What should an agent read at the start of a six-hour run?

A long agent run does not fail because the context window filled up. It fails because the agent could not tell which of the things in its context was still true.

That distinction matters, because the two problems have opposite fixes. If the problem were capacity, more window would help. Since the problem is currency, more window makes it worse — a larger space to accumulate material that has quietly stopped applying.

Separate by rate of change

The organising principle is simple: things that change at different rates belong in different files. Four kinds, four lifetimes.

Conventions — AGENTS.md or CLAUDE.md. How the project works: build commands, test commands, style, what must not be touched. Written by humans, changes rarely. Constraints, never intentions.

Environment — init.sh. One command that brings the thing up. Written once. Without it every session spends its opening minutes rediscovering how to run the project, and occasionally gets it wrong in a way that reads as a code failure.

Current plan — a structured list of items, each with a description and a status. Changes every session. This is the file that says what is being done now.

Progress — an append-only log, plus git history. Changes continuously. What happened, in order, with enough detail that the next session does not repeat it.

The rule that makes it work

Separation alone is filing. What makes it useful is being able to tell the agent which file wins:

The plan file is current intent. The conventions file is constraints. The progress log is history — context, not instruction.

You cannot say that about a single file. Everything inside one file has the same standing, which is exactly why the line from March competes on equal terms with the line from this morning.

The asymmetry in the plan file

One detail carries more weight than it looks: the agent may update status, and may not rewrite descriptions.

Given the ability to edit the plan, an agent will reconcile it with what it has already built — not dishonestly, but because the goal is the softer of the two and reconciliation is what it does. A few sessions in, the plan describes the work that happened, and can no longer tell you whether the right work happened.

Immutable descriptions, writable status. "Done" stays a claim that can be checked.

Anthropic's published harness for long-running agents encodes the same asymmetry: a feature list where the agent may flip a passes field and nothing else, alongside a progress file and an init script. The convergence is not coincidence — these are the shapes that survive contact with a run that outlasts its own context.

Append-only, and why

The progress log should only grow. An agent that tidies its history removes the record of the wrong turn that explains why the code looks the way it does — which is frequently the most valuable line in the file.

This is checkable: look at the file's own commit history and see whether it ever shrinks.

The session loop

Opening. Read the plan. Read the last few progress entries — not the whole log. Run the start script. Then verify the app actually runs before believing anything is finished, because the previous session may have marked work done without checking.

Closing. Append to the log. Update statuses, not descriptions. Commit with a message written for someone who was not there.

When the agent drifts

The instinct is to add a rule. Resist it. Ask instead which file it read that was wrong, and delete or fix that line.

Drift is almost always a stale rule outranking a fresh one, not a missing rule. Adding a correction leaves both lines in place, with no ordering between them, and produces intermittent behaviour that gets blamed on the model.

Where this does not apply

A task that starts and finishes in one sitting needs none of this. The overhead earns its keep when a run spans sessions, or when more than one agent works in the same repository — which is increasingly the default, and is when the cost of getting it wrong stops being visible.