Minimal and Complete Model Context Design

An agent can fail because it does not have information required for the current operation. It can also fail while possessing that information because the useful signal is buried among irrelevant instructions, stale state, excessive history, and oversized retrieval results. The first is a completeness failure. The second is an efficiency failure.

These failures can produce similar symptoms: missed constraints, inconsistent answers, unnecessary tool calls, weak reasoning, or outputs that contradict known state. That similarity encourages the wrong response. Teams see an omission and add more context. When performance deteriorates, they remove material broadly. The architecture then oscillates between prompt stuffing and prompt starvation without establishing which information each operation actually requires.

Minimal and complete context design resolves the tension at the level of the model call. Completeness means that the active context contains every item needed to perform the operation correctly. Minimality means that it excludes material that does not contribute to that operation. Neither property can be defined for an agent in general. They must be defined for a particular decision, step, tool invocation, or handoff.

The architectural question is what this operation must know, what it may discover, and what should remain outside its working view. Context volume follows from those requirements.

Anthropic describes effective context engineering as finding the smallest set of high-signal tokens that maximizes the likelihood of the desired outcome. That framing matters because token reduction is not the objective by itself. A short context that omits a governing constraint is defective, not efficient.

The useful unit of design is a minimum viable context contract for each operation. The contract identifies the information that must be present before inference begins, the information that may be obtained during execution, and the evidence that should not enter the working context unless a condition makes it relevant.

XTrace’s minimum viable context framing treats prompts, memory, retrieval, tools, and prior outputs as parts of the agent’s context environment. Architects should evaluate each part according to its operational role rather than treating them as one accumulated prompt. For a given call, the required set may include:

• The immediate objective and expected output form
• The constraints that govern the current decision
• The authoritative state values on which the operation depends
• The tool definitions and permissions available at that step
• The specific source material needed to support the output
• The minimum prior result required to continue the workflow

The test is counterfactual. Remove one item and ask whether the operation could still produce a valid result under the conditions it may encounter. If removal creates a plausible path to an incorrect decision, the item is part of the minimum. If the call remains sound, the item is a candidate for exclusion, summarization, indexing, or on-demand retrieval.

This test also exposes a common category error: information can be important to the system without being necessary in every model call. A policy archive, customer history, code repository, or full workflow transcript may be essential to the agent’s overall capability. That does not make the entire asset part of the active context. System availability and model visibility are separate design decisions.

A practical context architecture separates material that is stable across calls from material whose relevance, freshness, or scope changes with the operation.

Static context usually includes system-level behavioral instructions, fixed operating rules, stable tool schemas, output conventions, and other material that applies repeatedly without being reconstructed from live state. Keeping this layer ordered and stable can also make it suitable for prefix caching where the model platform supports it.

Dynamic context includes the current task, authoritative state values, recent tool results, retrieved evidence, active entities, intermediate decisions, and handoff data. This layer must remain current, but freshness alone does not justify including all of it. Dynamic context should be compiled for the call from the subset of state and evidence relevant to the current operation.

Google’s description of the Agent Development Kit distinguishes durable Session state from the per-call Working Context presented to the model. The separation is architectural rather than cosmetic: storage can preserve a complete operational record while the model receives a deliberately scoped view. The same design also allows context transformations, filtering, compaction, and handoff rules to be made explicit and testable instead of being hidden inside ad hoc prompt concatenation.

This split prevents two forms of drift. First, stable instructions are less likely to be duplicated, reordered, or contradicted as dynamic prompts are assembled. Second, mutable task information is less likely to become embedded in a supposedly fixed prompt and survive after it is no longer true.

The split should not be implemented as two large text blocks. It is a lifecycle distinction. Each context element should have an owner, source of truth, refresh rule, scope, and inclusion condition. The model-facing prompt is then a compiled view of those elements, not the record in which the system stores them.

Some information is neither universally required nor safely disposable. It may become necessary depending on what the model finds, which branch the workflow takes, or which entity becomes relevant. Preloading all such material protects against omission but creates an efficiency failure. Excluding it entirely creates a completeness failure. Progressive disclosure provides the middle path.

Under this pattern, the agent begins with a minimal working context and a structured indication of what additional resources are available. It loads a document, record, policy section, schema, or prior result only when the current step requires that detail. MindStudio describes this as starting with the task definition and an index of available resources, then fetching supporting material dynamically as the workflow proceeds.

The index is important. An agent cannot request information it does not know exists. Progressive disclosure therefore requires enough discovery context for the model or orchestration layer to identify the next relevant resource without exposing the full contents of every resource in advance.

The pattern works best when disclosure conditions are architectural rather than left to vague model judgment. A workflow might expose a contract only after a disputed clause is identified, retrieve an entity record only after the entity is resolved, or load a tool’s extended documentation only when the basic schema is insufficient. These conditions can be based on workflow phase, entity identity, confidence thresholds, tool results, or explicit model requests validated by the orchestrator.

Scoped retrieval is the corresponding evidence pattern. The system should retrieve for the present question, entity, and decision boundary rather than asking a broad semantic search to fill the available context window. Retrieval quality is not measured by how much potentially related material it returns. It is measured by whether the returned slice is sufficient to support the current operation without obscuring the governing evidence.

Before changing prompt size, determine whether the agent lacked a required input or failed to use an input that was already present.

• Check presence: Was the missing fact, rule, state value, or source passage actually in the model-visible context for that call?
• Check authority: If it was present, was it distinguishable from stale, duplicated, or conflicting versions?
• Check prominence: Was the critical instruction or evidence embedded inside a much larger body of low-relevance material?
• Check timing: Did the information arrive before the decision that depended on it, or only later in the workflow?
• Check scope: Did the call receive history, entities, documents, or tool outputs unrelated to its immediate operation?
• Check discoverability: If detail was intentionally withheld, did the agent know that the resource existed and how to obtain it?

If required information was absent, the primary issue is completeness. The likely fixes are to repair the context contract, add a missing state projection, expose a resource index, or disclose the required material earlier. Adding unrelated history will not solve the problem.

If the information was present but competed with duplicates, stale records, or broad retrieval results, the primary issue is efficiency. The likely fixes are to narrow retrieval scope, remove redundant prompt material, isolate authoritative state, reduce handoff payloads, or move optional detail behind progressive disclosure. Removing the governing rule because the prompt is too large would treat the symptom by creating the opposite failure.

Some incidents contain both. A call may receive a large transcript yet still lack the current approval state. In that case, the correct response is to remove the irrelevant transcript and add the missing state projection, rather than compromise between adding and removing context.

This diagnostic also locates the responsibilities addressed elsewhere in the series. Authoritative state separation determines which values the model should trust — see Part 3. Normalized entity and context-slice design determines how the system constructs a coherent operation-specific view — see Part 4. Exact-source preservation determines when compression would destroy wording the decision depends on — see Part 5. Each solves a different route by which context becomes incomplete, ambiguous, or noisy.

• Part 1: Architectural Principles for Token-Efficient Agentic Systems
• Part 3: Authoritative State Must Live Outside the Model Context
• Part 4: Normalized Entities and Context Slices Beyond Chunk Retrieval
• Part 5: Preserving Exact Source Wording in LLM Systems

Browse the full Architectural Insights series →

• Anthropic, "Effective context engineering for AI agents"
• XTrace, "Minimum Viable Context: What Your AI Agent Actually Needs to Know"
• MindStudio, "Progressive Disclosure in AI Agents"
• Google Developers Blog, "Architecting efficient context-aware multi-agent framework for production"