Context engineering is a permanent discipline, not a configuration problem

Context engineering is a permanent engineering discipline, not a configuration problem you solve once and move past. That's the core argument in dbreunig's AGNTCon talk on context fails and fixes, and it's the right frame for anyone building AI-powered products.

The reason it stays hard isn't that the tools are immature—it's that models aren't people. Their construction creates failure modes that are qualitatively different from any other software dependency you manage. When a model grows convinced it needs to give a game guard iced tea instead of lemonade—because the FireRed variant was in its training weights, not the original game it was actually playing—it doesn't just make a mistake. It pursues that mistake for hours, unable to escape. That's context poisoning, and it scales with capability.

The failure modes change, the toolbox doesn't

What's genuinely useful in the talk is the observation that the six core tools—context augmentation, tool loadout, quarantine, pruning, offloading, and summarization—have stayed stable even as the failure modes have evolved. Long context windows created poisoning and distraction problems. Agentic training created "fighting the weights" and context inertia. The fixes remained the same set of moves, assembled differently.

Context inertia is the newest named problem: a model hyper-focuses on a hypothesis or subtask and keeps pursuing it after it should stop. Research from Anthropic, Microsoft Research, and a UC Berkeley paper titled "Scaling Discovery Requires Forgetting" all arrived at the same fix independently: periodically clear the running context while preserving the artifacts in the environment. The model gets a fresh perspective; the work doesn't disappear.

The UC Berkeley data makes this concrete—periodic resets produce successive jumps in research agent performance. The same pattern that fixes distraction in a coding session also fixes inertia in a long-running research loop. It feels like a workaround. It isn't.

What this means for how we build

The framing that closes the talk is the most actionable: our output is the product of the context and the weights. You can improve the weights—expensive, slow—or you can improve the context. One of those is fast and cheap.

For small teams, this translates into a concrete discipline. Read the technical reports for the models you use, including the appendices. Dbreunig notes that Gemini 2.5's long-context degradation—once the context grew significantly beyond 100,000 tokens, the agent began repeating actions from its history instead of synthesizing new plans—was documented in an appendix the marketing team apparently never read. Monitor context size actively; he uses 200,000 tokens as a personal warning point. When an agent starts behaving strangely, ask how large the context is before assuming the model has regressed.

Also understand the model's training environment. When a model was trained on largely serial workflows, it will resist parallel tool calls. You'll see the evidence in system prompts that repeat the same instruction seven times in all-caps—that's fighting the weights, and you have to design around it deliberately.

Every capability gain shifts the boundary between what belongs in code and what belongs in the model. The job of context engineering is to keep that boundary deliberate rather than accidental. It won't stop being a job.

Sources

• The State of Context Engineering (original)
• Found via the TLDR newsletter