Context Engineering for AI Agents: Compaction, Tool-Result Clearing and Memory

Why agents degrade as the context grows

Everything an agent does lands back in its context: each tool call, each tool result, each piece of its own reasoning, each user message. Nothing leaves unless something removes it. A coding agent that reads ten files, runs the tests four times and searches the codebase twice can be carrying tens of thousands of tokens of output that mattered once and are now noise.

Two costs follow. The obvious one is money and latency: you pay for every token on every call. The less obvious one is quality. Anthropic's documentation on context management describes it plainly: as the number of tokens in the window grows, a model's ability to accurately recall information from it decreases. This is often called context rot, and a larger window delays it rather than removing it.

So the goal is not to fit more into the window. It is to keep the window holding what the next decision needs.

Technique 1: clear old tool results

The cheapest technique is also the most underused. Once the agent has read a file and acted on it, the full file contents rarely need to stay. Tool-result clearing replaces old tool outputs with a short placeholder while keeping the record that the call happened, so the agent still knows it read the file and can read it again if it needs to.

It costs no extra model call, it is deterministic, and it removes the largest category of waste in most agent transcripts. The design choices are when to trigger it — a token threshold — and how many recent results to keep in full. Keep the last few; clear the rest.

• Clear: large file reads, search results, test output from earlier runs, API responses already acted on.
• Keep: the user's goal, decisions made and why, the current plan, the most recent results.
• Never clear anything the agent will need to quote exactly, such as an error it is still fixing.

Technique 2: compact the history

Compaction asks the model to summarise the conversation so far into a shorter form and continues from the summary. It is the right tool when the history itself — decisions, constraints, what has been tried — matters, but its raw form is too long.

Compaction is lossy, and the losses are not random. Summaries tend to keep conclusions and drop the reasons, and they can drop the signals that told the agent it was finished, so a compacted agent may redo work or wander. Treat compaction as a tool you instrument rather than a switch you turn on: track how many steps tasks take before and after enabling it, and whether outcomes change.

• Tell the summariser what to preserve: the original goal, constraints, decisions with reasons, open questions, and what has already failed.
• Compact at task boundaries where possible, not mid-step.
• Keep the original transcript outside the window so a human can audit what was summarised away.

Technique 3: move durable facts into memory

Some information should outlive the window entirely: a user's preferences, facts about the project, lessons from a previous session. Memory means writing those to an external store and retrieving them when relevant, instead of carrying them in every request.

The difficulty is not storage; it is deciding what is worth remembering and keeping it correct over time. That is a large enough topic to have its own article in this series, on long-term memory for agents.

Choosing between them

The three are layers, not alternatives. Most production agents need all of them, applied in order of cost.

• Start with tool-result clearing. It is free and usually removes most of the bloat.
• Add compaction for tasks that run long enough that even the reasoning history becomes too large.
• Add memory when information needs to survive across sessions, or when the same facts are being re-discovered every time.
• Put rules that apply to every request in the system prompt, and procedures that apply to some tasks in skills that load on demand.

Measuring whether it worked

Context engineering is easy to get wrong in ways that look like success: the token bill falls and the task success rate falls with it. Measure both.

• Tokens per completed task, not per call — clearing that causes re-reads can cost more than it saves.
• Task success on a fixed evaluation set before and after each change.
• Steps per task, to catch compaction making the agent repeat itself.
• A sample of long transcripts read by a human every week. Numbers will not tell you the agent forgot why it made a decision.

A worked example: a coding agent fixing a failing test

Picture a coding agent asked to fix a failing integration test. In the first ten steps it reads the test file, the module under test, two helper files and a configuration file, runs the test three times and searches the codebase for every caller of the function involved. By step ten the context holds five full files, three copies of a long test log and a page of search results — most of it no longer relevant, because the agent has already found that the bug is a date-parsing issue in one helper.

With tool-result clearing set to keep the three most recent results, the five file reads and the first two test logs are replaced by short placeholders recording what was read. The agent keeps the user's request, its own notes on what it has learned, the helper it is editing and the latest test output. If it later needs the configuration file again, it can read it again; the placeholder tells it the file exists and was already checked.

Now suppose the task grows: the fix exposes three more failing tests and the session runs to sixty steps. Here compaction earns its place. At a natural boundary — after the first test passes — the agent compacts the history into a summary that states the root cause, the fix applied, the files touched and the remaining failures. And because this team keeps meeting the same date-handling quirk, the agent writes one durable memory: the project stores timestamps in UTC and the helper must not apply a local offset. Next week, in a new session, that fact is retrieved instead of rediscovered.

Common mistakes

The techniques are simple; the ways they go wrong are worth knowing in advance.

• Clearing the evidence. Removing the error message the agent is still fixing forces it to re-run the failing command just to see it again.
• Compacting too early. Summaries made in the middle of a step lose the half-finished state the agent was relying on.
• Trusting a bigger window. Raising the context limit postpones the cost and quality problem; it does not solve it.
• Optimising blind. Changing context policy without a fixed evaluation set means you will only learn about regressions from users.