Why Your Agent Forgets Step 2 by Step 7 — And Four Ways to Keep the Thread
Agents rarely fail because they reason badly — they fail because the original instruction gets buried under accumulated tool output. Here's how to tell displacement from dilution, and four fixes that keep the thread intact.
An agent starts a task correctly. It reads the requirements, plans six steps, and executes the first two cleanly. By step seven it is confidently doing something the requirements ruled out on line three. Nothing errored. No tool failed. The agent simply stopped knowing what it was doing.
This is the most common failure in multi-step agent work, and it is almost never a reasoning problem. It is a context problem.
Where the thread actually gets dropped
Each turn of an agent loop appends to the conversation: the model's reasoning, the tool call, and the tool's response. Tool responses are the expensive part. A file read returns hundreds of lines. A search returns ten results with snippets. A database query returns rows.
After seven steps, the original instruction sits at the top of a transcript dominated by intermediate output. It is still technically in the context window, but it is now a small fraction of what the model is attending to, buried under material that is louder, more recent, and more concrete.
Two distinct things go wrong here, and they need different fixes:
Displacement. The instruction is pushed out of the window entirely by accumulated tool output. This is a hard limit and it is easy to detect — you can measure it.
Dilution. The instruction is still present but no longer salient. Recent content dominates. This is the harder one, because nothing looks broken. Token counts are fine. The agent just quietly weights the last tool result above the constraint it read at the start.
Most teams instrument for displacement and get blindsided by dilution.
Fix one: restate the goal every turn
The cheapest intervention. Instead of relying on the original instruction staying influential, re-inject a compact version of it into every turn — as a system-level reminder or a short block prepended to the latest message.
Not the full original prompt. A condensed statement of the objective plus the hard constraints:
Objective: migrate the auth module to the new session API.
Constraints: do not modify database schema; do not touch files outside /auth.
Completed: read config, mapped call sites.
Remaining: rewrite handlers, update tests.
The cost is a few dozen tokens per turn. The benefit is that the constraint is always among the most recent content, competing on equal footing with tool output rather than losing to it by position.
Fix two: summarize tool output before it enters context
Raw tool output is the primary source of bloat, and most of it is never needed again. An agent that reads a 400-line file to find one function signature does not need all 400 lines in context for the remaining steps.
Two approaches, and the difference matters:
- Summarize on write — pass tool results through a compression step before appending them. Faster context growth control, but you lose detail permanently and you pay a model call each time.
- Store and reference — write the full result to a scratchpad file or key-value store, and put only a handle plus a one-line description in context. The agent can re-read the full content if a later step needs it.
The second is more work to build and considerably more robust. It converts context pressure into a retrieval problem, which you can solve, instead of an information-loss problem, which you cannot.
Fix three: checkpoint the state, not the transcript
The transcript is a log of how the agent got here. The state is what it currently knows and still needs to do. Only the second one has to survive.
Maintain an explicit state object the agent updates after each step — findings so far, decisions made, open questions, next action. When context gets long, you can discard most of the transcript and rebuild a fresh, short context from the state object plus the original objective.
This is the difference between an agent that degrades linearly with task length and one that resets to near-full clarity at every checkpoint. It also gives you something to inspect when a run goes wrong, which the raw transcript rarely provides.
Fix four: end the task before it gets long
The most reliable fix is structural. An agent that needs twenty steps is usually one that should have been three agents needing seven each, or a single agent whose task was scoped too broadly.
Long-horizon tasks fail more often than short ones, and not gradually — reliability tends to fall off sharply once a task runs past the point where the whole picture fits comfortably in context. Splitting a task at a natural boundary, with a clean handoff carrying only the objective and the accumulated state, restarts the clock.
The tradeoff is real: each split adds a handoff, and handoffs lose nuance. Split at boundaries where the interface is naturally narrow — "research is complete, here are the findings" transfers cleanly; "I'm halfway through a refactor" does not.
Diagnosing it in your own system
When a run goes off the rails, pull the transcript at the step where behavior first diverged and ask three questions:
- Was the original constraint still in the context window at that step? If not, it is displacement — fix with summarization or checkpointing.
- If it was present, what fraction of the context was tool output? Past roughly half, assume dilution and start restating the objective.
- Did the agent's own reasoning at that step mention the constraint at all? If it stopped referencing something it used to reference, that is the signature of dilution, and it is usually visible several steps before the visible failure.
That last signal is the useful one. Agents typically stop talking about a constraint before they start violating it, which means the failure is detectable while there is still time to intervene.