How an Agent Runs for 6 Hours Without Drifting: A 200-Item Unfinished Checklist

Kaiju put together a set of notes on Harness Engineering on X. The core formula is short: Long-Running Harness = Short Sessions + State on Disk. Long tasks are split into multiple short sessions, and state lands on disk. The video gives a full breakdown.

In Anthropic's tests, agents mainly fail because of two behaviors: building everything all at once; and later sessions seeing a little progress and declaring completion. Kaiju says in the tweet that Anthropic used a 3-page PDF to collect public practices from OpenAI, Anthropic, and LangChain, in which one formula replaced prompt engineering.

The harness governs what the agent can see, touch, and inspect: session startup files, tools, permissions, saved state, and output checks. Kaiju quotes Codacy's explanation: harness engineering determines what the agent can touch, and what checks the output.

Kaiju's five-step playbook:

First run an initializer session; do not write feature code.
Have it write a feature list in JSON format, with more than 200 items, each with passes set to false.
Add a progress file, an init.sh, and the first git commit.
From then on, every session starts with a fixed routine: pwd, read the log, pick a failing feature, run the smoke test.
Build one feature, test it in a real browser, commit, and update the notes.

OpenAI reports that under the same harness approach, a single agent can run for more than 6 hours.

It looks dumb. At multi-agent graph launches, the harness is like a sticky note. Kaiju's order is the opposite: harness, loop, graph. The harness makes one session reliable, the loop lets sessions finish, and the graph shares out work after both are in place. Kaiju cites LunarResearcher's judgment: a perfect graph cannot save a weak harness.

Anthropic's memory experiment is more direct: parallel agents writing to the same shared table retained only 41 of 57 contract facts; with one page per agent, all 57 were there. Changing only shared state is harness work.

The decision order has three questions:

Can a new session pick up yesterday's work in a few minutes?
Can you prove done with one command?
Does the task require multiple context windows?

If the first is no, build a harness; if the second is no, build a loop; only when all three are yes do you deserve a graph.

At the copy-paste level, Kaiju provides a four-piece kit: feature_list.json, init.sh, claude-progress.txt, and CLAUDE.md. Each feature starts with passes set to false. Anthropic chose JSON because models are less likely to modify JSON files inappropriately. The rules include: each session does only one feature, only changes the passes field, must not delete tests, can mark passing only after an end-to-end check has run, and must end with a commit and 3 to 5 lines of progress.

Tools are requests; hooks are guarantees. Kaiju quotes this line from Codacy and recommends putting a PostToolUse hook in .claude/settings.json: after Edit or Write, run tests, and exit 2 on failure. Only errors with exit 2 are passed back to Claude.

Loops use /goal. Conditions must be testable and have a turn cap. Example: /goal make the first 3 features with passes=false become true, each verified by ./init.sh and an end-to-end check, do not modify test files, update claude-progress.txt, or stop after 25 turns. When running overnight, add stream-json; otherwise the terminal looks frozen.

Graph comes last. First subagents, then teams, then workflows. For teams, 3 to 5 teammates are recommended; two agents modifying the same file will overwrite each other. More than 25 agents or 1.5 million tokens triggers a Large workflow warning.

The first week can be scheduled like this: Day 1 run the initializer and cut ambiguous items from the feature list. Day 2 manually run three sessions, each time reading the progress file and ending with a commit. Day 3 use /goal with N set to 1. Days 4-5 raise N to 3. Days 6-7 decide whether to review fan-out. If one reviewer is enough, don't use a team.

The most costly mistakes: bringing in a team on day one; having no numbers in the goal; running unattended but stuck in manual mode; letting the agent modify tests; two agents writing to one file.

Kaiju's full breakdown is in this tweet, and the long article is here.