Context rot: when to shorten or restart an AI session

Imagine a coding agent that has read more files and tried three fixes, yet still returns to an explanation you already ruled out. Another “try again” may repeat the same work. First check what the next attempt would inherit from the conversation.

Notice whether new evidence changes the next action#

A useful session responds to evidence. A failing test leads the agent to inspect relevant code. A result that disproves a guess changes the investigation. The agent can identify what it still needs to check.

Practitioners sometimes call this the smart zone. The dumb zone describes a session where the accumulated input gets in the way: the agent repeats abandoned work, revives a rejected explanation or makes unrelated edits. These are informal labels, not physical regions of a model’s input.

In the illustrative upload bug below, a file at the agreed size limit is rejected. The agent keeps editing browser code even though a direct server request fails too. The useful reset preserves that observation and separates it from the earlier browser-only explanation.

A

The conversation so far

What the session currently mixes together.

• Requirement At the size limit: accept.
• Evidence The server rejects the boundary request.
• Unproven explanation “The browser must be wrong.”

The wrong next stepPatch the browser again.

B

The next session's brief

What the next agent needs to know.

• Keep the requirement At the size limit: accept.
• Keep the evidence The server rejects the boundary request.
• Expose the uncertainty The browser cause is unproven.

A checkable next stepInspect the server validation path.

Check and select→

Outside the new conversationThe full logs and three client-side edits still exist. Reference the logs; inspect the saved diff.

Illustrative example: a reset changes the working context, not the repository or the evidence.

The better brief does not declare that the server code must be wrong. It identifies what to investigate next. Replacing one unsupported guess with another would not fix the problem.

Fitting more text does not guarantee better results#

A context window describes how much input a model can accept. It does not promise that the model will use every part equally well. Finding a named sentence in a document is also different from comparing requirements, code, logs and several abandoned plans.

Chroma’s July 2025 experiments found that performance varied with input length and content on the models and tasks tested. That supports taking long-input failures seriously. It does not establish one safe maximum for every coding session.

A repeated mistake does not prove that input length caused it. The agent may be missing a requirement or misunderstanding the code even in a short conversation. More context helps when it supplies that missing information; less can help when it removes distractions without losing useful facts.

Use token counts as checkpoints, not rules#

A good time to inspect the conversation is after research, after agreeing a plan or after completing a tested part of the implementation. The next step may need the findings without needing every search that produced them.

HumanLayer’s August 2025 workflow used roughly 40–60 percent context utilisation as a working range, depending on the task. This is practitioner advice from that setup, not a universal performance boundary.

For example, 40 percent of 200,000 tokens is 80,000 tokens. Forty percent of a million is 400,000. The arithmetic does not show that the second model can handle five times as much difficult reasoning. An absolute checkpoint such as 100,000 tokens also needs testing on your workload.

Stop an unsafe proposed action immediately rather than waiting for a token threshold. Conversely, do not discard a productive investigation merely because it crossed someone else’s suggested percentage.

Find what the next attempt needs to change#

The four questions in context engineering help distinguish the problem. A huge log may hide the relevant failure. An old note may be wrong. A required business decision may be missing. Or the history may keep steering the agent towards an earlier guess.

For the upload bug, keep the failing assertion rather than all the routine output. Replace the claim that only the browser checks size. Find the agreed rule for a file exactly at the limit. Make the direct server failure the starting point for the next investigation.

A shorter false statement is still false. A fresh session without the missing requirement still has to ask. Choose the correction before deciding whether a restart is useful.

Stop carrying an old mistake into new attempts#

An agent’s trajectory is its history of actions and claims. “Trajectory poisoning” is an informal name for earlier mistakes continuing to shape later work. In this example, every new edit extends the browser explanation instead of checking whether it fits the direct-request failure.

Microsoft Research’s multi-turn study found that tested models could rely too heavily on premature solutions and early assumptions. Inspect those assumptions rather than judging the agent by its tone. An apology followed by the right check can be progress; a confident claim without a check is not.

A useful new instruction is: “The browser cause is unproven. Reproduce the rejection through the server endpoint before editing another client file.” It identifies what is unknown and what to do next. “You are wrong, try harder” does neither.

Choose whether to continue, shorten or restart#

An automatic summary is a draft handover. Check that it preserved important exceptions before allowing consequential work to resume. The same applies to a subagent’s summary. A separate conversation does not necessarily mean a separate filesystem or restricted permissions.

What to carry into the new session#

For this upload bug, save the inclusive size rule and the request that reproduces the failure. Mark the browser explanation as unproven. Record the three client edits already attempted and the next server-side check. Attach the code revision, saved diff and relevant logs.

Label checks accurately: passed, failed, blocked or not run. Starting a new chat does not undo files, stop processes or close an existing pull request. Record external actions too, including any write whose result is still unknown. Do not discard uncommitted work just to make the new session look clean.

The replacement session first checks the repository version and workspace, then reproduces the failure. Only then does it make the next correction. The context-reset worksheet provides a record to fill in, and the planning guide covers handovers between longer phases.

Next, the harness guide explains how tools and checks limit what a session can do even when the model misunderstands its input.

Check whether the restart helped#

Look for a better action, not a more confident answer. The agent should test the disputed assumption, preserve the requirement and produce a change that passes the relevant checks. Count the review and correction work still needed from a person.

Across representative tasks, record the model, approximate input size, first wrong action and result after the intervention. Include unsuccessful restarts. If the same failure persists, inspect the requirement, environment or tests rather than endlessly rewriting the summary.

Questions people also ask

3 QUESTIONS

▸ Does context rot start at 40 percent or 100,000 tokens?

Neither is a universal cutoff. A token count can remind you to inspect a session, but task difficulty and observed mistakes matter too. A larger advertised window does not prove that a model can reliably handle a proportionally larger coding task.

▸ Does starting a new chat undo the agent's changes?

No. Files, commits, running processes and external actions remain. Save the current changes and record what has happened before restarting. The new session must inspect that state rather than assume it has an untouched workspace.

▸ Is compaction the same as starting again?

Compaction selects a shorter record of earlier work. A restart begins a new conversation, which may use that shorter record. Both can help, but copying a misleading summary into a fresh conversation can reproduce the same mistake.