Agent harnesses: five layers, and how to build your own

TL;DR

A harness is all the software wrapped around a model that turns it into something which does things instead of answering messages. The formula that settled in during 2026 is short: agent = model + harness. Nearly all the public attention goes to the first term; nearly all the defensible advantage lives in the second. This article maps the five layers of a harness, compares the most capable open and closed harnesses in the field today, and shows why the verticals that actually work — Harvey and Legora in law, Rogo and Hebbia in finance — did not win by training a better model. They won by building their industry's harness. It closes with the concrete route to building yours.

The harness is the product, not the model

One number from this year organises the whole discussion. When OpenAI launched GPT-6 Astra, the figure quoted everywhere was 99.9% on ARC-AGI-3. That number was measured with a provider adapter — a modified harness, not a modified model. Without it, the same model scores around 70%. We covered it in detail in our GPT-6 Astra analysis.

Thirty percentage points on identical weights. That gap is the size of the space harness engineering lives in, and it is why "which model should we use?" has become a far less interesting question than "what do we let it see, what do we let it touch, and how do we check that it finished?".

The most useful working definition is Databricks': "an AI agent harness is the software infrastructure that wraps around a large language model and enables it to act on tasks, not just respond to prompts." The harness decides what the model sees, which tools it may call, where state is kept, how observations come back, when validation runs, how failure is recovered, when it is allowed to stop, and how one or many model calls are arranged.

Anatomy: the five layers

The 2026 literature converges on a layered architecture. The survey Natural-Language Agent Harnesses (arXiv 2603.25723) orders them as below, and it is the skeleton worth holding in your head while designing one:

On that skeleton, Databricks enumerates the eight components that have to exist somewhere: system prompts, tools and their execution, sandboxes, durable filesystem, memory and context management, verification loops, guardrails with a human in the loop, and observability. Which layer you put them in is an architecture decision. Leaving one out is not a decision — it is a debt that gets collected in production.

All of it turns in a ReAct loop: the model reasons, the harness executes, the result comes back as an observation, and the cycle repeats until something decides it is finished. That "something" — the stopping condition — is the most underrated piece, and the one that most separates a serious harness from a while loop with an API call inside.

The 2026 map: open and closed

The field filled up fast. These are the harnesses setting the state of the art, listed with the architectural property that makes each worth studying.

Open

Closed

Two signals that this layer is maturing, and that are worth not ignoring. First: the Linux Foundation stood up an Agentic AI Foundation in 2026 on three donations — Anthropic's Model Context Protocol for tools, OpenAI's AGENTS.md for instructions, and Goose. Second: Zed, OpenHands and DeepSeek Harness all speak the Agent Client Protocol, which means they can drive each other. The interfaces between layers are standardising, and that means building your own no longer starts from zero.

What separates a serious harness from a while loop

Compare the harnesses above and the differences are not in the prompt. They are in seven decisions:

• Per-operation permissions. Reading is not writing, writing is not deleting, and deleting in staging is not deleting in production. Cline asks per edit; Claude Code asks per operation type. A harness without graded permissions has exactly two modes: useless and dangerous.
• Real isolation. A genuine sandbox is nsjail or a container, not a list of forbidden commands. The difference shows up the day the agent composes a command that is not on your list.
• Points of return. Aider's automatic commits and Muse Code's isolated worktrees solve the same problem: being able to undo without hand-reconstructing what the agent touched across 40 turns.
• Verification the agent can run itself. In code that is the test suite: the agent knows it finished because something turns green. This is the piece each industry has to invent, and the one that decides whether the project works.
• Context management. Compact, summarise, retrieve, forget. An agent that fills its window with tool output stops reasoning long before it runs out of tokens.
• Subagents. Delegating a sub-task to a copy with its own context keeps reading work from contaminating the main thread. Antigravity, Claude Code and Muse Code do it; Hebbia does it in finance by separating retrieval from drafting.
• Observability. Traces per action, not logs per session. Without it there is no debugging, and in a regulated industry there is no defence either.

The verticals already arrived: finance and law

This is the part worth reading slowly, because it is the evidence that this is a market rather than an idea.

Law

Harvey runs autonomous loops in the classic shape: plan the approach, execute sub-tasks, evaluate intermediate results, adjust, and continue until the goal is met — with the agent deciding which tools to use, which documents to prioritise, and when its own output needs revision. Its stated advantage is not the model: it is platform depth, on the order of 25,000 custom agents plus an Agent Builder that lets firms assemble their own.

Legora attacked from the domain-interface side. Its Tabular Review turns a folder of hundreds of contracts into an interactive grid for comparing clauses and extracting data at scale. During 2026 it acquired Walter AI for agent-native workflow automation and Qura for legal research. What both companies sell underneath is the same thing: tools purpose-built for legal work — tabular review, integration with the firm's document management system, redlining, research — human approval at the points that matter, and complete audit trails where every action the agent takes is traceable, reviewable and defensible.

Finance

Rogo is the most literal case: a vertical company with the entire stack — from the models to the interface — purpose-built for finance professionals. Its agent, Felix, executes multi-step financial workflows: deal screening, CIM generation, comparables, model building, pitchbook preparation, earnings synthesis and diligence memos. It ships with integrations to Pitchbook, Capital IQ and Datasite, finance-specific templates and per-deal compliance logging. That last item is the explicit commercial argument against a generalist model: a general-purpose LLM does not produce regulator-ready audit trails broken out by deal.

Hebbia solves a different piece with an interesting architectural decision: specialised subagents that separate retrieval from output formatting, and a data grid where every cell links to its source citation. That is why law firms, consultancies and private-equity diligence teams use it for data-room analysis.

Note what none of the four did: none of them won by training a better model than the frontier. They won by building layers 3, 4 and 5 for one specific trade.

Translating the layers to your industry

Here is the practical thesis: the five layers are generic, but the contents of three of them are specific to your trade — and that is where your advantage sits, not in the loop.

The middle row is the one that decides the project. In code, verification comes free: there are tests, a compiler, a linter, and the agent can run all of them without asking anyone. That is why code harnesses arrived first — not because programming is easier than litigating.

The good news is that in most back-office processes the check already exists; it is just executed today by a person with a list. Reconciling an account, balancing a ledger, verifying a contract does not deviate from the playbook, confirming every figure in a report appears in the source: all of those are explicit rules someone applies by hand. Writing them down as code is the work — and it is work that does not expire when the next model ships.

Why build yours instead of buying

Three reasons, and none of them is "it is cheaper".

1. Your process is not your sector's average process. Harvey and Rogo sell the modal workflow of a large firm or an investment bank. The more your operation resembles the average, the more sense buying makes. The more specific it is — and the operations that carry margin are usually the specific ones — the less the generic product covers.
2. The harness is where your knowledge lives, and it does not depreciate. Model weights get replaced every few months. Your trade's verification rules, your integrations and your definition of "done" outlive that turnover. Which is a good argument for owning them.
3. The data and the trail stay in. In regulated sectors that usually stops being a preference and becomes a requirement. OpenHands exists precisely for that case.

How to start without burning six months

The common mistake is to start at the control layer — the loop, the subagents, the planner — because it is the fun part. It is also the part that is already solved and that you can borrow. The order that works is the reverse:

1. Pick a process with a checkable ending. Repetitive, with volume, and with a check a machine can run. If it has none, pick another or build the check first.
2. Write the verification before the agent. In code that is tests. In your trade it is a script that answers yes or no to "is this right?". Without it you do not have a harness, you have a chat.
3. Wrap your systems as tools, not as prompts. One MCP server per system, with typed contracts, idempotency and predictable errors. We wrote about this separately in MCP templates for enterprise chatbots and MCP from scratch.
4. Borrow the control layer. Start with an existing harness before writing a loop. Self-hosting, OpenHands. Want to read a minimal one to understand it, Pi.
5. Instrument from day one. Traces per action. On memory and traceability we published the tiered memory pattern with Langfuse and Redis.
6. Permissions before autonomy. Human approval on irreversible actions from the start, loosened with evidence rather than optimism.
7. Measure with evals, not demos. A suite of real cases running in CI. We covered it in agent evals in CI/CD.

reconciliation-harness/
├── tools/                 # execution layer: one MCP server per system
│   ├── erp.ts             # read entries, never write them
│   ├── bank.ts            # statements, read-only
│   └── ledger.ts          # writes, with idempotency and operation_id
├── verify/                # the layer that decides whether it finished
│   ├── tie_out.ts         # sum of entries == statement, to the cent
│   └── tax_rules.ts       # what a person checks today with a list
├── policy/                # permissions: what it may touch unasked
├── traces/                # supervision: one trace per action, not per session
└── evals/                 # 40 real month-end closes, with their outcomes

Notice what is absent from that tree: the loop. That is deliberate. The loop is borrowed and swapped without pain; the other five directories are the asset.

What goes wrong

• Verification the agent can game. If the check is weak, the agent optimises the check instead of the work. Same phenomenon as a test that passes because the assertion was deleted.
• Autonomy before traces. Letting the agent run before you can reconstruct what it did turns any incident into archaeology.
• Tools that are too powerful. A single run_sql is convenient and it is a bomb. Narrow tools with explicit contracts age better.
• Mistaking the pilot for the system. The demo works because the case was chosen; production brings the 20% of odd cases where all the cost lives.
• Buying the vertical and not changing the process. A harness does not fix a process nobody has written down. If the definition of "done" lives in one person's head, that is the first deliverable.

Sources

• Databricks — What is an AI agent harness? (definition and the eight components)
• arXiv 2603.25723 — Natural-Language Agent Harnesses (five-layer architecture and taxonomy)
• explainx.ai — Top 10 agent harnesses, open vs closed 2026
• Legora — 2026: the year of agents in legal AI
• Rogo (Felix) — IB analyst agent for finance and Rogo / Hebbia comparison