The harness for long-running work

Every session starts with amnesia

A loop that runs for hours is really many sessions in a row, and each one begins with no memory of the last. Justin Young's article on long-running agents starts from that fact. Everything the next session needs to know has to be somewhere it can read.

The context engineering guidance says the same thing from the other side: structured note-taking is external memory. Addy Osmani's recipe includes it as a memory store, a markdown file or board on disk that records what is done and what is next. Ralph's plan file is the same idea in its simplest form.

Young's article is built around four failures, and each fix maps to one: premature victory, undocumented state, premature "done", and wasted setup.

The first session sets the stage

Young splits the work into an initializer session and many coding sessions. The initializer does the one-time setup.

• It writes init.sh, a script that starts the project, so later sessions do not waste time working out how.
• It starts a progress log.
• It makes the first git commit.
• It expands the prompt into a JSON feature list, with every feature marked failing.

Every later session does one feature. It may change only the passes field of that feature. Young chose JSON over Markdown for this file because models overwrite it less. A feature list the agent can rewrite is a feature list that will quietly shrink until the work looks finished.

The startup routine

Each coding session begins with the same short routine.

The last check before picking a feature is what protects the rest. If the previous session left the app broken, the new session finds out before it builds on top of the break. Young also reports that browser automation, a Puppeteer MCP in his setup, caught bugs that reading the code missed.

At the end of a session, the agent commits with a descriptive message and updates the progress log, so the next one starts clean.

What the compiler run taught

Nicholas Carlini's C compiler used a different shape: 16 agents in separate Docker containers on one shared git repo, no orchestrator at all. Coordination was files and git.

• Lock files. An agent claims a task by writing a lock file into current_tasks/. Git forces a second agent that tries the same task to pick another.
• Tiny test output. Keep it to a few lines and log details to files. A run that floods the context with output blinds the agent.
• Time blindness. Claude cannot judge elapsed time, so he added a fast sampling mode and kept progress output sparse.
• CI. New features kept breaking old ones, so tests and CI became part of the harness.

What the game harness taught

Prithvi Rajasekaran's harness for a retro game maker used three roles: a planner that turned one sentence into a 16-feature, 10-sprint spec, a generator, and a separate evaluator. The generator and evaluator agreed on what "done" meant for each sprint through files.

The most useful part came later. With Sonnet 4.5, the harness needed context resets, a fresh agent plus a structured handoff, because of what the article calls context anxiety. With Opus 4.5 those resets were dropped. With Opus 4.6 the sprint structure was removed, the evaluator moved to one final pass, and the planner stayed.