A Timeline of How Long a Fresh Context Window Stays Clean (Spoiler: 4 Prompts)

This is satire, although the terminal output is real enough to hurt: a fresh context window is software engineering’s clean-room suit. For approximately four prompts, the agent has no opinions, no inherited misunderstanding of the auth boundary, and no half-finished urge to “also improve the architecture.” It sees the repository with the calm, blank expression of a consultant who has not yet been added to Slack.

00:00 — The Fresh Context Is Born

You open a new session and type the sacred words: “Read the repo. Do not change anything yet.” The agent runs pwd, lists files, opens README.md, and reports that the service appears to be a service. It has not yet confused packages/api with apps/web, nor discovered a deprecated environment variable and made it its entire personality.

For 38 seconds, everyone is winning. The working tree is clean. The prompt contains one task. The agent has not received the 1,900-line transcript in which a previous agent decided that every bug was probably caused by “state synchronization.” This is the last moment in the session when “context” means information rather than sediment.

Prompt 1 — “Find Where We Validate the Request”

This goes well. The agent searches for the route, traces the middleware, and names the relevant file. It may even notice the test. You begin to think the new model is unusually disciplined, which is how the context window gets you: not through failure, but through a single accurate filename.

Do not celebrate. At this stage, the agent has learned enough to be useful but not enough to form a theory. This is the optimum operating point, comparable to a fresh branch before someone says “quick cleanup.”

Prompt 2 — “Make the Smallest Fix and Run the Targeted Test”

The change is 14 lines. The test passes in 6.2 seconds. The agent summarizes the modification in three bullets, one of which is technically redundant but emotionally reassuring. You review git diff --check and git diff --stat; both produce the sort of boring output that should be framed and mounted above the build monitor.

The system is still clean because the task has an edge. There is a named behavior, a file boundary, and a test command. Nobody has said “while you’re in there.” Nobody has pasted an error from a staging container whose image was built before lunch from a branch that no longer exists.

Prompt 3 — “Also Handle the Related Case”

The word “related” enters the conversation wearing a hard hat and carrying demolition equipment. The agent now knows about validation, middleware, retry behavior, one flaky integration test, and a comment from 2023 that begins “temporary.” It starts connecting these facts with a confidence normally reserved for detectives who have found a red string.

It proposes a plan with five steps. Step four is “consider extracting a shared abstraction.” No extraction has been requested. No shared abstraction has ever been requested. But the fresh context, having inhaled several nearby facts, has begun manufacturing weather.

Prompt 4 — “Why Did You Touch the Retry Helper?”

Cleanliness ends here. Not because the agent cannot answer, but because it can answer too much. It recalls that the retry helper was mentioned near a failing test, near a configuration flag, near a sentence you wrote at 9:17 a.m. saying “ignore that for now.” It now treats “ignore that for now” as a constitutional amendment requiring interpretation by a nine-member court.

This is the phase in which the agent starts reporting its own prior decisions as project requirements. “As established earlier” means “I generated this 11 minutes ago while attempting to locate a JSON fixture.” The context has ceased to be a workspace and become a municipal archive: everything is preserved, nothing is indexed, and one folder is labeled FINAL_FINAL_USE_THIS.

Prompt 5 — Compaction, Memory, and Other Moving Services

At this point, your tool may compact the conversation, summarize it, retain selected messages, or drop older material when limits are reached. These are reasonable mechanics, but they do not convert a weak task record into a strong one. A summary that says “implemented auth improvements” is not a handoff; it is a ransom note from a meeting you did not attend.

The bad workflow is asking the agent to preserve the whole saga in its head. The worse workflow is making it write a 14-volume AGENT_MEMORY.md that explains every false start in ceremonial detail. The useful workflow is less glamorous: leave durable state in the repository. A short progress.md, a focused test, a current issue description, and a clean diff give the next context something it can verify instead of something it must believe.

The Official Four-Prompt Hygiene Protocol

1. Start with one bounded task: file, behavior, acceptance check.
2. Before prompt three, ask for the current diff and the exact command used to verify it.
3. When the task shape changes, start a new context instead of holding a cross-examination about the old one.
4. Put decisions that must survive in versioned files, tests, or issue text—not in a chat transcript that has become a decorative geological layer.
5. On handoff, begin with git diff, git status, and the targeted test command before asking for a new edit.

This protocol will not make an agent wise. It will not stop it from finding a nearby abstraction with a suspiciously clean name. It is especially bad at preventing the human operator from replying “yes, do that too” at 4:56 p.m. But it does reduce a particular failure mode: treating a long conversation as a source of truth when the repository can still be inspected.

The One Non-Satirical Observation

A fresh context is not valuable because it is empty. It is valuable because it can re-derive state from artifacts that are testable: the files, the diff, the test output, and the current task. Context windows are temporary. git diff is not a project manager, but it does show what changed. That is already more institutional memory than many teams had before the agent arrived.