Less context

When an agent gets something wrong, it's tempting to add more context. Another document, one more example, an extra instruction. Sometimes that helps. Often it just makes the task harder to read.

Context engineering starts with selection. The agent needs the material that helps with the current task, not everything that might be related to it.

When extra context gets in the way#

Models don't judge context the way people do. If you send the entire repository, old rules, examples, and documentation all end up in the same window. The important instruction now has to compete with everything else.

Some problems show up often:

• Dilution: each new item takes up space and makes the important material less prominent.
• Conflicts: an old document may say one thing while the current rule says another. The model has to guess which one applies.
• Lost in the middle: in long contexts, material near the middle tends to be retrieved less consistently.

Before adding something, check whether it helps the agent make a decision or only gives it more material to sort through.

Cut what the task doesn't need#

In practice, a narrow scope usually works better. Send the relevant file instead of the whole repository, the function involved instead of the entire module, and the rule that applies now instead of a complete manual.

That doesn't mean hiding important information. It means leaving out material that doesn't help with the next decision. If another piece becomes necessary, you can add it later.

Use subagents for broad searches#

Some tasks need a broad sweep, such as finding a pattern across dozens of files or understanding a convention spread through the project. Putting all of that material into the main context is expensive and rarely useful, because most of it will be discarded once the search is done.

In those cases, I delegate the sweep to a subagent and ask for a short answer: the relevant files, line numbers, and a conclusion. The main agent gets the result without carrying the full path used to reach it.

The search runs in a separate window, leaving the main context available for the decision and the implementation.

What is worth keeping#

Rules that remain valid belong in the project context file or memory. They enter once and stay available for future tasks.

Details that only matter to one task can leave when the task is done. If every detail becomes permanent memory, the noise returns in future conversations and the context file stops being useful.

Context has limits#

Every item takes up part of the window and competes for attention. This is why long conversations also benefit from a summary. Keep the decisions, the current state, and the next steps. The reasoning that has already served its purpose can go.

Before sending more material, I try to summarize the task and remove what is no longer useful. Most of the time, that cleanup helps more than another document.