The standard advice on Context Engineering for AI Agents has settled on “just increase the context window,” and it is quietly wrecking performance. It is the same mistake I see when a developer fixes a slow WordPress site by throwing RAM at a bloated database instead of indexing the queries. A bigger window does not repair broken logic. It usually amplifies it.
Building multi-agent systems taught me that performance depends much less on how much context a model gets and much more on how precisely that context is shaped. Dump one giant shared transcript into every sub-agent and what you get is a distracted generalist with a heavy KV-cache bill, not a specialist.
The anatomy of context rot
Most developers treat the context window as an infinite bucket. Every token you add spends part of the model’s “attention budget.” That constraint is baked into the transformer: every token attends to every other token, which gives you an n² interaction pattern. The more context there is, the thinner the model has to spread its attention.
That is where Context Rot comes in. The model’s reasoning starts to blur while it is still inside the stated limit. Recall tends to hold up at the beginning and the end of a prompt, and the middle turns into a “lost in the middle” graveyard. In the WordPress world we would call it a performance bottleneck, and in Context Engineering for AI Agents it is the main reason agents fail.
Context compaction, the “transient” of AI
More space is not the answer. Context Compaction is. As a model approaches its limit, stop appending: summarize, then reinitiate. It works like the WordPress Transients API, where you store a processed version of expensive data so the whole logic tree does not get recomputed every time.
Recent research on context folding argues that agents should manage their working context as they go. An agent branches off to handle a subtask, then folds it once the subtask is done, dropping the messy intermediate steps and keeping a short summary of the outcome.
Agents do better when they see the right thing, in a usable form, at the moment they need it than when they simply see more.
The agent harness as a deterministic shell
A model on its own is not an agent. The Agent Harness is the deterministic wrapper around a stochastic core, and it handles tool routing, retry policies, and prompt serialization. When an agent repeats work, the model is rarely the culprit. The harness is, because nothing persisted the state of the earlier failure.
The harness is also what keeps the action space small. A bloated functions.php makes a theme unmaintainable, and a bloated toolset makes an agent indecisive in much the same way. Keep the tool schemas distinct and tied to the subtask in front of the agent.
Communication between agents
Complex tasks push us toward multi-agent systems, and the usual assumption is that more agents need shared memory. What they need is State Transfer through well-defined interfaces. Anthropic’s Model Context Protocol (MCP) is a step toward standardizing that interaction so agents are not drowning in each other’s raw traces.
Agents should talk to each other in Artifacts rather than raw traces. A search agent has no reason to hand over its whole browsing history when the distilled facts are the part that matters. That keeps prompt caching efficient and keeps the context from getting polluted.
If context engineering for your agents is eating your dev hours, hand it to me. I have been wrestling with WordPress and complex logic since the 4.x days.
What this comes down to
Context engineering is still an empirical science. Leave it alone and context grows, drifts, and eventually collapses. Reliable agents come from treating context as a finite resource: offload what you can to external systems, retrieve on demand, and compact aggressively.
