The Model Thinks. The Harness Remembers.

Give a modern language model a job that takes an afternoon. Refactor a module, run the tests, read the failures, fix them, move to the next file, keep going until the suite is green. For the first ten minutes it is magic. It reads the code, makes a sane plan, edits with taste. Then, somewhere around the twentieth step, it starts to drift. It re-reads a file it already changed. It forgets a decision it made twenty minutes ago. It declares victory while three tests are still red. By step forty it is confidently going in circles.

The model did not get dumber between step ten and step forty. Something else broke. Understanding what broke, and the machinery people build to stop it from breaking, is the whole subject of this post. That machinery has a name that has quietly become one of the most important words in applied AI: the harness.

What an agentic harness actually is #

A language model, on its own, does exactly one thing: you give it text, it predicts more text. It cannot read a file, run a command, or check its own work. It has no memory beyond the words currently in front of it. To turn that into an agent, something has to run it in a loop, hand it tools, feed the results back in, and decide when it is done. That something is the harness. Mitchell Hashimoto compressed the whole idea into a formula that stuck: Agent = Model + Harness.

An LLM agent runs tools in a loop to achieve a goal.

Simon Willison

The loop is the beating heart of it. Anthropic describes the shape as gather context, take action, verify the result, repeat. The model looks at what it knows, calls a tool (read a file, run a test, search the web), the harness executes that tool and appends the result to the conversation, and the model looks again. It keeps looping until it stops asking for tools. Everything that is not the model itself is the harness: the loop, the set of tools and how they are described (Anthropic calls this the agent-computer interface, and warns you should sweat it as much as you would a human UI), the way context is managed, the permission checks, and the recovery when something fails. A useful 2026 shorthand pins it to four necessary parts: an agent loop, a tool interface, context management, and control. Everything in this post is one of those four.

Martin Fowler's team offers a clean way to split the harness in two. There are guides, which shape the agent before it acts (the system prompt, an AGENTS.md or CLAUDE.md, the tool descriptions), and there are sensors, which give it feedback after it acts (a linter, a test result, a type error). The best sensors do not just report a failure, they phrase it so the model knows how to fix it. A good harness maximizes the chance the agent gets it right the first time, and then catches what it got wrong before a human ever sees it.

Why the simple version falls apart #

Here is the naive harness in full: a while loop that calls the model, runs whatever tool it asked for, appends the output to the conversation, and calls the model again. That is genuinely all you need for short tasks, and it is close to what real agents run. The problem is the word 'appends.' Every step makes the conversation longer, and the conversation is the model's entire working memory. On a long task, that memory does not just fill up. It rots.

messages = [system_prompt, user_task]

while True:
    reply = model(messages)            # predict the next action
    messages.append(reply)
    if not reply.tool_calls:           # no tool call: it thinks it is done
        break
    for call in reply.tool_calls:
        result = run_tool(call)        # read a file, run a test, search
        messages.append(result)        # the context only ever grows

The rot is measurable. Chroma tested eighteen frontier models and found performance degrades as input grows, often well before the advertised context limit, with the steepest drop between roughly 100,000 and 500,000 tokens. The classic 'lost in the middle' result found accuracy falling by thirty points or more when the relevant fact sat in the middle of the context instead of the ends. Practitioners talk about a 'dumb zone' in the middle 40 to 60 percent of the window where recall quietly falls apart. A transcript stuffed with old tool output is not neutral filler. It is active interference.

Then there is arithmetic that no model upgrade escapes. If each step of a task succeeds ninety-five percent of the time, and the steps depend on each other, a ten-step task finishes about sixty percent of the time and a twenty-step task about a third of the time. At a more realistic ninety percent per step, twenty steps drops to around twelve percent. METR's measurements put numbers on the ceiling: today's models finish almost every task that takes a human a few minutes, and almost none that take a human more than a few hours. Long-horizon reliability is not a knowledge problem. It is a structural one.

There is even a psychological wrinkle. Cognition found that models exhibit what they call context anxiety: as the window fills, the model starts rushing, cutting corners, and announcing it is running out of room even when it is not. Their fix is almost funny. They give the model a million-token window but cap real usage far below it, so it believes it has plenty of runway and stops panicking. Everything the rest of a harness does is, in one way or another, a response to these four problems: the window fills, the middle rots, errors compound, and the model panics. So let us build the fixes, one move at a time.

Move 1: give it a notebook #

If the model cannot trust its own memory over a long task, put the memory outside its head. The simplest version is a todo list the agent writes and then re-reads. This is why almost every serious coding agent has a todo tool. Claude Code shipped TodoWrite and has since moved to a structured Task tool set; opencode, which is fully open source, has a todowrite tool that persists straight into a local SQLite database. The list does two jobs: it forces the model to commit to a plan up front, and, because the agent is prompted to consult it constantly, it keeps the goal in fresh attention instead of letting it drift to the rotting middle of the context.

write_file('TODO.md', plan)   # commit to a plan up front

# many steps later, feed the plan back so it cannot drift out of attention
todo = read_file('TODO.md')
messages.append(user('Here is your plan. Update it, then continue:'))
messages.append(user(todo))

The bigger version of the same idea is to treat the filesystem as memory. The agent writes notes, progress logs, and decisions to files, then reads them back later. Anthropic's write-up on long-running agents describes a two-agent pattern for work that spans many sessions: an initializer sets up the environment and a progress log, and every later session reads the log, makes incremental progress, and commits its work to git with a descriptive message before it runs out of room. They even found the model is less likely to corrupt a JSON state file than a Markdown one, so the durable memory is JSON. The shift-handoff is the mental model: each session arrives with no memory of the last, so the last one has to leave good notes.

Move 2: forget on purpose #

Notes help, but the live conversation still grows. So the harness learns to forget deliberately. This is compaction: when the context approaches its limit, summarize the older part of the conversation, keep the most recent turns verbatim, and continue from the summary. opencode's implementation is a clean thing to read because it is open. It keeps a buffer of headroom, keeps the last several thousand tokens of conversation exactly as they are, serializes the rest into a summary produced by the same model, and starts the next turn from summary-plus-recent. Claude Code does this automatically too; Anthropic documents that it 'compacts conversation history when you approach context limits, preserving important code and decisions while freeing space.'

def maybe_compact(messages, limit, keep_recent=8000):
    if count_tokens(messages) < limit:
        return messages                        # still room; do nothing
    recent = tail_by_tokens(messages, keep_recent)   # keep the last turns verbatim
    older = messages[:-len(recent)]
    summary = model(summarize_prompt(older))   # let the model compress the rest
    return [system(summary)] + recent          # continue from summary + recent

Compaction is powerful and slightly dangerous, and honesty requires saying so. A summary is lossy by definition, and the art is tuning it to preserve the load-bearing details (unresolved bugs, architectural decisions, why a thing was done) while dropping the redundant tool output. Get it wrong and you summarize away the one fact that mattered. Simon Willison has a cautionary tale of an agent that lost its original instruction during a compaction and deleted the very inbox it had been told only to review. Forgetting on purpose is necessary. Forgetting the wrong thing is how long agents go quietly, catastrophically wrong.

That danger is why compaction is not one switch you flip, and why on high-stakes work you have to decide what is even allowed to be forgotten. Picture an agent drafting a contract over a hundred turns. If it compacts the client's hard requirement, 'indemnity capped at fees paid,' down to a breezy 'discussed liability terms,' it will draft something wrong and sound completely confident doing it. The fix is to make the lossy part the disposable reasoning and the lossless part the facts that must not change, by keeping the critical facts out of the summarizer entirely.

So the load-bearing facts get extracted, verbatim and with their source, into a durable structured store (a matter-state: parties, governing law, must-have clauses, forbidden terms, deadlines) that compaction never touches and the agent re-reads before it drafts. Three rules keep it safe. Extract the critical facts to durable memory before you compact, not after. Never let the model draft a critical clause from its own recollection; make it re-read the source (retrieve, do not recall). And keep the full transcript on disk, so 'compacted' means trimmed-from-the-window, not deleted, and a person or a fresh agent can always audit what was dropped. For the work that truly matters, that audit is a human, at a checkpoint. Compaction manages the model's short-term memory. It is not a place to keep your source of truth.

# critical facts never go through the summarizer
facts = extract_facts(messages)               # verbatim, with their source
save_json('MATTER.json', merge(load('MATTER.json'), facts))

messages = maybe_compact(messages, limit)     # only the chatter gets summarized

# before drafting anything critical, re-read the source. do not trust memory.
clause = draft(read_json('MATTER.json'), retrieve(source_docs, topic))

Move 3: send scouts, not the whole army #

Some work is inherently context-hungry. 'Figure out how auth works across this codebase' might mean reading forty files to produce three sentences of conclusion. If the main agent does that itself, its context is now full of forty files it will never need again. The fix is the most elegant move in the whole harness: spawn a subagent. The subagent runs in its own separate context window, does the messy reading, and returns only a compressed summary to the main thread. The exploration happened somewhere else. The main thread stays clean. Anthropic notes their subagents often burn tens of thousands of tokens exploring and return one or two thousand. It is a context firewall.

def spawn_subagent(question):
    # a fresh context window the main thread never sees
    sub = [subagent_prompt, user(question)]
    answer = run_agent_loop(sub)             # burns its own context exploring
    return summarize(answer, max_tokens=1000)  # hand back only a small summary

# the main thread stays lean
findings = spawn_subagent('how does auth work across this codebase?')
messages.append(user('findings: ' + findings))

This is also where multi-agent hype meets its limits, and the honest answer is nuanced. Reading parallelizes beautifully: fan out ten subagents to research ten things at once, each with its own context, and merge the summaries. Anthropic reported a multi-agent research system beating a single agent by about ninety percent on their internal eval, at roughly fifteen times the token cost. Writing is the opposite. Cognition's blunt argument in 'Don't Build Multi-Agents' is that when two agents edit in parallel, each makes implicit decisions the other cannot see, and the pieces do not fit together. Their rule is the single-writer principle: one agent owns the writing and the full context; subagents are scouts, not co-authors. The pattern that actually works is a single main thread that dispatches read-only subagents and keeps the pen for itself.

Move 4: do not trust the word 'done' #

A model will happily tell you it finished while the tests are red. It is a text predictor, and 'the task is complete' is a very probable sentence. So the harness cannot take 'done' on faith. Done is a claim, and the harness's job is to demand proof. The cheapest proof is a verifier that runs before completion is allowed: run the test suite, run the type checker, and if they fail, feed the failure back into the loop as a new problem rather than accepting the claim. A stronger version, which Anthropic uses, is a fresh-context evaluator, a separate read-only agent whose context never saw the build, so it judges the result without the builder's motivated reasoning.

def is_done(project):
    # 'done' is a claim. demand proof before believing it.
    if not run_tests(project).passed:      # a deterministic sensor
        return False, 'tests are red'
    check = fresh_agent(project.diff)      # a read-only judge that never saw the build
    return check.ok, check.reason

done, why = is_done(project)
if not done:
    messages.append(user('not done: ' + why + '. keep going.'))

The other half of completion is surviving crashes, and this is where a real open-source harness earns its keep as an example. opencode writes every step to a durable SQLite event log before any side effect happens, snapshots the filesystem before each step so any change can be reverted, and, on restart, scans for tool calls that were left mid-flight and marks them failed so the loop can recover. That is the difference the durable-execution people (Temporal, Restate, Inngest, and others) keep hammering: saving a checkpoint is not the same as guaranteeing completion. A checkpoint says 'here is where you were.' Durable execution says 'this will run to the end, even across a crash.' Dex Horthy's 12-Factor Agents makes the same point from the other side: the agents that survive production are mostly ordinary, well-engineered software with the model sprinkled in at the decision points, not autonomous magic.

Move 5: keep it aimed at the goal #

Everything so far keeps the agent alive across a long task. The last move keeps it pointed at the right target, because a long-running agent drifts. Forty steps in, it is busily optimizing some sub-problem it invented three detours ago and has quietly lost the plot. Drift has the same root cause as rot: the real goal was stated once, at the very top, and it is now buried in the rotting middle of the context while every recent turn is about a tangent. Every fix is a version of one idea, make the goal louder than the noise.

Write the goal and the definition of done as durable, checkable criteria before the work starts, not as a vibe: must include clauses X and Y, must not include Z, done when the tests pass and a review agent signs off. Then re-inject them. Manus calls it recitation, re-stating the goal and the plan every few steps so they sit at the fresh edge of the context where attention actually is, not the dead middle. Check progress against those criteria at milestones, so off-track work is caught while it is one wasted step and not thirty. And watch the trajectory itself: an agent that starts re-reading the same file, repeating actions, or thrashing is showing you drift in real time, and the right response is to stop and re-ground it, or reset the context, rather than let it spiral. For anything high-stakes, the checkpoints are human, and the agent proposes at each gate instead of barreling to the end.

goal = load_goal()   # {objective, must_include, must_not_include, done_when}

# recite the goal every few steps so it stays at the edge of context
if step % 5 == 0:
    messages.append(user('Recite the goal and acceptance criteria, then continue:'))
    messages.append(user(render(goal)))

# check against the criteria at milestones, not just at the very end
unmet = check(current_draft, goal.done_when)
if unmet:
    messages.append(user('Off track. Still unmet: ' + unmet))

None of this is exotic. It is a project manager's job, written down: set the spec, track against it, review at milestones, escalate when something looks off. That is the uncomfortable lesson of long-horizon agents. The harness has to be the project manager, because the model, left alone with a big goal and a growing context, will confidently wander off and never notice.

The twist: the best harness is barely there #

After all that machinery, the punchline is counterintuitive: the best harnesses are aggressively simple. The instinct to wrap a model in an elaborate graph of specialized agents almost always makes things worse, because every layer is another thing to debug and another way for context to fragment. The people who build these tools say it plainly. Boris Cherny, who created Claude Code, describes it as close to the opposite of clever.

All the secret sauce, it's all in the model. And this is the thinnest possible wrapper over the model.

Boris Cherny, on building Claude Code

Simplicity shows up in the tools, too. Give an agent a handful of sharp, general tools (read, edit, run a shell command, search) and it will compose them into anything. Give it a hundred bespoke ones and it degrades, spending its attention choosing between tools it half understands. And there is a deeper reason not to over-build: the harness has a shelf life. Every hand-coded workaround you add exists to paper over something the model cannot yet do reliably, and models keep getting better. Engineers who have watched this happen argue you should treat your harness as a ninety-day artifact, and remove structure as the model grows into the job. Add scaffolding for the level of capability you have, then take it away, because yesterday's scaffolding becomes tomorrow's bottleneck.

That churn is visible in the tooling itself. By mid-2026 the sharper question had quietly moved from which model you run to which harness you run, and a new category appeared above them: meta-harnesses that let you swap one engine for another mid-session while keeping your context and policies the same underneath. The harness stopped being plumbing and became something you choose.

The part nobody can measure #

Which raises the uncomfortable question I cannot stop thinking about. Every move in this post is a design decision. How do you know any of them actually helped? You would measure it, of course, by running the agent on a benchmark. Except the benchmark score is not a property of the model. It is a property of the whole system, harness included. Take one fixed model and run it inside nine different harnesses on the same tasks, and the score swings by more than twenty points, as much as the gap between one model generation and the next.

A coding agent is a system harness, a composite of models, harnesses, contexts, environments, and feedback signals, any one of which can move the benchmark score by margins comparable to those between adjacent model generations.

Coding Benchmarks Are Misaligned with Agentic Software Engineering (2026)

So most harness engineering is done half-blind. You change the compaction strategy, the score moves, and you genuinely cannot say whether you improved the harness or just got a lucky draw from a noisy instrument. If that sounds familiar, it should: it is the same problem as trusting an eval score whose grader you never validated. The harness is the evaluator's twin, another unmeasured instrument silently deciding your outcome. I am not a neutral observer here, since measuring these systems honestly is the problem I have chosen to work on, but the point stands on its own: you cannot improve a harness you cannot measure, and almost nobody measures theirs.

So, what is a harness #

It is the machine that takes a brilliant, forgetful, occasionally overconfident text predictor and keeps it pointed at a goal long enough to reach it. A loop to let it act. Tools to act with. A notebook so it does not forget. Compaction so it can forget the right things. Subagents so the messy work happens somewhere else. Verification so 'done' means done. And enough restraint to keep all of it thin, because the model is climbing toward the day it needs less of your help, not more. The model supplies the thinking. The harness supplies the memory, the discipline, and the second chances.

Further reading #

• ▸Anthropic, Building Effective Agents (2024). The canonical workflows-vs-agents distinction and the agent-computer interface idea.
• ▸Anthropic, Effective context engineering for AI agents (2025). Compaction, note-taking, and sub-agent context strategies.
• ▸Anthropic, How we built our multi-agent research system (2025). Read parallelizes, write does not; subagents return compressed summaries.
• ▸Cognition, Don't Build Multi-Agents (2025). The single-writer principle, stated bluntly.
• ▸Martin Fowler / Birgitta Boeckeler, Harness Engineering (2026). Guides and sensors as a vocabulary for the harness.
• ▸LangChain, The Anatomy of an Agent Harness (2026). The four parts of a harness, laid out cleanly.
• ▸awesome-harness-engineering. A living 2026 list of harness patterns, evals, memory, and orchestration.
• ▸Chroma, Context Rot (2025). Eighteen models, all degrading before their limits.
• ▸opencode. An open-source coding-agent harness worth reading end to end.
• ▸Coding Benchmarks Are Misaligned with Agentic Software Engineering (2026). Why the same model swings twenty points across harnesses.