AI Capability Framework - The Four Engineering Disciplines

Most organizations treat AI as a tool problem. They buy platforms, run pilots, train people on prompting, and wait for results. Then they wonder why 60% of AI investments generate no material business value (BCG, "The Widening AI Value Gap," 2025).

The technology works. What’s missing are the engineering disciplines that make AI produce reliable, context-specific, strategically aligned outcomes. These are institutional capabilities - built across functions, embedded in how work gets specified and executed, maintained as the technology shifts underneath.

This document defines four engineering disciplines that form a progressive capability stack. Each builds on the previous. Together, they represent the organizational infrastructure required to extract durable value from AI - not as a one-time implementation, but as a permanent operating capability. The disciplines originate in AI-native companies, but the underlying work - structuring knowledge, defining objectives, codifying processes - is the same whether you sell software, spirits, or steel. Every organization that runs on institutional knowledge and human judgment faces the same gap.

────────────────────────────────────────────────────────────

The Capability Gap No One Is Naming

The discourse around AI capability has been dominated by two narratives, both incomplete.

Narrative 1: "Just adopt it." Get tools into people’s hands, train them to prompt, measure adoption rates. This produces the BCG finding that 88% of organizations use AI in at least one function, but only 5% create substantial value at scale. Adoption without capability is consumption without digestion.

Narrative 2: "Upskill for the future." The World Economic Forum’s Future of Jobs 2025 report identifies AI and big data as the most important skill, with 77% of surveyed organizations committed to reskilling. But "AI skills" as a category is uselessly broad. It conflates typing a ChatGPT prompt with architecting an agentic system - like calling both "driving a car" and "designing a powertrain" the category "automotive skills."

The organizations actually generating value tell a different story. At Shopify, CEO Tobi Lutke declared "reflexive AI usage is now a baseline expectation" - but the real operational change was requiring managers to demonstrate why a task could not be done by AI before requesting additional headcount (Lutke, April 2025). At Microsoft, Satya Nadella introduced weekly "AI accelerator" meetings that deliberately exclude senior executives, placing engineers and technical staff at the center - designed to surface the unfiltered operational reality of how AI actually works inside the organization (Microsoft, 2025). At Anthropic, engineering productivity increased 200% per engineer after building systematic AI workflows: shared specification files, multi-agent orchestration, structured context management (Cherny, 2025). These are capability architecture stories, not adoption stories. And while these examples come from technology companies - the first to formalize the practices because they build AI systems daily - the disciplines themselves describe universal organizational work. Structuring institutional knowledge, specifying how decisions get made, defining what success looks like for autonomous processes: these are challenges for any company with more than a few dozen employees, a few legacy systems, and a few decades of accumulated practice.

What’s missing is a structural framework that defines what, specifically, organizations must learn to do with AI - and in what order. The answer is foundational engineering disciplines that compound over time and create institutional capability others cannot easily replicate. Generic "AI literacy" and tool-specific training that expires with every model update do neither.

The four disciplines are:

Prompt Engineering - communicating with AI systems (2024 frontier, now commoditizing)
Context Engineering - assembling the right information for AI to produce correct results
Intent Engineering - defining objectives, constraints, and success criteria for autonomous AI
Specification Engineering - codifying organizational processes and logic into machine-executable standards

Each has an emerging body of practice, a distinct skill profile, and a clear relationship to the others. Most organizations have invested heavily in layer one while ignoring layers two through four entirely.

────────────────────────────────────────────────────────────

Layer 1: Prompt Engineering

What it is. The discipline of communicating effectively with language models through structured instructions, examples, and reasoning patterns.

Why it matters. Prompt engineering established a core insight: the quality of AI output is determined by the quality of human input. This is not obvious. Most technology before AI improved output independently of how the user communicated with it - a spreadsheet formula works the same whether you understand it or not. AI systems are different. They are input-sensitive in ways that reward human skill.

Why it is commoditizing. By 2025, the primitive era of prompt engineering - characterized by trial-and-error iteration and artisanal prompt crafting - was already fading. Techniques like few-shot learning and chain-of-thought reasoning are now, as one practitioner put it, "as fundamental as knowing SQL is to database management - table stakes, not competitive advantages" (Big Blue Academy, 2026). Models have become better at interpreting unstructured input. Interfaces have absorbed prompting patterns into templates and defaults. The Fortune headline in May 2025 was blunt: the six-figure prompt engineering role was "already obsolete."

What this means for organizations. Prompt engineering should be treated as foundational literacy - the equivalent of email etiquette or spreadsheet competence. Everyone should have it. No one should specialize in it alone. It belongs in onboarding, not in a center of excellence. Organizations that are still investing primarily in "prompt engineering training" in 2026 are building a capability that is actively depreciating.

The residual value. Prompt engineering does not disappear. It becomes absorbed into the higher disciplines. A context engineer must write effective system prompts. An intent engineer must articulate objectives in language models can parse. A specification engineer must encode process logic in structured natural language. Prompting is to the AI capability stack what grammar is to writing: necessary, invisible when done well, insufficient on its own.

────────────────────────────────────────────────────────────

Layer 2: Context Engineering

What it is. The discipline of assembling, structuring, and delivering the right information to an AI system so it can produce accurate, relevant, situation-specific outputs.

Where the term comes from. In June 2025, Andrej Karpathy - one of the founding researchers at OpenAI and former head of AI at Tesla - named the shift from "prompt engineering" to "context engineering," defining it as "the delicate art and science of filling the context window with just the right information for the next step." The term was adopted rapidly: Anthropic, LangChain, and independent practitioners each published formal frameworks within weeks (see References 2, 3, 13). By late 2025, it had its own job descriptions.

The conceptual shift. The move from prompt engineering to context engineering reflects a structural change in how AI systems work. Modern AI applications do not run on single prompts. They operate on assembled context: system instructions, retrieved documents, structured data, conversation history, tool definitions, and prior model outputs - all packed into a context window that functions as the model’s working memory. Karpathy’s analogy: the LLM is the CPU; the context window is the RAM. What you load into RAM determines what the CPU can compute.

What it involves in practice.

Knowledge retrieval (RAG). Connecting AI to organizational knowledge bases, documents, policies, and data sources so responses are grounded in actual institutional information rather than general training data.
Information architecture. Structuring organizational knowledge so it can be efficiently retrieved and assembled. This includes taxonomies, metadata, document standards, and knowledge graph design.
System prompt design. Defining the persistent instructions, constraints, and behavioral parameters that shape how the AI operates within a specific organizational context.
Memory and state management. Maintaining relevant information across multi-turn interactions so the AI retains prior context rather than starting fresh each time.
Tool and API integration. Defining what external systems the AI can access and how, expanding its capability beyond text generation into action.

Why most organizations fail here. Context engineering exposes a truth that technology purchases cannot solve: most organizational knowledge is not structured for machine consumption. It lives in email threads, in the heads of experienced employees, in political agreements that were never documented, in process exceptions known only by the people who handle them. AI systems have a hard constraint here: they can only work with the information loaded into their active memory (the "context window"), and research from Stanford and UC Berkeley has shown that performance degrades when too much information is loaded at once - critical details get buried in the middle and missed. More information is not better. The right information, well-structured, is better. The binding constraint is the organization’s ability to surface the right knowledge in the right structure at the right moment.

How the frontier organizations solve it. Boris Cherny, head of Claude Code at Anthropic, described the solution his team uses: "When Claude does something wrong, add it [to the specification] so it doesn't repeat." His team maintains a shared CLAUDE.md file checked into version control - institutional memory for AI systems, continuously refined through use. The principle is simple: every error is a missing specification. Every missing specification is a knowledge gap made visible.

The organizational capability required. Context engineering is a cross-functional discipline. It requires:

Knowledge architects who can structure organizational information for AI retrieval
Data stewards who maintain the quality and currency of knowledge bases
Integration specialists who connect AI systems to data sources and tools
Domain experts who validate that retrieved context is accurate and complete

At this layer, AI capability building is an organizational design challenge, not a training program.

────────────────────────────────────────────────────────────

Layer 3: Intent Engineering

What it is. The discipline of defining objectives, desired outcomes, constraints, decision boundaries, and success criteria for AI systems that operate with increasing autonomy.

Why it exists. As AI systems evolve from conversational assistants to autonomous agents - systems that plan, execute multi-step tasks, use tools, and make decisions - a new problem emerges: these agents fail not because they cannot reason, but because "their objectives, outcomes, and constraints are underspecified" (Product Compass, 2025). An agent that can execute perfectly will produce useless or harmful results if it does not know what success looks like, what trade-offs are acceptable, and when to stop.

The defining insight. "Intent is what determines how an agent acts when instructions run out" (Product Compass, 2025). Prompts tell an AI what to say. Context tells it what to know. Intent tells it what to accomplish - and what not to sacrifice in the process.

The framework components. An intent specification, as formalized by emerging practice, includes:

Objective. The problem being solved and why it matters. Qualitative, aspirational, guides trade-offs.
Desired outcomes. Observable states indicating success. Not activities or outputs - observable changes from the user’s perspective.
Health metrics. What must not degrade during optimization. This addresses Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure.
Strategic context. The operational system the AI is working within - organizational priorities, dependencies, constraints.
Decision types and autonomy levels. Which decisions the agent takes independently, which require human escalation.
Constraints. Both soft constraints (steering guidance) and hard constraints (enforced boundaries).
Stop rules. When to halt, when to escalate, when to declare completion.

The progression from context engineering. Context engineering improves the relevance of AI outputs but remains reactive to user queries. Intent engineering transforms the system "from a conversational interface into a structured execution engine" (Tericsoft, 2025). The shift is from "give the AI the right information" to "give the AI the right objective."

The organizational challenge. Intent engineering requires something most organizations have never done: explicitly articulate their actual objectives, actual priorities, and actual trade-off logic. The strategy deck version will not do. What’s needed is the real version - the one that exists in the heads of senior leaders and manifests in how decisions actually get made.

Guillermo Rauch, CEO of Vercel (the company behind Next.js and v0), distilled this to three essential capabilities for the AI era: "clearly defining product intent, coaching AI effectively through iteration, and quickly resolving challenges when AI gets stuck" (Rauch, 2025). The first of those three - defining intent - is the hard one. The rest follows from it.

This is uncomfortable. Organizations run on ambiguity by design. Competing priorities coexist because no one has been forced to choose between them. Intent engineering forces the choice. You cannot tell an agent to "maximize customer satisfaction while minimizing cost while maintaining quality while moving fast" and expect coherent behavior. Agents, unlike people, cannot navigate political ambiguity. They need rank-ordered objectives, explicit trade-offs, and clear escalation rules.

What this means for capability building. Intent engineering is not a technical skill alone. It requires:

Strategic clarity from leadership about what actually matters and in what order
Process owners who can articulate success criteria and failure modes for their domains
Governance specialists who can define autonomy boundaries and escalation logic
Cross-functional alignment because an agent operating across functions will expose every inconsistency in how those functions define success

────────────────────────────────────────────────────────────

Layer 4: Specification Engineering

What it is. The discipline of codifying organizational processes, decision logic, policies, and standards into structured, machine-readable specifications that AI systems can execute against reliably and consistently.

The ambition. If intent engineering tells AI what to accomplish, specification engineering tells it how the organization works. Every process. Every decision tree. Every policy. Every exception. Every escalation path. Every unwritten rule. Captured in a format precise enough for machines to execute and clear enough for humans to audit.

Why this is the hardest layer. Most organizations cannot specify their own operations with precision. Not because they choose not to, but because much of how organizations actually function has never been written down:

Tribal knowledge. The way things actually get done, passed from person to person, never documented. When key employees leave, this knowledge disappears. Research on tacit knowledge in organizations found that "institutional knowledge is often locked in the minds of subject matter experts" and cannot be reliably reconstructed from formal documentation alone (Zuin, Mastelini, Loures & Veloso, 2025).
Political agreements. Informal understandings about territory, authority, and precedence that shape how decisions actually get made. These are undocumented by design because writing them down would surface contradictions and require resolution.
Process exceptions. The "but in this case we do it differently" knowledge that accumulates in experienced teams. Often more voluminous than the official process itself.
Implicit standards. Quality thresholds, communication norms, approval dynamics, risk tolerance - all operating without formal specification, calibrated through years of organizational socialization.

The connection to spec-driven development. In software engineering, a parallel discipline has already matured. ThoughtWorks defines spec-driven development (SDD) as "a development paradigm that uses well-crafted software requirement specifications as prompts, aided by AI coding agents, to generate executable code" (ThoughtWorks, 2025). GitHub open-sourced an SDD toolkit in September 2025. Addy Osmani, engineering lead at Google Chrome, published "How to Write a Good Spec for AI Agents" (O'Reilly, January 2026), establishing that specifications should focus on "what and why, more than the nitty-gritty how" - the organizational equivalent of defining success criteria before dictating procedures.

How this differs from traditional requirements engineering. IT teams will recognize specification engineering as familiar territory - requirements gathering, business process modeling, and systems analysis have existed for decades. The resemblance is real, but the consumer is different. Traditional requirements specifications are read by human developers who fill gaps with judgment, ask clarifying questions, and infer intent from ambiguity. AI agent specifications must be complete because the machine will execute them literally. A human developer reads "handle edge cases appropriately" and makes reasonable choices. An AI agent treats it as a null instruction. The discipline is the same. The tolerance for ambiguity is zero.

The AGENTS.md standard - an open format for guiding AI coding agents - has been adopted by over 20,000 repositories and is supported natively by GitHub Copilot, OpenAI Codex, Google Gemini, Cursor, and others (InfoQ, August 2025). Each repository’s AGENTS.md encodes its build steps, testing workflows, coding conventions, and quality standards in a structured format that any AI agent can read and execute against. This is specification engineering applied to software development - and the principle transfers directly to organizational operations.

The question for any enterprise function is the same one software teams have answered: can you define the inputs, outputs, preconditions, postconditions, and constraints of your compensation review process? Your onboarding workflow? Your talent calibration? Your market entry checklist? Your supply chain escalation logic? If not, no AI system will execute them reliably. The complexity of a consumer goods company’s route-to-market process or a financial institution’s regulatory compliance workflow is no less specification-worthy than a software build pipeline. The tooling is the same. The intellectual challenge is the same. The only difference is that software teams started first.

What specification engineering produces. When an organization develops this capability, it creates a new class of artifacts:

Process specifications. Machine-readable definitions of how work flows through the organization, including decision points, routing logic, and exception handling.
Policy specifications. Structured representations of organizational rules that AI can apply consistently across cases, languages, and geographies.
Quality specifications. Explicit criteria for what "good" looks like in each context - replacing the implicit judgment of experienced employees with auditable standards.
Integration specifications. Definitions of how systems, processes, and data sources connect and depend on each other.

The organizational consequence. Specification engineering forces organizations to make explicit what has always been implicit. It surfaces contradictions, resolves ambiguities, and creates a written record of how the organization actually operates - often for the first time. The resulting clarity has independent value regardless of technology. An organization that has specified its operations can deploy AI against them, but it has also built something more durable: an auditable, transferable description of how it works.

────────────────────────────────────────────────────────────

Where Knowledge Falls

Knowledge is the raw material that each discipline progressively structures and makes actionable. The four engineering disciplines are, at their core, a framework for transforming organizational knowledge from tacit to executable:

This progression maps to the knowledge management literature’s SECI model (Nonaka & Takeuchi): Socialization (tacit to tacit), Externalization (tacit to explicit), Combination (explicit to explicit), and Internalization (explicit to tacit). The four engineering disciplines operationalize this cycle for the AI era, with one critical addition: the final transformation is not back to tacit knowledge in human heads, but to codified, executable knowledge in organizational systems.

The implication. An organization’s AI capability is ultimately bounded by its ability to codify its own knowledge. No model, no platform, no vendor can compensate for knowledge that does not exist in structured, accessible form. This is why BCG found that organizations generating value from AI are those that "redesign workflows" - they are doing the knowledge codification work, whether they call it that or not.

────────────────────────────────────────────────────────────

The Capability Stack: How the Layers Relate

The four disciplines are not independent skills to be trained in parallel. They are a stack. Each layer requires the previous one as foundation and enables the next one to function:

Why the order matters. You cannot do context engineering if your people cannot prompt effectively - they will not know what information to assemble or how to validate that it was assembled correctly. You cannot do intent engineering if your knowledge is not structured - you will define objectives against information that does not exist in accessible form. You cannot do specification engineering if your intents are ambiguous - you will codify contradictions rather than clarity.

Where most organizations are today. The vast majority of organizations are investing almost exclusively in Layer 1. "AI literacy programs" are prompt engineering programs. "AI upskilling" means teaching people to use ChatGPT more effectively. This is necessary but radically insufficient - it is teaching people to type while the real capability gap is in what they should be writing.

The stack in practice: performance management

To make the progression concrete, consider a process every leader in every organization runs: performance management. Goal-setting, feedback, calibration, development decisions. Every manager does it. Most do it badly. AI makes the gap between good and bad visible.

Layer 1 - Prompt. A manager asks an AI to "write a performance review for a team member who exceeded targets." The output is generic, plausible, and useless - it sounds professional, says nothing about actual work done. Could describe anyone in any company.

Layer 2 - Context. The AI is now connected to the goals set in January, project deliverables, peer feedback, skill assessments, and team benchmarks. The same question produces a review that references real work. This is where most organizations stall - because their goals live in one system, project data in another, feedback in a third, and nobody built the connective tissue between them.

Layer 3 - Intent. The system now calibrates against defined objectives: differentiate the top 15% with development investment, flag rating inflation across managers, ensure succession pipeline coverage for critical roles, escalate misaligned ratings before calibration meetings. The AI is no longer drafting text - it is running the review cycle against explicit success criteria, surfacing patterns humans miss, and routing decisions to the right authority level.

Layer 4 - Specification. The full cycle is codified: goal-setting templates tied to business OKRs, calibration rules by grade level, promotion criteria with evidence requirements, development plan triggers based on skill gaps and career aspirations. The AI executes the entire performance management cycle - across 25 markets, against local employment regulations - and produces an auditable output managers review and decide on, rather than draft and format from scratch.

The difference between Layer 1 and Layer 4 is the difference between an AI that helps one manager write one review and an AI that runs a global process to completion. The technology at each layer is the same. What changes is the organizational clarity required to use it.

────────────────────────────────────────────────────────────

Emerging Artifact Domains

As organizations build these capabilities, new functional domains emerge that do not map to traditional organizational structures. These are not departments - they are disciplines that must be distributed across functions:

Knowledge Architecture

Structuring organizational knowledge for both human and machine consumption. Combines traditional knowledge management with information architecture, ontology design, and retrieval system optimization. Requires deep domain expertise combined with structural thinking - this is not an IT function.

Process Specification

Defining how organizational processes work with enough precision for AI execution. Process owners move from describing "what we do" in narrative form to specifying inputs, outputs, decision logic, exceptions, and quality criteria in structured formats. This is where unspoken institutional knowledge gets transferred into documented, auditable form.

AI Governance and Intent Alignment

Maintaining the objectives, constraints, autonomy boundaries, and escalation logic for AI systems. Sits between strategy and technical implementation - requires both strategic clarity and system-level understanding.

Evaluation and Quality Engineering

Measuring whether AI systems produce correct, consistent, and useful outputs. Requires building evaluation criteria and test cases from organizational reality (not synthetic benchmarks), and maintaining quality standards as both AI systems and business processes evolve.

Integration and Orchestration

Connecting AI systems to organizational data, tools, and workflows. Includes API design, data pipeline management, and coordination of multi-agent systems that span functional boundaries.

These domains represent new forms of organizational capability that do not exist today in most enterprises. They will not emerge from training programs alone. They require deliberate organizational design, role definition, and sustained investment - the same treatment organizations gave to digital transformation capabilities a decade ago, but with a more precise target.

────────────────────────────────────────────────────────────

Implications for Capability Building

What this framework changes about AI strategy

Investment sequencing. Organizations should invest in the four disciplines in order, ensuring each foundation is solid before building the next layer. Running an intent engineering initiative without functioning context engineering is premature optimization.
Training is necessary but insufficient. Prompt engineering can be taught in a workshop. Context engineering requires organizational infrastructure. Intent engineering requires strategic clarity. Specification engineering requires institutional commitment to making implicit knowledge explicit. The difficulty and investment required escalates at each level - and so does the value created.
The technology is secondary to the discipline. Models change every quarter. Platforms consolidate and fragment. But the organizational capability to structure knowledge, define intent, and specify processes persists across all technology shifts. An organization that has codified its compensation logic into a clear specification can deploy it on any AI platform. An organization that has not done this work will fail on every platform equally.
The durable work is the specification work. The tasks that persist are the ones AI cannot do for itself: structuring knowledge, defining objectives, specifying processes, and auditing outputs. Everything else is being absorbed by the technology at an accelerating rate. The people who do this work are the ones whose roles grow in value.
Industry is irrelevant to the framework. The four disciplines describe how any organization prepares its institutional knowledge for an era of AI-augmented execution. A technology company, a beverage company, a bank, and a hospital all share the same dependency: processes that run on accumulated human judgment, documented nowhere with enough precision for a machine to replicate. The capability gap is the same. The path through it is the same. The only variable is where each organization starts.

────────────────────────────────────────────────────────────

A Note on Pace

These disciplines are not theoretical. They are already being practiced at the frontier, even if the language varies:

Anthropic runs 70-100% of its engineering output through AI agents orchestrated with specification files and sub-agent architectures. Boris Cherny’s workflow: specification first, plan second, execution third. "Coding becomes a pipeline of phases: spec, draft, simplify, verify" (Cherny, 2025).
OpenAI shipped the Agents SDK with explicit support for intent engineering primitives: tool definitions, handoff protocols, guardrails, and tracing. The Model Spec (December 2025) codifies how agents should interpret autonomy boundaries and trustworthiness signals.
Mistral AI (Paris) is building enterprise AI infrastructure with a different premise: AI as utility, not spectacle. Arthur Mensch, CEO, describes the goal as "abstracting away from lower-level routines that data scientists understand to higher-level systems that business owners can actually use" (Mensch, 2025). Their enterprise deployments focus on three use cases that map directly to the capability stack: developer productivity (context engineering), knowledge management connected to proprietary data (specification engineering), and customer service automation (intent engineering). EU-hosted, GDPR-native infrastructure.
AWS published prescriptive guidance on "clarifying agent intent and scope" as the first focus area for operationalizing agentic AI - positioning intent engineering as the prerequisite for production deployment (AWS, 2025).

The timeline of this shift is worth registering. In 2024, prompt engineering was the leading edge. By mid-2025, Karpathy and the AI engineering community had already moved to context engineering. By late 2025, intent engineering frameworks were being formalized. Specification engineering is the current frontier - and it is being standardized faster than previous disciplines because the tooling now demands it. AI agents that operate without specifications produce unpredictable results. The specification functions as the operating system of the agent.

The tech companies listed above are building these practices in public because open documentation is their culture. But the need is identical in industries where the work is less visible. A consumer goods company with 50 markets, each running localized versions of global processes, has a specification engineering challenge that dwarfs most software shops. A financial services firm with 30 years of compliance precedent embedded in institutional memory faces a context engineering problem of extraordinary depth. A manufacturing company with plant-level process variations across three continents needs intent alignment as badly as any AI lab. The disciplines are universal. The industries that build them first gain the same compounding advantage - regardless of what they produce.

Organizations that wait for these disciplines to become packaged training programs will find themselves permanently behind. The capability is built through practice - through the daily work of specifying, structuring, and iterating on how AI operates within a specific organizational context.

────────────────────────────────────────────────────────────

References

Practitioners and AI Labs

Karpathy, A. Post on context engineering. X, June 2025. "Context engineering is the delicate art and science of filling the context window with just the right information for the next step."
Willison, S. "Context Engineering." simonwillison.net, June 2025.
Anthropic. "Effective Context Engineering for AI Agents." anthropic.com/engineering, 2025.
Cherny, B. (Head of Claude Code, Anthropic). Interviews on AI workflow, specification files, and multi-agent orchestration. 2025. Via Lenny’s Newsletter, VentureBeat, DEV Community.
Lutke, T. (CEO, Shopify). Internal memo on AI as baseline expectation. April 2025. Published on X.
Nadella, S. (CEO, Microsoft). AI accelerator meetings, organizational restructuring for AI capability. Microsoft Blog, 2025.
Mensch, A. (CEO, Mistral AI). Interviews on enterprise AI as utility, knowledge management, and EU-hosted infrastructure. 2025-2026. Via CNBC, Big Technology Podcast, McKinsey.
Rauch, G. (CEO, Vercel). On defining product intent, AI-era developer skills, and spec-driven workflows. 2025. Via Lenny’s Newsletter, ChatPRD.
OpenAI. "Model Spec." model-spec.openai.com, December 2025.
Osmani, A. (Google Chrome). "How to Write a Good Spec for AI Agents." O'Reilly / addyosmani.com, January 2026.

Standards and Frameworks

AGENTS.md. "A simple, open format for guiding coding agents." agents.md. Adopted by 20,000+ repositories.
GitHub. "Spec-driven development with AI: Get started with a new open source toolkit." GitHub Blog, September 2025.
LangChain. "Context Engineering for Agents." blog.langchain.com, 2025.
ThoughtWorks. "Spec-driven development: Unpacking one of 2025's key new AI-assisted engineering practices." 2025.
AWS. "Focus Area 1: Clarify Agent Intent and Scope." AWS Prescriptive Guidance, 2025.
ISO/IEC 42001:2023. AI Management Systems.

Intent Engineering

Product Compass. "The Intent Engineering Framework for AI Agents." 2025.
Tericsoft. "Intent Engineering in AI: The Shift Beyond Context Engineering." 2025.

Knowledge and Research

Zuin, Mastelini, Loures & Veloso. "LLMs as Tacit Knowledge Excavators in Organizations." 2025.
MDPI. "Unveiling the Unspoken: A Conceptual Framework for AI-Enabled Tacit Knowledge Co-Evolution." 2025.
Nonaka, I. & Takeuchi, H. "The Knowledge-Creating Company." Oxford University Press, 1995.

Industry Analysis

BCG. "The Widening AI Value Gap: Build for the Future." September 2025.
McKinsey & Company. "The State of AI in 2025." 2025.
World Economic Forum. "The Future of Jobs Report 2025." January 2025.
Fortune. "This six-figure role was predicted to be the next big thing - it's already obsolete thanks to AI." May 2025.
InfoQ. "AGENTS.md Emerges as Open Standard for AI Coding Agents." August 2025.

Celebrate

Support

Love

Insightful

Funny

Comment

Copy
LinkedIn
Facebook
X

3 Comments

Matthew Diakonov

7mo

Report this comment

the four-layer capability stack framing is really useful. the commoditization of prompt engineering at layer 1 matches what Im seeing - the value isnt in crafting better prompts anymore, its in encoding organizational knowledge with enough precision that the agent can execute autonomously. the performance management example makes it concrete. Im seeing the same pattern in software development - at layer 1 the agent writes generic code, at layer 4 it understands your specific architecture, testing conventions, deployment constraints, and can operate across the full development lifecycle with minimal human review

Reply 1 Reaction

2 Reactions

The Capability Gap No One Is Naming

Layer 1: Prompt Engineering

Layer 2: Context Engineering

Layer 3: Intent Engineering

Layer 4: Specification Engineering

Where Knowledge Falls

Recommended by LinkedIn

The Capability Stack: How the Layers Relate

The stack in practice: performance management

Emerging Artifact Domains

Implications for Capability Building

A Note on Pace

References