Harness Engineering in 2026: Techniques Beyond MCP

Somewhere in the first half of 2026, the interesting question about AI coding agents stopped being “which model?” and became “what did you build around it?” The evidence forced the change. On Terminal-Bench 2.0, the same frontier model scores dramatically differently depending on the scaffolding it runs inside, a gap documented in Addy Osmani’s 2026 essay Agent Harness Engineering (also published on the O’Reilly Radar). Same weights. Different wrapper. Different results.

That wrapper now has a name, a practitioner literature, and a set of named techniques that did not exist eighteen months ago. This post inventories them: what each technique is, who named or shipped it, what failure it eliminates, and what it costs you. Not MCP servers, not CLAUDE.md hygiene, not linting hooks. Those are table stakes, covered elsewhere on this site. This is the layer above.

What is harness engineering?

Harness engineering is the practice of designing the system around an AI coding agent rather than the prompts inside it: the tools it can call, the rules injected before it acts, the tests and evaluators that check its work, and the loops that let it run for hours without drifting.

The model reasons; the harness decides what that reasoning can touch and whether the output survives.

The term spread through 2026 the way “prompt engineering” spread through 2023, and for the same reason: it named a job people were already doing badly. Osmani’s essay credits Viv Trivedy with the framing that stuck, Agent = Model + Harness, and the reframe that follows from it is blunt. When your agent produces garbage, the working assumption among harness engineers is the one HumanLayer states directly: it is not a model problem, it is a configuration problem.

You already run a harness, by the way. If you use Claude Code, Cursor, or Codex, you rented one. The techniques below are what people do when the rented defaults stop being enough. For what the stock Claude Code harness gives you (skills, hooks, subagents and their context costs), see the Claude Code harness guide; for the five structural layers every harness has, see the harness scaffolding guide. This post assumes both and goes to the techniques that sit on top, most of them tool-agnostic.

Why the harness now beats the model

Two things happened in late 2025 and early 2026 that made this a discipline instead of a folk practice.

First, the benchmark evidence became hard to ignore. Osmani’s essay reports that on Terminal-Bench 2.0, Claude Opus 4.6 running inside Claude Code scores far lower than the same model in a custom harness, and that Viv Trivedy’s team moved a coding agent from Top 30 to Top 5 by changing only the harness. The same conclusion anchors this site’s survey of the 2026 agent field: the harness matters more than the model. When a wrapper is worth more leaderboard places than a model generation, the wrapper is where the engineering hours go.

Second, Anthropic published the internals. Two engineering posts, Effective harnesses for long-running agents and Harness design for long-running application development, describe how their own teams keep coding agents productive across multi-hour sessions: initializer agents, structured handoff files, separate evaluator agents with calibrated scoring. Vendor material, so read it as the vendor’s position, but it is the most detailed public account of a production harness that exists, and half the techniques below trace to it.

The sequence from folk practice to discipline took about a year:

The economics follow the same direction. Models are rented and repriced monthly. The harness is owned, versioned in git, and compounds. Every dollar of harness work survives the next model swap; most prompt tuning does not.

The techniques, ranked by what they cost and what they fix

Seven techniques have earned names and adoption as of July 2026. Here is the inventory, cheapest first.

Technique	Failure it eliminates	What it costs
Ratchet rules	The same mistake twice	Discipline; near-zero tokens
Memory files as learning	Re-teaching the agent every session	A few hundred always-on tokens
Spec-driven development	Building the wrong thing fluently	Upfront spec-writing time
Ralph loops	Context rot on long tasks	Re-read of state files per iteration
Context resets and handoffs	Degraded judgment in a full window	Handoff-file tokens; lost nuance
Evaluator agents	The agent grading its own homework	A second agent’s tokens per review
Worktrees and orchestration	Serial throughput; single-perspective review	Multiples of everything

1. Ratchet rules: every failure becomes a permanent constraint

The ratchet principle, named in Osmani’s essay, is the meta-technique the others hang off. When the agent makes a mistake, you do not fix the output and move on. You fix the harness so that class of mistake cannot recur: a new rule, a new hook, a new check in CI. The harness only tightens. It never loosens.

The discipline that makes it work is the part most teams skip: zero aspirational rules. Every line in your rules file should trace to a real failure you can point at. If you cannot name the incident, delete the line. This is the opposite of how most CLAUDE.md files grow (speculative instructions layered on until the model ignores all of them), and it is why ratcheted harnesses stay short while undisciplined ones bloat.

Notice what the ratchet actually is: an incident postmortem process, compressed to minutes, applied to a machine. Ops teams have run this loop on humans for decades. The novelty is the cycle time.

2. Memory files: continual learning without fine-tuning

A memory file (AGENTS.md is the emerging cross-tool standard; CLAUDE.md is the Claude Code dialect) gets injected at every session start. The technique is letting the agent write to it. After a session surfaces a gotcha, the agent appends what it learned; the harness reloads the file next session, and knowledge from one run carries into the next. Osmani’s essay calls this what it is: a crude but effective form of continual learning, no fine-tuning required.

Crude is the operative word. The failure mode is the file becoming a junk drawer, which is why this technique only works paired with the ratchet discipline above: entries earn their place by preventing a named failure, and stale entries get pruned. The 2026 refinement is splitting human-facing docs from machine-facing context bundles, so the agent reads distilled rules rather than prose written for onboarding engineers.

3. Spec-driven development: the contract before the code

Spec-driven development inverts the vibe-coding workflow. Instead of prompting an agent into a codebase and steering, you (or a planning agent) first write a versioned specification of what the system should do, derive a plan from it, break the plan into tasks, and only then let the agent generate code against the spec. The spec, not the chat transcript, is the source of truth, and drift from it is a detectable error rather than a vibe.

By mid-2026 every major vendor ships a flavor: GitHub’s Spec Kit (an open-source toolkit), AWS Kiro (an IDE built around specs, priced apart in the Kiro pricing breakdown), and the open OpenSpec format among them. The through-line is the same: an agent that can check its work against a written contract fails loudly instead of fluently.

The cost is honest and upfront. Writing a real spec takes hours, and for exploratory work it is the wrong tool; you cannot specify what you have not yet understood. SDD pays off precisely where vibe coding fails: multi-session features, multiple agents on one codebase, anything where “plausible but wrong” is expensive.

4. Ralph loops: brute-force persistence with fresh context

The Ralph technique (yes, named for the Simpsons character) is an autonomous loop that re-feeds an agent the same prompt in a fresh context window, iteration after iteration, with all durable state living in files and git rather than in the conversation. Each iteration starts clean, reads the task list and progress notes from disk, does one increment of work, commits, and exits. Geoffrey Huntley published the technique in July 2025 as a deliberately dumb bash loop (his own formulation: while :; do cat PROMPT.md | claude-code ; done), it worked embarrassingly well, and Anthropic now ships an official ralph-wiggum plugin in the Claude Code repository: a stop hook blocks the agent’s exit and feeds the prompt back until the task is actually done.

Why it works is the interesting part. Long agent sessions do not fail because the model gets dumber; they fail because the context window fills with stale detail and the model’s judgment degrades. Ralph sidesteps the whole problem: no context ever gets old. Runners like the open-source snarktank/ralph add the persistence that makes it safe: a PRD the loop works through story by story, an append-only progress file, and AGENTS.md updates after each iteration so later loops obey what earlier ones learned. The ratchet again, automated.

The cost: every iteration re-reads the state files, so you pay a fixed token overhead per loop, and a badly scoped prompt can burn a night of iterations producing nothing. Practitioners running Ralph loops overnight treat the task list, not the prompt, as the thing worth engineering.

5. Context resets and handoff files: fighting context rot structurally

Anthropic’s long-running-agent harness formalizes what Ralph does informally. Their published design uses an initializer agent that sets up the environment on the first run, then a coding agent that makes incremental progress in each session and writes clear artifacts for the next one. When a window fills, the harness does not just compact the conversation; it can tear the session down entirely and rebuild from a structured handoff file.

The core problem, as the November 2025 post states it, is that long-running agents must work in discrete sessions, and each new session begins with no memory of what came before. Compaction alone does not fix that; Anthropic is explicit that even a frontier coding model like Opus 4.5, run in a loop across multiple context windows, falls short of a production-quality app without more structure. So the harness supplies the structure: descriptive git commits, a running progress file, and a feature list in JSON whose pass/fail state no summary can garble. Osmani’s essay draws the general lesson and credits it to Anthropic’s team: a harness encodes assumptions about a specific model’s weaknesses, and model progress relocates the scaffolding rather than eliminating it.

For your own setup the portable lesson is the handoff file. Any agent that might outlive one context window should be writing a “what I did, what is next, what surprised me” artifact as it goes. It costs a few hundred tokens per session and turns a context loss from a restart into a resume.

6. Evaluator agents: because agents overrate their own work

Ask a coding agent to review its own output and it will give itself a passing grade with the same fluent confidence it used to write the bug. Anthropic’s harness team hit this directly: agents consistently overrated their results, especially on subjective work, so the harness splits the roles. A planner expands intent into a spec, a generator implements, and a separate evaluator agent (calibrated with few-shot examples and explicit scoring criteria) grades the result before it counts as done.

The separation matters more than the head-count. The evaluator has no memory of the generator’s reasoning, no investment in its choices, and a rubric instead of vibes. It is code review rebuilt as structure, and it generalizes beyond Anthropic’s setup: the pattern shows up as adversarial verification in multi-agent workflows, where independent verifier agents are prompted specifically to refute a finding rather than confirm it.

This is the first technique on the list with a real token bill: you are running a second (sometimes third) agent per unit of work. Whether that is worth it depends on what a defect actually costs you; the hidden cost of AI-generated code covers that side of the ledger. For code that ships to production, it usually is.

7. Worktrees and deterministic orchestration: parallelism with guardrails

The last rung is running many agents at once without them trampling each other. The infrastructure answer is git worktrees: each agent gets an isolated checkout on its own branch, merges happen deliberately, and a failed experiment gets deleted rather than reverted. The practitioner writeups are a genre now, and the numbers have converged. An April 2026 guide from Claude Directory, Claude Code Worktrees Guide, reports teams running 4 to 8 concurrent worktrees per developer reliably, and that above that “you’re usually bottlenecked on review, not on Claude.” Past that point you are not agent-limited, you are attention-limited.

The orchestration answer is newer: instead of a human juggling sessions, the lead agent writes a deterministic script that fans work out to parallel subagents and collects results, with loops and conditionals living in real code rather than model judgment. Claude Code shipped this as dynamic workflows in research preview on May 28, 2026, and the pattern composes with technique 6: fan out finders, then fan out adversarial verifiers over what they found.

This is the most expensive row in the table by an order of magnitude. Every parallel agent is a full metered instance, and orchestrated fleets can run to dozens. The teams for whom this pencils out are the ones who did the math on engineer-hours first.

What these techniques do not replace

None of this substitutes for the boring layer. You still need a pruned rules file, deterministic lint and test hooks, and a deliberately small tool surface; a fleet of orchestrated agents with a bloated context and no test suite is just an expensive way to generate plausible bugs in parallel. The MCP server selection problem does not go away either. Every technique above assumes the layer below it works.

And one honest caveat from the benchmark literature: harness quality is also why agent benchmark scores are so hard to compare. When a custom harness moves a score double digits, a leaderboard number tells you about the model-plus-harness system, not the model. Treat vendor benchmark claims accordingly.

An adoption order that pays for itself

When the agent fails, do not fix the output. Fix the harness so that failure cannot happen again.

Resist the urge to install the list. Each technique earns its place when you hit the failure it eliminates:

1. First repeated mistake: start the ratchet. One rules file, every line traceable to an incident.
2. First “I told you this last week”: let the agent write to its memory file, pruned by ratchet discipline.
3. First multi-day feature: write a spec before the agent writes code, and add handoff files so sessions resume instead of restart.
4. First overnight task: a Ralph loop with a task list and a guardrails file.
5. First production defect that a fresh reviewer would have caught: an evaluator agent with a rubric.
6. First time you are waiting on one agent while holding work for another: worktrees, then orchestration, in that order.

Steps 1 through 3 cost almost nothing and most teams have not done them. Steps 5 and 6 have real bills attached.

Frequently asked questions

What is an agent harness?

An agent harness is everything around the model that turns it into a working agent: the execution loop, tool connections, injected rules and context, permission boundaries, and the checks that validate its output. Rough equation from the 2026 literature: Agent = Model + Harness.

How is harness engineering different from prompt engineering and context engineering?

Prompt engineering shapes one request. Context engineering controls what information the model sees across a task. Harness engineering designs the whole system around the model: tools, constraints, verification loops, and orchestration. Each subsumes the previous one, and by 2026 the real gains come from the harness layer.

What is the Ralph Wiggum technique?

A loop that repeatedly runs an agent against the same prompt, each time in a fresh context window, with progress stored in files and git instead of the conversation. Originated by Geoffrey Huntley in 2025, it prevents long-task failures caused by degraded full-context judgment, and Claude Code now ships it as an official plugin.

Will better models make harness engineering obsolete?

The evidence so far says the harness changes shape rather than disappears. Anthropic reports that even Opus 4.5, a frontier coding model, falls short on multi-window projects without initializers, progress files, and evaluators around it. A harness encodes assumptions about a specific model, so model progress relocates the scaffolding; it has not eliminated it.

Sources

• Osmani, A. (2026). Agent Harness Engineering. addyosmani.com, also published on O’Reilly Radar. https://addyosmani.com/blog/agent-harness-engineering/
• Anthropic (2025). Effective harnesses for long-running agents. Anthropic Engineering. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Anthropic (2026). Harness design for long-running application development. Anthropic Engineering. https://www.anthropic.com/engineering/harness-design-long-running-apps
• Huntley, G. (2025). Ralph. ghuntley.com. https://ghuntley.com/ralph/
• Anthropic (2026). ralph-wiggum plugin. Claude Code repository (vendor code). https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum
• GitHub (2026). Spec Kit. Open-source toolkit (documentation). https://github.com/github/spec-kit
• AWS (2026). Kiro. Product documentation. https://kiro.dev/
• Fission AI (2026). OpenSpec. Open-source SDD framework (documentation). https://github.com/Fission-AI/OpenSpec
• snarktank (2026). ralph. Open-source autonomous loop runner (repository). https://github.com/snarktank/ralph
• Anthropic (2026). Orchestrate subagents at scale with dynamic workflows. Claude Code documentation. https://code.claude.com/docs/en/workflows
• Claude Directory (2026). Claude Code Worktrees Guide. Practitioner guide (secondary). https://www.claudedirectory.org/blog/claude-code-worktrees-guide