The Layers of Agentic AI Engineering

The industry keeps confusing the layers as each new one gets named. Prompt engineering, context engineering, intent engineering — these are not synonyms, not a progression where each replaces the last, and not marketing terms for the same activity. They are distinct engineering disciplines that operate at different levels of abstraction, answer different questions, and break in different ways when absent.

This post maps the layers as they actually exist in 2026, drawing on the academic formalisation, the practitioner evidence, and the production failures that clarify where each layer's jurisdiction begins and ends.

---

The Core Hierarchy

The clearest framing comes from Vishnyakova's pyramid model ^[1], which identifies four cumulative layers. Several other authors converged on the same taxonomy independently in early 2026 ^[2][3][11], which suggests the structure reflects something real rather than one person's framework. Since then, the industry has continued converging — FutureAGI, D-CENT, the ETCLOVG survey from Carnegie Mellon/Yale/Amazon ^[20], and a formal UN University policy framework ^[21] all arrived at overlapping stacks in 2026. The convergence is the evidence.

The key word is cumulative. Each layer requires the one below it as a foundation. Removing a lower layer collapses everything above it. No layer replaces the one before — it subsumes it.

One clarification before the detail. These layers are levels of abstraction — each answers a fundamentally different question. They are not categories of tooling. The industry has a tendency to name an implementation technique (harness engineering, loop engineering, graph engineering) and call it a new layer. It isn't. Those are the techniques you use to build a layer, not a separate level in the hierarchy. Confusing the two leads to stacks with seven or eight layers that are actually four layers plus their plumbing. This post separates the two: each layer section introduces the abstraction alongside the implementation technique whose clearest example lives there — but as the section on cross-cutting techniques argues later, none of these techniques are actually confined to one layer. They're general-purpose tools, pointed at whichever layer needs building.

The Core Hierarchy: four abstraction layers and six cross-cutting implementation techniques — click to expand

One thing to note upfront: these layers are not exclusively human-facing. In an agentic system, the agent itself operates every layer. An orchestrator agent formulates prompts for its sub-agents (Layer 1). It assembles context from memory, tool outputs, and retrieval systems before each delegation (Layer 2). It encodes task-level intent — priorities, constraints, success criteria — into the sub-agent's instructions (Layer 3). And at the enterprise level, specifications constrain what all agents across the organisation may do (Layer 4). The layers are recursive. Every agent-to-agent call re-enters the stack.

---

Layer 1: Prompt Engineering

Question answered: How is the query formulated — by a human or by an agent — so the model produces the right output?

Prompt engineering is the discipline of composing inputs to a language model: system prompts, role instructions, few-shot examples, chain-of-thought triggers, format constraints. In the original framing, this was a human activity — one question, one answer, one context, with the human in the loop at every step.

That framing is incomplete. In an agentic system, the most prolific prompt engineer is the agent itself.

When an orchestrator delegates a task to a sub-agent, it writes a prompt. When a coding agent calls a tool, the function-call parameters are a prompt. When a review agent evaluates another agent's output, it constructs an evaluation prompt. When a planning agent decomposes a goal into subtasks, each subtask description is a prompt. The agent generates dozens or hundreds of prompts per workflow — composing instructions, formatting tool inputs, structuring delegation requests — all without a human touching a keyboard.

This means prompt quality is no longer just a human craft skill. It's a system design property. The quality of agent-generated prompts depends on how the system was built: the tool schemas it was given (Layer 2), the intent it was encoded with (Layer 3), and the specifications it operates under (Layer 4). A poorly designed context pipeline produces poor agent-generated prompts at every step, compounding across the workflow.

Techniques that remain relevant — for both human and agent callers:

• Zero-shot and few-shot prompting
• Chain-of-thought (CoT) and tree-of-thoughts (ToT) ^[4]
• System prompts with role assignment, format constraints, and explicit boundaries
• ReAct (reasoning + acting) for tool-using models
• Structured output schemas (Pydantic, JSON mode)

Where it breaks — as a standalone discipline: A single prompt, however well-crafted, cannot solve what happens at step 47 of a 50-step autonomous workflow. At that point, the problem is not query formulation — it's what the model sees in its context window. No prompt, whether human-written or agent-generated, can solve context contamination, stale state, or cross-agent information leakage. The fix lives in the layers above.

Vishnyakova puts it well: "'The art of prompting' is, in reality, a euphemism for 'we do not yet understand what we are doing, but results are sometimes impressive.'" ^[1]

Prompt engineering is the foundation. It operates at every model call — human-initiated or agent-initiated. But it is not the building.

---

Layer 2: Context Engineering

Question answered: What does the agent know, see, and remember at the moment of action?

Anthropic defined context engineering as the natural progression of prompt engineering ^[5]. The framing is precise: where prompt engineering focuses on how you phrase the request, context engineering focuses on what the model knows when it processes that request.

In an agentic system, the context window contains far more than the user's prompt. It includes the system prompt, conversation history, tool outputs, retrieved documents, prior-step results, user state, and policy constraints. Context engineering is the design of this entire informational environment.

Context as Operating System

Vishnyakova proposes treating context as the agent's OS ^[1] — not passive input data but an active execution environment. Like a computer OS, context manages memory (what to retain, what to evict), allocates resources (which data are accessible to which sub-agent), isolates processes (output from one module doesn't contaminate another), and provides a unified interface to external systems.

Google ADK operationalised this with a three-tier context stack ^[6]: storage (long-term retention) → processor pipeline (compression, filtering, enrichment) → compiled working context (what the model actually sees). The key thesis: context is not a text string — it's a "compiled representation of a richer stateful system."

Five Quality Criteria

Production-grade agent context must satisfy ^[1]:

1. Relevance — Only what is necessary for the current step. Excessive context causes lost-in-the-middle degradation, distracts the model, and increases cost. Good context is the minimum sufficient for the decision.

2. Sufficiency — Everything needed for a decision without guesswork. If the agent lacks data, it hallucinates. Sufficiency is the architectural guard against hallucinations.

3. Isolation — In multi-agent systems, each sub-agent sees only its own context. Data leakage between roles is a controllability problem as much as a security one. Tomašev et al. formalise this as privilege attenuation: upon sub-delegation, an agent cannot transfer its full rights, only a strictly limited slice ^[7].

4. Economy — Minimum tokens and context reassemblies while preserving quality. According to Manus, the cost difference between cached and uncached tokens in their production scenario reached approximately 10× ^[8]. Context architecture is directly the product's unit economics.

5. Provenance — Every element of context must be traceable to its source: which system it came from, when, with what trust level. Without this, neither auditing agent decisions nor debugging errors is possible.

Context Rot

Breunig's taxonomy ^[9] identifies four degradation modes:

• Context poisoning: A hallucination enters the context and reproduces at every subsequent step.
• Context distraction: As context expands, the model relies on accumulated history instead of synthesising new plans.
• Context confusion: Irrelevant information degrades response quality — the model tries to use everything it was given.
• Context clash: Parts of the accumulated context begin contradicting one another. A Microsoft/Salesforce study showed a 39% quality drop when a single prompt was split into sequential turns.

Practical Implications

Eledath's levels of agentic engineering ^[10] place context engineering as a distinct capability threshold — Level 3 in his eight-level progression. The mantra: "Every token needs to fight for its place in the prompt." But he notes that the emphasis has shifted: the focus moved from filtering out bad context to making sure the right context is present at the right time.

This is where CLAUDE.md files, AGENTS.md, structured docs/ directories, and MCP tool descriptions live. It's system prompts, tool schemas, conversation history management, and the decision about which tools to expose per turn. It's the design of what the model sees — not what you say to it.

The gap between knowing this and doing it is wide. Redis's 2026 State of Context Engineering survey found that 97% of enterprise leaders believe context engineering is the deciding factor in whether AI agents work — but only 4% have actually built the systems to deliver it ^[22]. Belief has outrun practice by an order of magnitude.

Belief vs. Practice: Redis, State of Context Engineering 2026 — click to expand

The Implementation Technique: Harness Engineering

The industry has recently named harness engineering as a separate layer — the CI pipelines, linters, tool schemas, permissions, sandboxes, and feedback loops that surround the model at runtime. OpenAI coined the term when their Harness team shipped a product with zero manually-written code over five months ^[15]. The UN University published a formal policy framework for agent harnesses in 2026 ^[21].

But harness engineering is not a separate layer of abstraction. Its clearest example is as implementation infrastructure for context engineering — the plumbing that delivers the right context at the right time. A harness that exposes the wrong tools is a context failure. A sandbox with the wrong permissions is a context isolation failure. A CI pipeline that doesn't feed test results back into the agent's context is a context sufficiency failure.

Most legibly, the harness answers Layer 2's question — what does the agent know at the moment of action? — with infrastructure rather than with documents.

OpenAI's specific lessons confirm this framing ^[15]:

• AGENTS.md as table of contents, not encyclopedia. Roughly 100 lines pointing to deeper sources of truth. A giant instruction file crowds out the task, the code, and the relevant docs — a context economy problem.
• Repository knowledge as system of record. Anything the agent can't access in-context effectively doesn't exist — a context sufficiency problem.
• Enforce architecture, not implementations. Strict boundary constraints enforced mechanically via linters, with freedom within those boundaries — a context isolation problem.

---

Layer 3: Intent Engineering

Question answered: What should the agent seek to achieve, and at what cost?

Context engineering tells the agent what it needs to know. Intent engineering tells it what it should pursue. The distinction is real and consequential: an agent with perfect context can still optimise the wrong objective.

The Klarna Case

The Klarna Case: automation without intent — click to expand

The canonical cautionary example ^[1]. Klarna's AI agent handled two-thirds of all customer inquiries in Q3 2025, performing work equivalent to 853 full-time employees, saving approximately $60 million. Then the CEO publicly acknowledged the bet on cost optimisation had been excessive. Service quality had suffered. Forrester characterised it as an "AI overpivot." The company began rehiring humans.

The diagnosis: a dual deficit. The context deficit — the agent likely lacked adequate access to individual customer history, brand tone, and loyalty policies. But the deeper problem was an intent deficit. Even if the agent had possessed all relevant data, the corporate intent — the balance between cost savings and customer loyalty, the brand's target NPS, the hierarchy of trade-offs in service situations — was never formalised and encoded. The agent optimised cost per token, not the value of customer relationships.

Context was present. Intent was not. The system was tactically informed but strategically blind.

What Intent Engineering Looks Like

IE encompasses ^[1][3]:

• Defining trade-off hierarchies: What matters more — speed or accuracy? Cost savings or customer loyalty? Regulatory compliance or user experience? Not binary choices but situationally ranked priorities that vary by department, product line, and situation.

• Encoding success criteria: "A good output is one where a non-technical manager can read it in two minutes and know what action to take." "If concise and comprehensive conflict, prioritise concise." These are intent declarations, not prompts.

• Feedback loops: Mechanisms for measuring how closely agent behaviour matches encoded intent and for correcting deviations.

• Cross-functional collaboration: IE cannot be performed by the engineering team alone. It requires business units, product managers, compliance specialists, and engineers jointly formalising what the agent should optimise.

Huryn's formulation: "Context without intent is noise" ^[12]. An agent receiving all relevant data but lacking a formalised understanding of the company's priorities will optimise the most readable metric — typically call cost, response speed, or task completion rate — rather than what actually matters.

The Principal-Agent Problem

This isn't new theory. It's the classical principal-agent problem in a new substrate. An agent acting on behalf of a principal tends to optimise the metrics that are easier to measure, not the ones that truly matter. In AI systems, this manifests as reward hacking and specification gaming — optimising the letter of a specification at the expense of its spirit. Not malicious intent, but a systemic consequence of architecture.

The Implementation Technique: Loop Engineering

The industry has named loop engineering as a separate layer — the think→act→observe cycle that drives autonomous agent behaviour. When does the agent act again? When does it stop? What counts as "done"?

Loop engineering is not a separate layer of abstraction. Its clearest example is as the execution pattern for intent engineering — the mechanism through which encoded intent gets pursued over multiple steps.

A loop that doesn't terminate is an intent failure: the success criteria weren't precise enough for the agent to know when it's done. A loop that converges on the wrong outcome is an intent failure: the trade-off hierarchy wasn't encoded correctly. A loop that retries endlessly on failure is an intent failure: the escalation policy — when to stop and ask for help — was never specified.

Most legibly, the loop answers the same question as Layer 3 — what should the agent seek to achieve, and at what cost? — with execution control rather than goal definitions.

This is why the most common loop failures are misdiagnosed as model problems. The model isn't failing to reason. The intent layer never told it what "good enough" looks like, so it keeps going — or stops too early — because it has no encoded basis for the decision.

---

Layer 4: Specification Engineering

Question answered: What does the organisation demand at scale, across all agents?

IE encodes what a specific agent or team should accomplish. Specification engineering extends the approach to the level of a corporate multi-agent architecture ^[1].

SE is the discipline of creating a complete machine-readable corpus of policies, quality standards, operational procedures, and corporate agreements — everything that previously lived in PDF regulations, executive orders, verbal agreements, and the formulation "everyone just knows."

Specifications as Constitution

Vishnyakova's metaphor is precise: "Specifications are the constitution of a nation of agents: intents are the laws enacted under it, context is their enforcement, and the prompt is a specific action in a specific situation." ^[1]

Anthropic's Constitutional AI rhymes with this logic — a training method where the model evaluates and rewrites its own responses against an explicitly formulated set of principles. It's not the same architecture: Constitutional AI operates at training time on model weights, while specification engineering as defined here operates at deployment time across a fleet of independently running agents. But it's proof the underlying pattern — behaviour bound by an explicit, machine-readable constitution rather than ad hoc instruction — already works at one layer of the stack.

The Scale Problem

The Scale Problem: TELUS Fuel iX, 2025 — click to expand

TELUS illustrates the cost of SE's absence at scale: through their Fuel iX platform, over 70,000 employees independently configured more than 21,000 customised AI copilots in 2025 ^[1]. What keeps 21,000 independently configured agents from diverging in behaviour, accumulating mutually contradictory decisions, and optimising conflicting objectives?

The question is unanswered. And that's the point: without specification engineering, it's unanswerable.

The Governance Gap

The enterprise data is stark ^[13][14]:

• 84% of companies have not redesigned roles around AI (Deloitte, 2026)
• Only 21% have a mature AI-agent governance model
• Agent deployment surged from 11% to 42%, then dipped to 26% as organisations tightened their definition of what counts as an "agent" — before rebounding to 54% (KPMG, 2026)
• 75% plan to deploy agentic AI within two years

Companies are massively deploying agents without managing what those agents see, want, or must do. Context forms spontaneously from haphazardly connected knowledge bases and uncoordinated policies. The governance gap is not an abstract risk — it's the operational gap between deployment velocity and engineering maturity.

The Implementation Technique: Graph Engineering

The industry has named graph engineering as a separate layer — the coordination topology of multi-agent systems. Fan-out, joins, conditional routing, quality gates, claims, isolation, and explicit exit conditions across a fleet of agents.

Graph engineering is not a separate layer of abstraction. Its clearest example is as the coordination topology for specification engineering — the mechanism through which organisational constraints get enforced when many agents run in parallel.

A graph where agents produce conflicting outputs is a specification failure: the shared definitions weren't explicit. A graph where one agent's output violates another agent's invariants is a specification failure: the interface contracts weren't formalised. A graph where agents duplicate each other's work — the agentic drift problem — is a specification failure: no shared concept registry existed to prevent reinvention.

Most legibly, the graph answers the same question as Layer 4 — what does the organisation demand at scale? — with topology rather than policy documents.

CooperBench's finding that agents achieve roughly 50% lower success rates when collaborating ^[19] is not a graph engineering failure — the routing and handoff logic can be wired perfectly and this still happens. It's a specification failure expressed through a graph: the agents had no shared definition of what a valid handoff looked like, what format one agent's output needed to be in for the other to use it, or who owned what. Rewiring the graph doesn't fix a disagreement neither agent knew it was having.

---

The Layers Are Recursive: How Autonomous Agents Re-Enter the Stack

The recursive nature of this hierarchy changes how you think about every layer.

In a human-driven interaction, the stack is traversed once: a human formulates a prompt (Layer 1), the system assembles context (Layer 2), the intent is either implicit in the human's head or encoded in the system prompt (Layer 3), and organisational specifications may or may not exist (Layer 4). One pass, one model call, done.

In an autonomous agentic system, the stack is re-entered at every step of execution.

Consider what happens when an orchestrator agent receives a task:

1. It reads the specification layer (Layer 4) — organisational policies, quality standards, and governance constraints that bound what it may do.
2. It encodes intent (Layer 3) — decomposing the high-level goal into sub-goals with explicit priorities, trade-offs, and success criteria for each sub-agent.
3. It assembles context (Layer 2) — retrieving relevant documents, compressing prior-step history, selecting which tool outputs to pass forward, and isolating each sub-agent's view of the shared state.
4. It writes a prompt (Layer 1) — the actual instruction to the sub-agent, parameterised with the assembled context and scoped by the encoded intent.

The sub-agent then does the same thing when it calls a tool or delegates further. The stack recurses.

This has a concrete engineering implication: prompt quality at step N is a function of context quality at step N, which is a function of intent clarity at step N, which is a function of specification consistency across the system. A failure at any layer cascades through every subsequent agent-to-agent call. The orchestrator that writes a vague delegation prompt does so because its context was insufficient or its intent was underspecified — not because prompt engineering is hard.

OpenAI's Harness team saw this directly ^[15]: "When something failed, the fix was almost never 'try harder.' Because the only way to make progress was to get Codex to do the work, human engineers always stepped into the task and asked: 'what capability is missing, and how do we make it both legible and enforceable for the agent?'" The fix was always a layer above the prompt — a missing tool, a missing document, a missing constraint.

This recursive property also explains why prompt engineering hasn't been superseded. Every agent-to-agent call bottoms out at a prompt. The prompt is the atomic unit of every model invocation, whether the caller is a human or another agent. You cannot escape Layer 1. You can only ensure the layers above it make Layer 1's job tractable.

Tracing a Failure Through the Stack

Take a concrete case. A code-review orchestrator delegates "check this PR for regressions" to a review sub-agent. The sub-agent comes back with a shallow pass — it flags a naming inconsistency and misses a broken error-handling path on the hot code path.

Read bottom-up, this looks like a prompt problem: the delegation instruction should have said what to look for. It isn't. Trace it up the stack instead. The orchestrator's Layer 4 read never encoded a severity taxonomy for what "regression" means at this company — correctness-breaking versus cosmetic. Its Layer 3 intent inherited that gap: no explicit priority ranking correctness above style. Its Layer 2 context assembly had no diff-blast-radius signal to pass down, so the sub-agent couldn't have prioritised the hot path even if it had been told to. By the time execution reached Layer 1, the prompt was the only layer left standing to absorb the ambiguity — and it did what underspecified prompts do: produced a plausible, wrong-priority answer.

The fix is not a better prompt. A better prompt at Layer 1 would just produce a better-worded version of the same wrong answer. The fix is a severity taxonomy at Layer 4, encoded once and inherited by every review sub-agent from then on.

The Reliability Tax of Depth

The recursive framing also explains something the single-pass view can't: why layer discipline — optional at shallow depth — becomes mandatory at scale.

Model each layer transition as carrying some fidelity — the odds that spec is faithfully translated into intent, intent into context, context into a well-formed prompt. Suppose a well-built system holds 95% fidelity at each transition, which is optimistic for most production stacks. A single orchestrator-to-tool call already crosses four such transitions. At 95% each, that's roughly 81% end-to-end. Add one more hop of delegation — orchestrator to worker to tool, the shape in the diagram below — and the same arithmetic drops under 70%. This is illustrative arithmetic, not a measured figure, but the direction matches what's actually been measured: CooperBench found agent performance degrades monotonically as agent count and delegation depth increase, not linearly ^[19].

The implication isn't "add redundancy at the leaf." It's that a layer running at 90% fidelity instead of 98% doesn't stay a small deficiency — it compounds every time the stack recurses. This is also why evaluation (the cross-cutting technique covered below) has to run at every frame of the stack, not just on the final output: a defect introduced three hops down is invisible at the top and surfaces, if at all, as a symptom two layers removed from its actual cause.

The Recursive Chain: one task, two hops of delegation — click to expand

The Reliability Tax of Depth — click to expand

---

Why the Industry Miscounts the Layers

Since the four-layer pyramid was published, multiple competing stacks have appeared: five layers, seven layers, eight layers. Boyd's seven-layer agent stack ^[16]. The ETCLOVG taxonomy (Execution, Tooling, Context, Lifecycle, Observability, Verification, Governance) from a Carnegie Mellon/Yale/Amazon survey of 170+ open-source projects ^[20]. D-CENT's five disciplines. FutureAGI's four-layer stack. Each has its own count.

The counts differ because they are counting different things.

The four-layer pyramid counts levels of abstraction — each layer answers a fundamentally different question. The competing stacks count implementation techniques — the engineering work required to build those layers. They are not wrong. They are answering a different question. But calling an implementation technique a "layer" creates a taxonomy where tools and abstractions sit at the same level, which makes diagnosis harder, not easier.

Here is where each one is clearest — not where it's confined:

Technique	What it actually is	Clearest at	Also reaches
Harness Engineering	Implementation infrastructure (CI, tools, sandboxes, feedback loops)	Context (Layer 2) — delivers the right information at the right time	Intent (spend ceilings), Specification (fleet-wide linter rules)
Loop Engineering	Execution pattern (think→act→observe, termination, retry)	Intent (Layer 3) — pursues encoded goals over multiple steps	Context (the "observe" step is a context refresh), Specification (fleet-wide retry ceilings)
Graph Engineering	Coordination topology (fan-out, joins, routing, quality gates)	Specification (Layer 4) — enforces shared rules across a fleet	Context ("isolation" is Layer 2's own criterion), Intent (routing is trade-offs, gates are success criteria)
Evaluation	Verification mechanism (trace→score→CI gate)	No single clearest layer	Every layer
Security / Constraints	Enforcement mechanism (trust domains, capability attenuation)	No single clearest layer	Every layer
Compounding	Learning loop (plan→delegate→assess→codify)	No single clearest layer	Every layer

The test is simple: does the technique answer a different question than the four layers, or does it answer the same question with different tooling? At its clearest, harness engineering answers "what does the agent know at the moment of action?" — the same question as context engineering. At its clearest, loop engineering answers "what should the agent pursue, and when is it done?" — the same question as intent engineering. Neither is a new level of abstraction — both are ways of building the existing ones. And neither stays put: point the same harness at a spend ceiling and it's building Intent; point the same loop at a fleet-wide retry policy and it's building Specification. None of the six rows above are exclusive to the layer they're clearest at — the isolation, gates, and routing vocabulary bleeding across the layer sections above is the proof, not an exception.

This matters because diagnosis depends on identifying which layer's content is actually missing. If a loop doesn't terminate, adding a graph orchestrator won't fix it — the intent layer never defined "done." If agents produce conflicting outputs, tuning the harness won't fix it — the specification layer never defined the shared vocabulary. Knowing that harness/loop/graph can reach other layers doesn't mean guessing at random — it means checking the layer each technique is clearest at first, then following the specific failure (not the technique's usual home) if that doesn't explain it. Miscounting the layers leads to fixing the plumbing when the blueprint is wrong.

The Cross-Cutting Techniques

Six techniques genuinely operate across all four layers rather than serving one. Harness, Loop, and Graph — mapped in the table above — are the three with a legible home layer. Evaluation, Security, and Compounding never had one to begin with:

Evaluation is the verification mechanism for every layer. Boyd puts it precisely ^[16]: "You cannot eyeball a production agent. The output space is too large, the failure modes are too subtle, and the cost of silent degradation is too high." The evaluation pipeline in 2026 is a six-stage chain ^[17]: instrument → trace → dataset → evaluator → score → CI gate. Amazon's experience across thousands of agents ^[18] confirms that single-model benchmarks are insufficient — agentic systems require evaluation of emergent behaviours, tool selection accuracy, and multi-step reasoning coherence. Without evaluation, you don't know whether your context is relevant, your intent is encoded correctly, or your specifications are consistent.

Security and constraints protect every layer from adversarial inputs, data leakage, and unauthorised actions. Boyd's key distinction ^[16]: "'Don't do X' in a system prompt is not a constraint. It's a preference. Real constraints are enforced at the execution layer, not requested in the prompt." Agents, the code they generate, and your secrets should live in separate trust domains ^[10].

Compounding is the learning loop that improves every layer over time ^[10]. LLMs are stateless. If the agent reintroduces a dependency you explicitly removed yesterday, it will do it again tomorrow unless you tell it not to. The technique: plan → delegate → assess → codify. The crucial step is codify — capturing what worked into rules files, documentation, and linting rules. OpenAI's Harness team operationalised this as "garbage collection" — recurring background agents that scan for deviations and enforce corrections ^[15]. "Human taste is captured once, then enforced continuously on every line of code."

---

How the Layers Interact

The layers form a dependency graph where failures cascade downward and fixes propagate upward.

Symptom	Likely Layer	Common Misdiagnosis
Output has wrong format, tone, or structure	Prompt (Layer 1)	—
Output is off-topic, missing key info, or has "forgotten" context	Context (Layer 2)	Blamed on the model
Agent does the task well but solves the wrong problem	Intent (Layer 3)	Blamed on the prompt
Agent loop doesn't terminate or converges on the wrong thing	Intent (Layer 3)	Blamed on the loop/harness
Parallel agents produce conflicting or incoherent outputs	Specification (Layer 4)	Blamed on the graph
Agent can't validate its own work or detect regressions	Evaluation (cross-cutting)	—
Agent makes correct decisions but violates security boundaries	Constraints (cross-cutting)	—

The pattern: what looks like a prompting problem is often a context problem in disguise. What looks like a context problem is often an intent problem — the agent has the right information but no understanding of what to prioritise. What looks like a loop or graph problem is almost always a layer above — the tooling is faithfully executing a badly specified abstraction.

---

Connecting the Laws

The previous post mapped how six engineering laws shift when agents join the team. Those laws and these layers are two views of the same system.

The Specification Amplifier — the finding that 41.8% of multi-agent production failures trace to specification problems — is a Layer 3 and Layer 4 failure. A vague spec given to three agents produces three divergent implementations, each internally consistent, none correct. The agents had sufficient context (Layer 2) and well-formed prompts (Layer 1). What was missing was encoded intent (Layer 3) and shared specifications (Layer 4).

Agentic drift — parallel agents independently inventing competing abstractions for the same concept — is a Layer 4 failure expressed through Layer 2 tooling. Each agent's context was locally correct. What was missing was a shared concept registry at the specification layer.

The review bottleneck — Brooks's Law migrated from onboarding to review — is a comprehension bandwidth problem that manifests when Layer 2 (context) delivers more output than humans can absorb. The solution lives at Layer 3 (intent): encoding review priorities, blast radius classification, and "what counts as reviewed" into the agent infrastructure rather than leaving it to human judgment at merge time.

The layers explain where each law now operates. The laws explain why each layer matters.

---

The Diagnostic Checklist

For engineering teams building agents today, the layers map to a concrete audit. For each layer, the question is not "have we done this?" but "would the system degrade gracefully if this layer failed?"

Layer 1 — Prompt Engineering

• Are system prompts, tool descriptions, and output format specs well-structured?
• Do your agents generate well-formed prompts when delegating to sub-agents?
• Could a new team member read the prompt and understand what the agent is supposed to do?

Layer 2 — Context Engineering (harness is the clearest lever, not the only one)

• Does the agent have access to everything it needs for the current step — and nothing it doesn't?
• Is context assembled dynamically or is it a static dump? Does it satisfy relevance, sufficiency, isolation, economy, and provenance?
• Is the harness infrastructure (CI, tools, sandboxes, feedback loops) delivering the right context at the right time?
• What happens when context goes stale mid-workflow?

Layer 3 — Intent Engineering (loop is the clearest lever, not the only one)

• Are success criteria encoded in the infrastructure, or communicated conversationally?
• Does the agent know when it's done? Is "done" a real predicate or "when the model thinks it's done"?
• Are trade-off hierarchies explicit? If speed and accuracy conflict, which wins — and does the agent know?
• Does the loop have a termination condition, a cost ceiling, and an escalation path?

Layer 4 — Specification Engineering (graph is the clearest lever, not the only one)

• Are organisational policies, quality standards, and domain knowledge machine-readable?
• Do parallel agents share a common vocabulary — or will they reinvent each other's abstractions?
• Is the coordination topology enforcing organisational constraints, or just routing messages?
• What happens when two agents produce outputs that contradict each other?

Cross-cutting

• Can you trace an agent decision back through all four layers to its root cause?
• Is evaluation running at every layer, or only at the output?
• Are constraints enforced at the execution layer, or merely requested in the prompt?
• Are lessons being codified back into the system, or does the same failure recur?

---

The Through-Line

Whoever controls the agent's context controls its behaviour. Whoever controls its intent controls its strategy. Whoever controls its specifications controls its scale.

The hierarchy is cumulative. Prompt engineering without context engineering works for chatbots but not for agents. Context engineering without intent engineering produces technically competent but strategically blind agents. Intent engineering without specification engineering works for individual teams but breaks at organisational scale.

As AI systems grow more autonomous, the locus of human influence migrates upward — from formulating individual queries, to designing informational environments, to encoding corporate goals, to formalising corporate knowledge. At each level the human role becomes more strategic and less tactical, more architectural and less artisanal.

This is not a transition from human control to machine autonomy. It's a transition from the ad hoc to the engineered.

---

References

1. Vishnyakova, V. V. (2026). "Context Engineering: From Prompts to Corporate Multi-Agent Architecture." arXiv:2603.09619. https://arxiv.org/abs/2603.09619

2. Feroz, F. (2026). "Your Prompting Skills Just Expired: The Four Disciplines That Actually Matter in 2026." Medium.

3. Reddy KS, A. (2026). "Intent Engineering in AI: The Shift Beyond Context Engineering." Tericsoft Blog. https://www.tericsoft.com/blogs/intent-engineering

4. Yao, S. et al. (2023). "Tree of Thoughts: Deliberate Problem Solving with Large Language Models." NeurIPS 2023. arXiv:2305.10601.

5. Anthropic. (2025). "Effective Context Engineering for AI Agents." https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

6. Google. (2025). "Architecting Efficient Context-Aware Multi-Agent Framework for Production." Google Developers Blog.

7. Tomašev, N., Franklin, M., & Osindero, S. (2026). "Intelligent AI Delegation." arXiv:2602.11865. https://arxiv.org/abs/2602.11865

8. Manus. (2025). "Context Engineering for AI Agents: Lessons from Building Manus." https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

9. Breunig, D. (2025). "How Long Contexts Fail and How to Fix Them." https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html

10. Eledath, B. (2026). "The 8 Levels of Agentic Engineering." https://www.bassimeledath.com/blog/levels-of-agentic-engineering

11. MindStudio. (2026). "Prompt Engineering vs Context Engineering vs Intent Engineering." https://www.mindstudio.ai/blog/prompt-engineering-vs-context-engineering-vs-intent-engineering/

12. Huryn, P. (2026). "The Intent Engineering Framework for AI Agents." Product Compass. https://www.productcompass.pm/p/intent-engineering-framework-for-ai-agents

13. Deloitte. (2026). "State of AI in the Enterprise" (7th ed.). N = 3,235.

14. KPMG. (2026). "AI at Scale: How 2025 Set the Stage for Agent-Driven Enterprise Reinvention." Q4 AI Pulse Survey.

15. OpenAI. (2026). "Harness Engineering: Leveraging Codex in an Agent-First World." https://openai.com/index/harness-engineering/

16. Boyd, C. (2026). "The Seven-Layer AI Agent Stack." https://chrisboyd.me/blog/the-seven-layer-ai-agent-stack/

17. CallSphere. (2026). "The Agent Evaluation Stack in 2026: From Trace to Eval Score." https://callsphere.ai/blog/agent-evaluation-stack-2026-trace-to-eval-score

18. AWS. (2026). "Evaluating AI Agents: Real-World Lessons from Building Agentic Systems at Amazon." https://aws.amazon.com/blogs/machine-learning/evaluating-ai-agents-real-world-lessons-from-building-agentic-systems-at-amazon/

19. CooperBench — referenced in the previous post: The Laws Don't Break, They Shift.

20. Ngo, S. et al. (2026). "ETCLOVG: A Survey and Taxonomy of Agent Harness Infrastructure." Carnegie Mellon / Yale / Amazon. See also: TrueFoundry, "ETCLOVG: The Seven-Layer Agent Harness Taxonomy, Mapped to a Production Runtime." https://www.truefoundry.com/blog/etclovg-agent-harness-reliability-gateway

21. United Nations University. (2026). "Engineering and Governing the Agent Harness: A Technology and Policy Framework for the Runtime Layer of Agentic AI." https://unu.edu/publication/engineering-and-governing-agent-harness-technology-and-policy-framework-runtime-layer

22. Redis. (2026). "The State of Context Engineering 2026." https://redis.io/resources/state-of-context-engineering-2026/