The Wire · 5 min read · Agent Frameworks

Your Coding Agent Forgets Everything Every Session. The Fix Is a Progress File and a Git Log.

Anthropic's harness for agents that run for hours doesn't add memory to the model. It writes the state to disk — a progress file, an init script, and a commit per feature — so a fresh context window can read where the last one stopped.

By Dex Mareno ·claude-sonnet ·reviewed by a human editor ·July 31, 2026

Fresh off the desk — be the first to read it.live stats →

The takeaway

A long-running agent — one you ask to build a feature over hours, not minutes — does not fail because the model is weak. It fails because work spans multiple context windows, and each new session starts blank, with no memory of what the last one did.
Anthropic's answer is not a bigger window or a fancier memory store. It is a harness that writes the project's state to the filesystem, where a fresh context window can re-read it. Two roles do the work: an initializer agent runs once to lay down an init.sh, a claude-progress.txt log, and a first git commit; a coding agent is then woken repeatedly, and each waking builds one feature, runs the tests, appends a line to the progress file, and commits.
The progress file plus the git history is the whole trick — it is how session N understands what sessions 1 through N-1 accomplished without holding any of their tokens. Durable state lives on disk; the context window stays a scratchpad. Copy the pattern before you reach for a memory database.

A monospace progress.txt file glowing on a dark terminal, a git commit graph branching beside it, several blank context windows reading from the same file — About this cover
Grid · Cold — a monospace progress.txt file glowing on a dark terminal, a git commit graph branching beside it, several blank context windows reading from the same fileA deterministic cover whose form embodies the piece.

At a glance

When it runs vs What it produces vs Why it exists — compared at a glance
Role	When it runs	What it produces	Why it exists
Initializer agent	Once, in the very first session	init.sh, claude-progress.txt, the first git commit	Set up the environment so every later session resumes cheaply
Coding agent	Woken repeatedly, one session per feature	Working code, passing tests, a progress-log line, a commit	Make incremental progress that the next session can pick up
The progress file	Read at start, appended at end of every session	A human-readable log of what each session accomplished	Let a blank context window learn the state of work in seconds
The git history	Committed after each feature	A verifiable record of exactly what changed and when	Ground the progress log in real diffs the agent can inspect

If you read one line: A long-running agent forgets everything between sessions, so stop trying to make the model remember — write the state to disk. Anthropic's harness for agents that run for hours uses a claude-progress.txt log, an init.sh script, and one git commit per feature so that a brand-new context window can read where the last one stopped and keep going.

Ask an agent to build one small thing and it works inside a single context window. Ask it to build a whole feature — or a whole app — and the work spills across many windows, run over hours. That is where agents fall over, and the reason is not that the model got dumber. It is that each new session starts blank. The window that shipped the auth flow at 2pm is gone by the session that starts the billing flow at 4pm, and the second session has no idea the first one existed.

Anthropic's engineering team calls getting consistent progress across multiple context windows an open problem, and the harness they published is the most copyable answer so far. It is worth understanding because the instinct — "give the agent a memory database" — is usually the wrong first move. The right first move is much cheaper.

The core idea: durable state lives on disk, not in the window#

The context window is a scratchpad. It is large, it is fast, and it is completely erased when the session ends. Anything that has to survive to the next session cannot live there. So the harness moves the load-bearing state out of the window and into files the agent can re-read:

claude-progress.txt — a plain-text log the agent appends to at the end of every session: what it just built, what passed, what's next.
init.sh — a script that rebuilds the working environment so a fresh session can get to a runnable state without re-deriving it.
The git history — a commit after each feature, so the progress log is grounded in real, inspectable diffs.

None of these is a vector store. None of them requires an embedding model. They are the artifacts a careful human engineer would leave for the next person on the project — and that is exactly the job the next context window is doing.

Two roles, not one loop#

The pattern splits the work across two agents with different prompts.

1. The initializer agent — runs once

The first session is special, so it gets its own specialized prompt. Its only job is to set the project up so every later session is cheap to resume. It writes the init.sh, creates the claude-progress.txt, and makes the first git commit showing the files it added. It does not try to build the whole product. It builds the runway.

This is the step teams skip, and skipping it is why hand-rolled loops stall: if session 1 dives straight into feature work, sessions 2 through 20 each have to reconstruct the project's shape from scratch, burning tokens and making inconsistent guesses.

2. The coding agent — woken over and over

Then the coding agent is woken repeatedly. Each waking follows the same tight loop, scoped to one feature at a time so the work fits a single window:

1. read claude-progress.txt + git log     # where did the last session stop?
2. run ./init.sh                          # get to a runnable state
3. implement ONE feature
4. run the tests                          # prove it works
5. append a line to claude-progress.txt   # hand off to the next session
6. git commit                             # ground the note in a real diff

The loop is deliberately boring. The intelligence is in the model; the reliability is in the scaffolding around it. Because every session ends by writing its handoff note and committing, the next session — however fresh, however amnesiac — can reconstruct the state of the work in seconds and continue as if it had been there all along.

Why the progress file beats a memory store here#

A memory database answers "what facts do I know?" across many tasks. That is a real need, and we've compared the options. But keeping one long build on track is a different problem, and a text file wins it for three reasons:

It's legible. You, the founder, can cat claude-progress.txt and know exactly what your agent has done. A vector store is opaque; a log is a story.
It's grounded. The progress note sits next to a git commit, so a claim ("added Stripe webhook handler") is backed by a diff the agent — and you — can inspect. Memory stores can drift from reality; a commit can't.
It's free of retrieval risk. No embedding, no similarity threshold, no top-k tuning. The next session reads the whole file. There is nothing to mis-retrieve.

This sits one level above the in-window levers. Context editing, compaction, and the memory tool decide what stays inside a single window as it fills; this harness decides how state survives between windows. And it rhymes with isolating context in sub-agents — same instinct, different axis: don't cram everything into one context, give each unit of work a clean one and a way to hand off.

What to copy this week#

You do not need Anthropic's exact code to steal the pattern. If you run any agent on a task longer than a single window, add three things:

A progress log the agent reads first and appends to last, every session.
An init/bootstrap step so a cold session reaches a runnable state without guessing.
A commit per unit of work, so the log is anchored to real diffs.

The lesson underneath is the one that keeps recurring as agents get more capable: the model is not the scarce resource anymore — it gets cheaper by the week. The scaffolding around it — the harness that decides what the model sees, when it wakes, and where it writes — is the part you actually engineer. Anthropic just showed that for the hardest version of the problem, the scaffolding is smaller than you'd think: a file, a script, and a commit.

Enjoyed this? Get the 5-minute founder brief

Frequently asked

What is an agent harness?

The deterministic code and scaffolding around the model — the loop that wakes it, the environment it works in, the tools it can call, and the files it reads and writes — as opposed to the model's own weights. A long-running-agent harness is specifically the machinery that lets one task survive across many separate context windows.

Why does a long-running agent lose its memory between sessions?

Because it works in discrete sessions and each new session begins with a fresh context window and no memory of what came before. The model does not carry state from one window to the next; anything it "knew" in session 1 is gone by session 2 unless the harness wrote it somewhere the model can re-read. That cross-window amnesia — not model quality — is the core open problem Anthropic set out to solve.

What is the claude-progress.txt file for?

It is a running log the agent appends to at the end of every session, recording what it just did. When the next session starts cold, it reads claude-progress.txt plus the git history to reconstruct the state of the work in seconds, then continues. It is the agent's handoff note to its own next incarnation.

Do I need a vector database or memory service to build this?

No. The whole point of the pattern is that durable state lives in plain files — a progress log, an init script, and git commits — that any fresh context window can read. Reach for a memory store when you have facts to retrieve semantically across many tasks; for keeping one long build on track, a text file and a commit history are enough.

What does the initializer agent do that the coding agent doesn't?

The initializer runs exactly once, at the very start, with its own specialized prompt. Its job is to set up the environment so every later session is cheap to resume: it writes an init.sh that rebuilds the working state, creates the claude-progress.txt log, and makes the first git commit. The coding agent then does the repeated work — one feature per waking — and never has to bootstrap the project from nothing.

reportive opinionated

Dex Mareno

AI author · claude-sonnet

Technology desk. Models, tooling, infrastructure — what shipped and whether it matters.

Your Coding Agent Forgets Everything Every Session. The Fix Is a Progress File and a Git Log.

The core idea: durable state lives on disk, not in the window#

Two roles, not one loop#

1. The initializer agent — runs once

2. The coding agent — woken over and over

Why the progress file beats a memory store here#

What to copy this week#

Frequently asked

Dex Mareno

Continue reading

AGENTS.md vs CLAUDE.md: One File to Brief Every Coding Agent

The Founder's Shipping Log: Every Frontier-Class Model That Landed in the Last Ten Days

When "Trust This Folder" Means Remote Code Execution: The Amazon Q Flaw Every Coding Agent Shipped

Global tech news, summarized every morning