Go back

How Does Context Engineering Drive Multi-Agent Reliability?

• Updated
14 min read

In June 2025, Shopify CEO Tobi Lütke introduced the term “context engineering” as a more precise alternative to prompt engineering: “the art of providing all the context for the task to be plausibly solvable by the LLM” (Lütke, June 18, 2025). Andrej Karpathy amplified the definition a week later with nearly identical framing. The definition arrived because the problem had outgrown its old name. Prompt engineering implies craft; context engineering implies architecture. For platform teams deploying multi-agent systems, that distinction is the difference between a fragile prototype and a reliable production system. A third discipline, harness engineering (Hashimoto, Lopopolo, February 2026), governs the execution runtime that wraps the model. Context engineering governs the window that runtime assembles. The two are cumulative layers, not a succession; this post covers the context layer.

Three failure modes account for the majority of production incidents: context accumulation, context starvation, and context leakage. Each has a distinct fingerprint, a detection signal, and a remediation pattern. The remainder of this post defines them precisely and proposes a design framework for suppressing all three.

Table of contents

Contents

What Is Context Engineering and Why Does It Matter Now?

Context engineering is the systematic design of what information a model sees at inference time. Anthropic (September 2025) defines it as “the set of strategies for curating and maintaining the optimal set of tokens during LLM inference,” alongside two platform primitives: context editing and a memory tool. That includes the system prompt, retrieved documents, tool outputs, conversation history, structured state, and any other tokens present in the model’s context window when it generates a response. Prompt engineering, by contrast, focuses on the wording of a single instruction. The scope difference is roughly analogous to the difference between writing a function signature and designing a database schema.

As an infrastructure discipline, context engineering shares the same properties as other platform concerns: it must be observable, testable, and subject to capacity constraints. A context window is a finite resource. Every token consumed by irrelevant history is a token unavailable for the signal the current task requires. Vishnyakova (2026) frames context as the agent’s operating system, proposing five quality criteria: relevance, sufficiency, isolation, economy, and provenance. That framing is useful because it makes the engineering trade-offs explicit.

The business imperative is timing. Vishnyakova cites Deloitte 2026 survey data indicating that approximately three in four enterprises plan agentic AI deployment within two years, alongside KPMG findings showing that early deployment waves have already contracted as organizations confront scaling complexity. The teams that avoided that contraction treated context as a first-class infrastructure concern from the start.

How Does Context Engineering Relate to Harness Engineering?

In February 2026, Mitchell Hashimoto (HashiCorp co-founder) formalized a parallel discipline he called harness engineering, summarized by the formula Agent = Model + Harness (Hashimoto, February 5, 2026). Days later, OpenAI engineer Ryan Lopopolo published a field report from shipping a production codebase with zero manually written lines of code, using the same vocabulary (Lopopolo, February 11, 2026). The harness is everything that wraps the model except the model itself: tool execution, multi-session state management, error recovery loops, permission enforcement, sandboxing, and session lifecycle. The core principle: whenever an agent makes a mistake, you engineer the environment so it cannot make that mistake again.

The relationship between the two disciplines is not a replacement hierarchy. Fowler and Böckeler put it directly: “Context engineering provides us with the means to make guides and sensors available to the agent. Engineering a user harness for a coding agent is a specific form of context engineering” (Fowler / Böckeler, 2026). The disciplines address different failure modes at different scopes. Context engineering governs what the model sees at each inference step: the window layer. Harness engineering governs the runtime that assembles that window and acts on its output: the system layer. A well-engineered harness that ignores context quality will still accumulate stale tokens, starve agents of relevant signal, and leak state across boundaries. Neither discipline is optional; neither supersedes the other.

The claim that “context engineering is outdated” conflates chronology with containment. The fact that harness engineering was named in 2026 does not make the 2025 discipline obsolete, for the same reason that distributed systems engineering did not make database schema design obsolete. The 2026 TMLR-track survey “Agent Harness Engineering: A Survey” (Li, Xiao, Zhang, Liu et al.) proposes a seven-layer taxonomy (Execution, Tool, Context, Lifecycle, Observability, Verification, Governance) where context management is an explicit layer inside the harness stack, not a predecessor to it. This post covers that context layer. A harness without it fails on the same three modes documented here.

What Are the Three Failure Modes of Context in Multi-Agent Systems?

Failure modes in multi-agent context management follow a consistent pattern across production systems. Each can be diagnosed from observable symptoms before it causes a task failure.

Table 1: Failure mode reference.
Failure ModeObservable SymptomDetection Signal
AccumulationDegrading accuracy on identical subtasks over time; increasing token cost per stepAccuracy drops as context length grows; latency increases non-linearly
StarvationAgent requests clarification on information already retrieved; retrieval precision degradesRelevant chunks absent from context at decision time; U-shaped accuracy curve
LeakageAgent actions reflect information from a sibling agent’s scope; cross-task contaminationState from one pipeline step persists into another; privacy boundary violations
Table 2: Failure mode remediation and sources.
Failure ModeRemediation PatternLiterature Anchor
AccumulationContext compression; sliding window; periodic summarizationYi et al. AdaCoM (2026); Chroma “Context Rot” (2025)
StarvationRetrieval audit; chunk overlap tuning; context budget allocationLiu et al. “Lost in the Middle” (2024)
LeakageTyped context slots; explicit boundary enforcement; audit log diffingThoughtworks / Bayer AG PRINCE (2026)

Why Does Accumulation Turn More Context Into Less Signal?

Chroma Research (Hong, Troynikov, Huber, 2025) tested 18 frontier models, including GPT-4.1, the Claude 4 family, Gemini 2.5, and Qwen3, across context lengths from 1K to 1M tokens. Every model degraded with input length, even on simple tasks, well before advertised window limits were reached. In some conditions, accuracy drops exceeded 30%.

Yi et al. (2026) label this the Fidelity-Reliability Trade-off: preserving more context fidelity degrades reliability. Their AdaCoM system trains an external context manager via reinforcement learning to compress and prioritize context adaptively, without modifying the underlying agent, making it applicable to closed-source models. The effect is not uniformly negative: repeating a question in context can improve recall accuracy by double digits even when paired with a wrong answer, because repetition re-anchors model attention. What accumulates matters as much as how much accumulates.

Why Does Starvation Leave the Agent Unable to See What It Needs?

Context starvation is the inverse problem: retrieval succeeds, but placement fails. Liu et al. (2024, TACL) document a U-shaped degradation pattern: models perform best when relevant information appears at the very beginning or very end of the context, and worst when it is buried in the middle. In long-context multi-agent pipelines, the middle is where most retrieved content lands.

The consequence is failures that look like retrieval failures but are positioning failures: the chunk was retrieved, then placed where the model attends least. Fixing retrieval recall does not fix the problem; context budget allocation and chunk ordering do.

Why Does Leakage Occur When Context Crosses Agent Boundaries?

Shared memory stores and insufficiently scoped prompts are the two most common causes: an agent completing a research subtask may expose proprietary source material or intermediate reasoning to a downstream agent that has different authorization, audience, or role constraints.

The Bayer AG PRINCE system, documented by Thoughtworks / Bayer AG (Fowler, publisher, 2026), uses a structured harness with explicit control points for recovery, inspection, evaluation, and human intervention. That architecture enforces boundary conditions that an unconstrained autonomous agent cannot. PRINCE scored 3.1/5.0 in live evaluation, indicating that even production-hardened systems face persistent reliability gaps when context boundaries are not designed in from the start.

How Does Context Isolation Prevent Failure at Scale?

Context isolation works by giving each agent role exactly the context subset its task requires, defined at design time as a named, typed container.

In a standard three-role pipeline, the planner receives the schema, the user query, and the workflow specification. The researcher receives retrieved document chunks and the research question. The writer receives the citation set, the output constraints, and the structured summary from the researcher. None of the three receives the full workflow history. The Anthropic “Building Effective Agents” guide (Schluntz, Zhang, 2024/2025) describes this pattern as “context window protection”: sub-agents handle specialized tasks without polluting the main agent’s context, creating clean separation of concerns.

Code Snippet 1: Context slot definition for a multi-agent pipeline.
from dataclasses import dataclass
from typing import Any, Literal

AgentRole = Literal["planner", "researcher", "writer"]

@dataclass
class ContextSlot:
    role: AgentRole
    schema: str | None = None
    query: str | None = None
    chunks: list[str] | None = None
    citations: list[str] | None = None
    constraints: str | None = None

def route_context(full_state: dict[str, Any], role: AgentRole) -> ContextSlot:
    if role == "planner":
        return ContextSlot(role=role, schema=full_state["schema"], query=full_state["query"])
    if role == "researcher":
        return ContextSlot(role=role, chunks=full_state["retrieved_chunks"], query=full_state["query"])
    return ContextSlot(role=role, citations=full_state["citations"], constraints=full_state["constraints"])context_router.py

A routing function enforces context isolation by dispatching only the relevant subset to each agent slot.

Pipeline isolation: context router dispatching subsets to planner, researcher, and writer agents
Figure 1: Each agent receives exactly the context its role requires. None receives the full workflow history.

The PRINCE case study illustrates what isolation looks like at production scale. The system’s structured harness is not merely a logging layer; it is the mechanism by which context boundaries are enforced between pipeline stages. The 3.1/5.0 live evaluation score (Thoughtworks / Bayer AG, 2026) reflects the difficulty of the preclinical data domain, and underscores that isolation is necessary but not sufficient: it removes a class of failures without replacing measurement.

Anthropic’s guidance reinforces this operationally: developers should literally inspect the agent’s context window at decision time. Agents frequently fail from information asymmetry rather than model capability limits (Anthropic, 2024/2025); typed slots are the enforcement mechanism.

How Do You Measure Context Quality in Production?

Four metrics cover the space of context quality concerns in production multi-agent systems. Each maps to one of the failure modes from Section 2.

Which Metrics Should You Instrument First?

Table 3: Context quality metrics.
MetricWhat It MeasuresTarget ThresholdTool / Method
Context freshness ratioFraction of context tokens within the recency window> 0.80 for time-sensitive tasksToken timestamp audit; TTL-tagged chunk store
Inter-agent leakage rateRate of one agent’s tokens leaking to another< 0.01 (near-zero)Context diff between consecutive agent invocations
Retrieval precision at kFraction of top-k retrieved chunks relevant to subtask> 0.70 at k=5Human or LLM-as-judge relevance scoring on sampled traces
Task success deltaAccuracy change between full-context and scoped-context agent runsPositive delta confirms isolation improves performanceA/B evaluation on held-out task set

The 0.80 freshness threshold derives from the Chroma degradation curve, where accuracy loss accelerates below that ratio.

How Do You Implement a Context Guard?

Code Snippet 2: Context freshness check.
from datetime import datetime, timedelta, timezone

MAX_CONTEXT_AGE_HOURS = 4

def is_context_fresh(chunk_timestamp: datetime | None, reference_time: datetime | None = None) -> bool:
    if chunk_timestamp is None:
        return False
    now = reference_time or datetime.now(timezone.utc)
    age = now - chunk_timestamp.replace(tzinfo=timezone.utc) if chunk_timestamp.tzinfo is None else now - chunk_timestamp
    return age <= timedelta(hours=MAX_CONTEXT_AGE_HOURS)

def filter_stale_chunks(chunks: list[dict], reference_time: datetime | None = None) -> list[dict]:
    return [c for c in chunks if is_context_fresh(c["timestamp"], reference_time)]context_guard.py

A freshness guard prevents accumulation by rejecting stale context before injection.

Freshness ratio and leakage rate are instrumentable at the infrastructure layer without changing agent behavior. Retrieval precision at k requires sampling: logging 5-10% of agent invocations, scoring retrieved chunks against the task query, and computing precision over time. Task success delta requires a baseline on a held-out evaluation set. The PRINCE team’s live evaluation methodology (Thoughtworks / Bayer AG, 2026) demonstrates that structured evaluation is feasible in production drug-development workflows, where the cost of a wrong answer is measurable.

What Does Context-First Design Look Like in Practice?

Context-first design is a sequence of four decisions made before any agent is implemented.

First, define the context budget: the maximum token allocation for each agent role, derived from the model’s effective context window, not its advertised limit. Second, define the context slots: named, typed containers specifying which categories of information each role is authorized to receive. Third, wire the routing: implement a context router that enforces slot boundaries at every inter-agent handoff. Fourth, instrument the metrics: deploy freshness checks, leakage monitors, and retrieval precision logging before the system handles real traffic.

How Do You Triage a Detected Failure?

Failure mode decision tree: observable symptom leads to failure mode label leads to remediation pattern
Figure 2: Identify the failure mode first; remediation follows from diagnosis.

When an agent pipeline fails, use this decision tree to pinpoint the context breakdown and select the appropriate guardrail.

Takeaways

  1. Context engineering is infrastructure. The information environment at inference time is a platform concern, not a prompt concern. Treat it with the same discipline as schema design or capacity planning.
  2. Three failure modes cover most production incidents. Accumulation degrades accuracy over time; starvation leaves critical information out of the window; leakage crosses agent boundaries. Each has a distinct detection signal and remediation pattern.
  3. Isolation is the primary control. Named, typed context slots enforced at every inter-agent handoff address all three failure modes. The Anthropic and PRINCE case studies both converge on structured separation as the enabling architectural pattern.
  4. Measure before optimizing. Freshness ratio, leakage rate, retrieval precision at k, and task success delta are the four metrics that cover the space. Define a minimum detectable threshold before running at scale: a small pilot that fails to show the expected signal is cheaper to stop than a full-scale run that surfaces the same finding after 10x the cost.
  5. Design context budgets from observed degradation curves, not advertised limits. Chroma Research data showing accuracy drops exceeding 30% before window limits are reached means that advertised context window sizes are not safe planning assumptions.
  6. Context engineering and harness engineering address different failure modes. Harness engineering (Hashimoto, Lopopolo, February 2026) governs the runtime: tools, sessions, error recovery, permissions. Context engineering governs the window that runtime assembles. A well-engineered harness that skips context quality discipline will still accumulate, starve, and leak. Neither discipline supersedes the other.

References

Previous Post
Open-Weight LLMs Reach the Structured Output Quality Ceiling

Related Posts