Progressive context shaping: steering agent runs that last ten hours

Key Takeaways

• Replace the manual with a map. OpenAI swapped their giant instruction file for a short document pointing at active execution plans, decision logs, design documents, an architecture map, and quality grades for each part of the codebase being touched. Those materials changed as the work progressed, so the map stayed an accurate picture of current state instead of an archive of past instructions.
• Anthropic's version is a progress file as portable memory. In long-running scientific computing work, Claude Code keeps a file recording current state, completed work, known limitations, and failed approaches with the reason each failed. A fresh session reads it, picks up the next task, and avoids re-entering the same dead end. The same pattern — progress file, structured handoffs, version history — appears in their long-running coding harness.
• Arise's fix: move the plan out of the conversation entirely. Their agent Alex once spent 27 model calls almost entirely reorganising its own to-do list, because the original request had been buried under tool output and intermediate results. They didn't solve it by adding a firmer sentence at the top of the prompt — they stored the plan on disk, and on every model call rebuilt a short plan message from the latest state and placed it in front of the noisy history.
• Separate transcript from current context. That is the load-bearing idea. The transcript still holds real information, but the maintained plan carries more authority than the pile of events. The agent gets an updated answer to the only question that matters at each step: given everything that has happened, what should I be doing now?
• The mechanism is ordinary — a current.md file. Not a Claude or Codex feature; you and the agent just have to agree to keep it current. In Claude Code, CLAUDE.md can instruct Claude to read it at the start of the job and update it after every consequential decision. In Codex, AGENTS.md or the task itself carries the same instruction. In a plain chat, paste or attach the state when you open a new conversation. Jones has run the same practice through a markdown file, a plan, a JSON record, and an issue tracker — the container matters far less than whether the next action sees updated state.
• A rule for what belongs in state versus history. Save a change only when it affects the target, the goal, or the definition of done. His test: if you would be annoyed when a fresh agent misses a decision, it belongs in project state. If it only explains how you got there, leave it in the history.
• Write approval gates into the opening prompt. Alongside the result you want, the materials the agent may use and a sensible first move, name the actions that require sign-off — publication, spending, deletion, or contact with another person.
• Long runs amplify wrong directions as much as right ones. His own benchmark project discovered 339 sources, generated over a thousand questions and produced 250 verified answers, then got stuck re-triggering itself during package synchronisation — still active, no longer adding value. The original "keep stress testing" instruction had been correct early and became wrong later. He stopped the run, recorded a checkpoint that prohibited resuming the unbounded loop, and redirected the next pass to deepen evidence on the 50 highest-value answers and stop. All completed work stayed available under the new direction.

The Four Kinds of Context to Separate

Rather than one file, Jones splits what the agent needs into four categories — and argues most people maintain the first and fourth while skipping the second, which is the one that actually governs the next decision.

1. Project rules. The durable constraints: what actions require approval, and what standards must hold throughout. Written once, changed rarely.
2. Current project state. What the project is trying to accomplish, which decisions currently govern the work, which questions remain open, what should happen next, and what condition should make the agent stop or come back to you. This is the layer he says most people skip.
3. The map. What material exists and where it lives — how the agent gets a reliable way to find the piece that matters for the next decision, rather than being handed everything.
4. History. What happened before, what changed, and why. Transcripts and decision logs are useful history, but history should be available for the agent to consult rather than pushed in front of it.

He calls the pruning that follows helpful forgetting: a failed approach is still recorded, but it no longer occupies the same position as the active one, so a fresh session doesn't relive the failure to learn from it.

How to Structure the Opening Ask

Start with one project whose path is uncertain but whose outcome matters, and don't request the whole thing in a single shot. Give the agent four things at the start:

• The outcome you want.
• The relevant source material it may use.
• The action boundaries — what it can and cannot do.
• The first useful checkpoint, containing work substantial enough to change your judgment.

His contrast on checkpoint quality: "think about the problem and report back" is a very weak ask. "Find the sources, identify where they disagree, and propose the first version of the answer" is a strong one — it produces something you can push against, which is the entire point of checkpointing before you know every step.

Then have the agent maintain a small current-state record as it goes. It does not need to be long; it needs to sit where the agent will look, and it needs to be short enough that the agent will actually read it.

Why This Matters More as You Run Agents in Parallel

• Anthropic's research across roughly 400,000 Claude Code sessions found that in a typical session the person in charge made about 70% of the planning decisions while Claude made about 80% of the execution decisions. Jones treats the split as a rule of thumb rather than a law, but it clarifies the human role: you own what counts as done and what the new evidence means; the agent owns the path between checkpoints.
• OpenAI found its engineers could comfortably manage only three to five Codex sessions at once before context-switching became painful — people forgot which session was doing what and spent their time moving between terminals. Symphony moved the work onto a project board where agents pulled tickets, so the ticket carries current state instead of a person holding every session in their head. On some teams, landed pull requests rose 500% in the first three weeks after the change.
• You can adopt the idea without adopting the tool. The ticket, the board, the markdown file and the JSON record are interchangeable; what matters is that the next agent action reads updated state.
• A bigger context window is not a substitute. A larger window may retain more events, but retention is not the same as knowing which of those events still governs the work — and Jones is explicit that none of this substitutes for your judgment, it only extends its reach.
• Correct the state, not just the draft. If you fix only the output in front of you, the correction stops there. Changing the current project state is what makes it reach the research still open, the next implementation, and any work handed to another agent.