Drew Breunig published The State of Context Engineering on October 24, 2026, drawing on his AGNTCon talk, “Context Fails & Fixes.” The post presents slides and a lightly edited transcript about managing the information and capabilities available to AI agents.
Its six tactics are augmentation, tool loadout, quarantine, pruning, offloading, and summarization. This is an implementation map, not a new model release. The central engineering choice is where to use deterministic software rules and where to delegate decisions to probabilistic model behavior.
That distinction gives developers a useful way to review an agent: identify which information it may access, which judgments it may make, and which mistakes the surrounding software can contain.
Breunig supplies the framework and failure taxonomy. The control boundaries and examples below are editorial analysis of that framework, not tested recipes or evidence of measured reliability gains.
Context Capacity and Reliability Are Different Problems
Breunig describes four ways context can go wrong in the published transcript:
- Poisoning: A bad fact or hallucination enters the context and becomes difficult for the model to move past.
- Distraction: Growing context changes the model’s behavior, including how it draws on its underlying knowledge.
- Confusion: Extraneous information influences an answer even though it is unrelated to the task.
- Clash: Instructions, tools, skills, or other information conflict inside the agent’s harness.
These failures involve information quality, relevance, and consistency. A larger context window gives an agent more capacity, but capacity alone cannot determine whether a document belongs in the task or whether two instructions contradict each other.
Consider an agent investigating a software incident. Its context might contain the correct current runbook, an obsolete runbook, and a previous incident summary. Everything could fit while still leaving the agent with conflicting instructions.
The useful design question is therefore more specific than how much context to provide: which parts of that selection can the application enforce before the model reasons over them?
Deterministic controls apply explicit rules, such as checking a task identifier or enforcing a size limit. Model-driven decisions interpret meaning, such as deciding which incident resembles the current one. Both have a role. Neither should silently substitute for the other.
Augmentation and Tool Loadout Govern What Enters
Augmentation concerns the information added to a task. Tool loadout concerns the capabilities exposed to the agent. Treating those as separate decisions makes the boundary easier to inspect.
The following split is a proposed implementation approach:
| Tactic | What software can enforce | What the model can judge |
|---|---|---|
| Augmentation | Permitted sources, document versions, access filters, and context-size budgets | Which eligible passages help answer the current question |
| Tool loadout | Available tools, permitted operations, and argument validation | Which available tool is appropriate and when to request it |
For augmentation, a model could rank passages from an approved document collection. Application code could first filter that collection by customer, project, or software version. That puts semantic selection inside a defined information boundary.
For tool loadout, an agent assigned to investigate a problem might receive read-only inspection tools. A workflow requiring changes could expose additional capabilities under separate authorization.
I’d make eligibility a software responsibility whenever the rule can be stated explicitly. A model may judge a document highly relevant without recognizing that it belongs to another customer or an incompatible release.
Tool visibility also needs a separate execution boundary. Hiding a tool helps shape the agent’s choices, but authorization should still be checked when an operation is requested. Selecting an action and permitting it are different responsibilities, a distinction that also matters in coding-agent process control.
Quarantine and Offloading Separate Information by Role
Quarantine and offloading both involve boundaries, but they address different questions.
Quarantine asks which information should remain separate. An agent working on unrelated projects could use distinct task workspaces, with application code controlling which workspace supplies context. Within an assigned workspace, the model could still decide which records matter.
Offloading asks what must remain immediately available. A large tool response or completed research note could be retained outside the active context, with a reference available for later retrieval.
A conceptual workflow might look like this:
- Store a complete tool result in a task-specific record.
- Give the agent a compact description and a retrieval reference.
- Retrieve the relevant detail when a later step needs it.
This makes recoverability important. A reference should resolve to the intended record under the correct access rules. If a record has changed, version information can help distinguish the original evidence from its replacement.
My view is that offloading is most useful when it preserves a path back to evidence. Removing a long result from active context is a weak trade if the agent later has only an unsupported sentence describing what it supposedly contained.
Quarantine also needs an explicit rule for crossing boundaries. Copying an entire subtask transcript into a parent task may reintroduce information that separation was intended to contain. A narrower handoff could carry the result, supporting references, and unresolved questions.
Pruning and Summarization Decide What Survives
Pruning removes material. Summarization creates a shorter representation. Both can reduce active context, but they carry different risks.
| Tactic | Deterministic control to consider | Model-driven judgment to consider |
|---|---|---|
| Pruning | Retention rules, protected records, and removal of superseded entries | Which unprotected details are no longer useful |
| Summarization | Required fields, source references, and preservation of the original | Which events, decisions, and uncertainties deserve emphasis |
A pruning policy could protect the user’s current request and unresolved requirements while allowing completed intermediate work to leave the active window. Age alone would be a poor deletion rule if an early message contains the only statement of a critical constraint.
A summary could be required to include the current objective, completed actions, open questions, and evidence references. The model would still decide how to describe those items.
The distinction matters because shorter context can preserve the same mistake more efficiently. If a model treats a hypothesis as confirmed and writes it into a summary, reducing the token count has not repaired the reasoning.
For consequential decisions, I’d preserve the distinction between an observation, an inference, and an unresolved assumption. A statement such as “the service is unavailable” carries different weight depending on whether it came from a current tool result or an earlier guess.
Frequently Asked Questions
3 questions
1What Are the Six Context-Engineering Tactics?
Breunig lists augmentation, tool loadout, quarantine, pruning, offloading, and summarization. Together, they organize decisions about what enters an agent’s context, what remains separate, and what survives over time.
