A harness is not "everything that isn't the model"

Harness engineering went from a coinage to a discipline in about ninety days. Mitchell Hashimoto named it for a habit: every time an agent makes a mistake, engineer a permanent fix into its environment so the mistake cannot recur. OpenAI formalised it after shipping a million-line production application with zero hand-written lines, crediting the harness around the agents rather than the model inside them. Then LangChain rebuilt only the harness around its coding agent, three changes, and jumped from 52.8% to 66.5% on Terminal-Bench 2.0 with the weights untouched. The industry jumped on board and converged on a definition: the harness is everything that isn't the model.

While this definition is true by construction, it’s useless in practice. It tells you where the harness ends, not what it must contain. By that definition, a folder of prompt files is a harness, and a pile of MCP servers someone installed in March is a harness. Most of what gets called a harness today is configuration sprawl: accumulated tweaks, each one reasonable, with no architecture holding them together.

So, the way I talk about harnesses is: A harness is the system that turns a rented model into your delivery capability, and it has four load-bearing functions: what the agent knows, what it may do, how work moves, and how truth is verified.

And I build these as four named components: knowledge layers, guardrails, workflows, and verification. If you can’t point at all four in your setup, it’s not a harness yet.

The biggest quality lever in an agentic SDLC is what the agent knows when it starts. Most setups stop at a repository-level context file, and it shows: the agent produces code that is locally plausible and globally wrong, because real software spans services, teams, and a business domain. So we structure knowledge in four layers.

• Level 1 is the repository: architecture, conventions, and build-and-test commands.
• Level 2 is the system: dependency maps and shared contracts, the layer that tells an agent which changes ripple where.
• Level 3 is the organisation: standards, security policy, ownership and approval flows, encoded once and inherited by every team.
• Level 4 is the domain: the business concepts and rules of the world the software serves, so the agent writes code that makes sense in your business rather than code that merely compiles.

The session state an agent accumulates as it works sits on top of all four, and is the only part that is disposable. The layers are not equal: hard constraints from the domain and organisation outrank conventions from the codebase, which outrank anything in the live session, and an agent acting under a hard constraint cites the specific policy it applied. Every consequential decision traces to a rule rather than a vibe, and every layer eventually compiles into an executable check, which is where the verification checks come from.

Guardrail architecture starts from one non-negotiable rule: the agent never executes anything. It only ever returns typed intents, a structured tool call to edit a file, run a command, or push a branch. The harness validates the schema, checks the request against a deny-first permission matrix keyed by risk class, and executes on the agent's behalf inside an ephemeral sandbox. The risk classes are read-only analysis, reversible branch writes, merges to main, and deploys or migrations, and each class sets its own bar. The agent gets back a structured observation: a result, a permission denial, or a timeout. The model proposes; the harness disposes. A prompt injection buried in a README can at worst persuade the agent to propose an action, and a proposal is exactly the thing the permission layer exists to refuse.

Guardrails are not primarily about restriction. You can only give an agent more freedom when you can bound precisely what that freedom means, so the teams with the strictest guardrails end up running the most autonomous agents. Restriction and autonomy are not opposites in a harness; one is the precondition for the other.

Most "agentic" setups are a chat window with better tools, and you can tell because the workflow lives nowhere: it exists only as the transcript of what someone happened to ask for. In our harness, the delivery workflow is an artefact. It is a declarative graph of stages, spec, plan, implement, verify, review, merge, in which agents, scripts, and humans are typed, interchangeable nodes. Because the graph is declarative, it lives in version control, it is reviewed like code, and swapping a human node for an agent node when the evidence supports it is a one-line change rather than a re-architecture.

Humans are first-class nodes, not spectators. A human gate suspends the run and accepts approve, revise, or reject, and a revise re-runs the upstream stage with the feedback baked in, so human judgement enters the loop as structured input rather than as a comment someone hopes the agent reads.

An agent's claim that it is done is worth nothing; verification is how the harness finds out, and it has two parts: continuous checks that run alongside the work, and verification gates that consume their results. The human gate in a workflow, the promotion gates on the autonomy gradient, and the release gates in CI are all the same mechanism, a verification gate, fed by checks that come in four kinds along a spectrum ordered by cost. Static checks, the compiler, type checks, linters, run in seconds on every loop iteration, and the compiler never hallucinates. Dynamic tests actually run the code: unit, integration, and end-to-end suites against ephemeral preview environments. Perceptual checks cover what tests cannot: screenshot diffs and vision models inspecting the rendered UI, because everything can be green while the button is invisible; an agent doing frontend work without them is being graded on homework nobody looks at. Judges, LLMs audited against human reviewers, score what cannot be computed or rendered, and releases gate on statistical lower bounds rather than raw pass rates. The statistics of trusting judges and gates get their own post in this series.

Modern agents can build the system, boot it in the sandbox, drive a browser through the flow they just wrote, and read the logs, and we want them to, because verification inside the work is the cheapest place to catch failure. But an agent checking its own work is grading its own homework, so we draw a hard line: the agent may verify, the harness must witness. Agent-conducted verification produces artefacts, test transcripts, screenshots, probe logs, and it is those artefacts, adjudicated by verification gates the agent cannot skip, that count as evidence. Verification the agent merely claims to have done never happened.

The components answer what a harness is; the method answers how one comes into existence. We start from behaviour, not tooling: before an agent touches a repository, we write what it may do, what it must never do, when it must hand back to a human, and how we would recognise good work. Every line of that specification must become either a guardrail or an executable check. If a requirement cannot be turned into one of those two artefacts, it is not yet a requirement. It is a hope.

Autonomy is then earned and never configured. Every capability starts at the conservative end, the agent suggests and a human decides, and is promoted along the gradient, to drafting, to merging with approval, to shipping autonomously in bounded change classes, only when the evidence clears the bar set by its risk class. Migrations never fully leave the approval gate, whatever the numbers say, and demotion is automatic: a revert-rate alarm drops the capability a level first and convenes the humans second.