better models, bigger context windows, and more capable agents. But most real-world failures don't come from the model's capabilities – they come from how the context is built, passed, and maintained.
This is a difficult problem. The space is moving fast and the techniques are still evolving. Much of it remains experimental science and depends on context (pun intended), limitations and the environment you are working in.
In my work building multiple agents, a recurring pattern has emerged: performance is less about how much context you give the model, and more about the method. directly he shapes it.
This piece is an attempt to make the things I learn into something you can use.
It focuses on the principles of managing context as a constrained resource – deciding what to include, what not to include, and how to organize information so that agents remain relevant, efficient and reliable over time.
Because at the end of the day, the strongest agents aren't the ones that see the most. They are the ones who see the right things, in the right situation, at the right time.
Names
Content engineering
Content engineering is the art of providing the right information, tools and format to the LLM to complete the task. Good context engineering means finding a very small set of high-signal tokens that give the LLM a high probability of producing a good result.
In practice, good context engineering often comes down to four paths. You take out information on external systems (content upload) so the model does not need to carry everything in the band. You bring it back information dynamically instead of preloading everything (to retrieve the context). You separate context so that one small task does not pollute another (context classification). You too reduce history when needed, but only in ways that preserve what the agent will need later (reduce context).
A common failure mode on the other hand context pollution: the presence of too much unnecessary, conflicting or unnecessary information that interferes with the LLM.
Content decay
Content decay is a situation where the performance of LLM degrades as the content window fills up, even if it is within a set limit. The LLM still has room for further study, but its reasoning is beginning to fade.
You wouldn't notice that the active content window, where the model renders at high quality, is often much smaller than what the model is capable of.
There are two parts to this. First, the model does not keep track of its entire context window. Information at the beginning and end is remembered more reliably than things in between.
Second, large context windows do not solve the problems of business systems. Business data is not effectively defined and updated so often that even if a model can import everything, that doesn't mean it can keep a consistent understanding of it.
Just as humans have a limited working memory capacity, every new token introduced to LLM depletes this available attention budget by some amount. The lack of attention is caused by structural constraints in the transformer, where every token looks at every other token. This leads to an interaction pattern of n² for n tokens. As the context grows, the model is forced to spread its attention less and less across multiple relationships.
Content density
Content density is a common response to context decay.
When the model approaches the limit of its content window, it collapses its content and restarts a new context window with the previous summary. This is especially useful for long-running tasks to allow the model to continue running without much performance degradation.
Recent context-wrapping work offers a different approach – agents actively control their context of operation. An agent can branch off to handle a subtask and then collapse when it's done, collapsing intermediate steps while keeping a brief summary of the result.
The difficulty, however, is not in summarizing, but in determining what is living. Some things should remain stable and almost change, such as the purpose of the work and the difficult problems. Some can be safely disposed of. The challenge is that the value of information is often revealed later.
So good integration needs to preserve the facts that continue to constrain future actions: which methods have already failed, which files have been created, which assumptions are invalid, which handles can be updated, and which uncertainties remain unresolved. Otherwise you get a neat, short summary that's human-readable and useless to the agent.
Agent's harness
A model is not an agent. The harness is what turns the model into one.
By harness, I mean everything around the model that determines how the context is compiled and saved: rapid serialization, toolpath, retry policies, rules governing what is saved between steps, and so on.
When you look at real agent systems this way, many of the so-called “model failures” now look different. I have encountered many such at work. This is actually a failure of the harness: the agent was forgotten because nothing persisted in the right situation; it works again because the harness has not been a strong art of previous failures; chose the wrong tool because the harness overloaded the action space; and so on.
A good harness is, in a sense, a deterministic shell wrapped around a stochastic backbone. It makes the context readable, stable, and reproducible in such a way that the model can use its limited thinking budget for work instead of reconstructing its own state from dirty traces.
Communication between agents
As tasks become more complex, teams have automated to multi-agent systems.
It is a mistake to think that multiple agents imply a shared context. In fact, dumping a large script that is shared across all sub-agents tends to create the exact opposite of professionalism. Now every agent reads everything, inherits everyone's mistakes, and pays the same context fee over and over again.
If only a certain context is shared, a new problem arises. What is considered authority if the agents disagree? What is left of the property, and how are disputes resolved?
The way out is to handle connections not as shared memory, but as transfer of state through well-defined interfaces.
For discrete tasks with clear inputs and outputs, agents often have to communicate through artefacts rather than trace. A web search agent, for example, does not need to go through their entire browsing history. It only needs to display objects that can be used by the agents below.
This means that average reasoning, failed attempts, and test tracking remain private unless clearly necessary. What is carried forward are stripped-down results: extracted facts, confirmed findings, or decisions that prompt the next step.
For tightly coupled tasks, such as a debugging agent where the downstream logic really depends on previous attempts, a limited path sharing approach can be implemented. But this should be deliberate and tested, not automatic.
KV cache fine
When AI models generate text, they often repeat the same math. KV caching is a hint timing optimization that speeds up this process by remembering important information from previous steps instead of recalculating everything again.
However, in multi-agent systems, if each agent shares the same context, you clutter the model with a ton of irrelevant information and pay a huge KV cache penalty. Multiple agents working on the same task need to communicate, but this should not be by sharing memory.
This is why agents must communicate small, systematic results in a controlled manner.
Keep the agent's tool set small and consistent
Tool selection is a context problem disguised as a power problem.
As the agent accumulates more tools, the action space becomes harder to navigate. Now there is a high probability that the model will descend into the wrong action and take an ineffective route.
This has consequences. Tool schemes need to be more diverse than most people realize. The tools should be well understood and have little conflict in practice. It should be very clear what their intended use is and have clear and unambiguous input parameters.
One common failure mode I've noticed even on my team is that we tend to have more advanced sets of tools added over time. This leads to unclear decisions about which tools to use.
Agent memory
This is an aa process where the agent always writes persistent notes to memory outside of the context window. These notes are pulled back into the content window over time.
The hardest part is deciding what is worth promoting to memory. My rule of thumb is that long-term memory should contain things that continue to compel future thinking: persistent favorites. Everything else should have a very high bar. Storing more is just another way back to context pollution, only now it's more persistent.
But memory without revision is a trap. If agents insist on notes at all steps or times, they need methods for conflict resolution, removal, and reduction. Otherwise long-term memory becomes a dumping ground for outdated beliefs.
In short
Content engineering is still evolving, and there's no one right way to do it. Much of it is always operational, the systems we build and the constraints we work under.
If left unchecked, the core expands, drifts, and eventually collapses under its own weight.
When managed well, context becomes the difference between an agent that simply responds and one that can think, adapt, and stay connected throughout long and complex tasks.
