Harness engineering is the practice of treating the runtime around a model as the system you design, test, and tighten — so that when an agent fails, you change the environment, not only the prompt.

LangChain defines the object: Agent = Model + Harness. Harness engineering is what you do to that object. Addy Osmani puts the payoff in one line: a decent model with a great harness beats a great model with a bad harness. Birgitta Böckeler’s article on martinfowler.com is the user’s-side map for coding agents: guides in, sensors back. Thoughtworks then asked the organisational question: how you scale that harness across a company without turning every team into a snowflake of markdown files.

The practice showed up because prompt engineering hit a wall that everyone could see and nobody wanted to name. You can spend a week on a system prompt. The agent will still skip the test, ignore the style guide, or report the task finished. The model is non-deterministic. The prompt is interpreted, not executed. The harness is code. That is the whole discipline.

This is not a replacement for prompt or context work. Those live inside the harness. Harness engineering is the wider loop: every failure becomes a rule, a hook, a test, or a denied tool — the ratchet Osmani describes — so the same mistake is cheaper the second time and impossible the tenth.

Words you’ll hear

Ratchet. A failure updates the harness. Commented-out test → pre-commit hook and a reviewer check. Invented CRM field → schema quote and a Hard gate. If you only fix the artefact by hand, you did operations. You did not do harness engineering.
Guides (feed-forward). Context the agent gets before it acts: AGENTS.md, CLAUDE.md, architecture notes, company wiki playbooks. Böckeler’s term. Advice. Necessary. Not a stop.
Sensors (feedback). Deterministic checks (compiler, linter, schema, pytest) and inferential checks (LLM reviewer, specialist critic). Thoughtworks on sensors. Without sensors the agent grades its own homework.
Hooks. Lifecycle intercepts that always run. Claude Code can block a tool with exit code 2. LangChain middleware is the library form. A guide that says “never run rm -rf” is not a hook.
Harness-as-a-service. Osmani’s HaaS framing: you used to build on completion APIs; you now build on runtime APIs (Claude Agent SDK, Codex SDK, OpenAI Agents SDK) that already own the loop, sandbox, and hooks. You configure; you do not re-implement ReAct.
Skill issue. HumanLayer’s joke with a serious edge: most agent failures are configuration. Blaming the model first is how teams wait for the next release instead of adding a sensor.
Organizational harness. Thoughtworks’ enterprise layer: who may build which harness, how exceptions work, identity, economics, learning. The gap after builder harnesses (Claude Code, Cursor) and user harnesses (guides and sensors on a repo).
Eval loop. Independent verification that does not take the model’s word. SWE-bench and Terminal-Bench for code. Quoted payload vs executed write for operations. See eval loops for enterprise agent harnesses.

In Nimbus, harness engineering for operators looks like: wiki revisions as guides, connector scopes as tool policy, Soft / Hard / Critical as hooks on the write plane, and the Lifecycle Graph as the sensor log you can query. That is the same discipline as adding a linter. The artefact is a signed CRM change rather than a green CI job.

Why you should care

If you only tune prompts, every incident is a conversation. If you engineer the harness, incidents become tests. NIST’s AI RMF Measure and Manage steps assume you can change controls after you observe harm. A prompt history is not a control change. A hook that now fires is.

It affects you if:

agents already write code or propose writes to live systems
two teams have two CLAUDE.md files that contradict Legal
you cannot say which harness version ran last Tuesday
spend is “the model was verbose” rather than “the loop had no budget”
auditors ask who could have stopped the action, and the answer is “the model was supposed to ask”

McKinsey’s 2025 State of AI keeps showing usage without redesign. Harness engineering is the redesign for agentic work: not a new department named AI, a runtime with stops. ISO/IEC 42001 wants named AI actors and documented operational controls. You cannot name actors if every operator’s personal GPT is a different harness.

Coding teams already have half of this and do not always notice. Types, tests, CI, CODEOWNERS — Böckeler’s point is that those are sensors. The work is to point the agent at them and to add the ones that are missing (architecture fitness, behaviour: did it do what was asked). Operations teams usually have the human version — maker-checker, SoD, SOX — and have not yet wired those instincts into a loop. Write-back governance is that wiring. Human-in-the-loop approval architecture is the state machine.

Air Canada’s chatbot and the sanctioned ChatGPT brief are what happens when generation reaches a system of record with no ratchet. The fix is not a sterner system prompt. The fix is a harness that cannot emit a commitment or a filing until a named person has seen the artefact.

The practice, not the slogan

1. Work backward from the behaviour you cannot afford to miss once. Inner loop: never merge without tests; never git push --force to main. Outer loop: never PATCH Opportunity.Amount without a Hard quote. Write those as hooks, not as paragraphs.

2. Separate advice from invariants. Anthropic’s steering note for Claude Code is unusually clear: CLAUDE.md is always-on context; hooks fire on events and can block. If a rule must hold when the model is tired, it graduates from markdown to a hook. Enterprise equivalent: playbooks in the wiki versus the interceptor in governance. If they conflict, the interceptor wins.

3. Put verification outside the generator. Anthropic’s long-running harness uses incremental commits and end-to-end checks so later sessions cannot declare victory by vibes. Coding sensors: pytest, tsc, lint. Enterprise sensors: schema of the quote, identity of the signer, hash of the payload that executed, connector grant still attached. The model may propose that it is done. The harness decides.

4. Version the harness. Which AGENTS.md, which wiki revision, which team contract, which approval tier ran. What is an agentic workflow already treats workflow version as an input. Harness engineering extends that to tools and gates. Hot-patching production prompts without a change record is how Tuesday becomes unexplained.

5. Budget the loop. Max steps and a cost cap that do not depend on the model’s judgement. Seat licences hide this; metered work makes it visible. See What is model routing and AI cost control architecture. Always-flagship is not careful. It is an unengineered harness.

6. Do not fork a harness per person. User-owned bots are how mandates drift. Org-level agent teams assigned to workstreams is the enterprise form of “one CI config per repo, not one per intern.” Thoughtworks’ organisational harness is this ownership question: who is allowed to add a write tool.

Nimbus encodes several of these as product defaults — read-only connectors until you enable write, quoted payloads, graph on the way out — because operators should not have to re-implement ReAct to get a ratchet. You can still fail the practice: a wiki that is never updated, a Critical tier nobody uses, a graph nobody queries. The product is not the practice. The practice is whether last month’s incident produced a new gate.

How this differs from adjacent crafts

Prompt engineering improves a single call. Necessary for tone, tool descriptions, and “what good looks like.” Insufficient for tool dispatch, identity, and replay.

Context engineering governs what the model sees this turn: compaction, retrieval, files. Anthropic’s initializer agent is context engineering in a harness. It is not permission to write NetSuite.

Platform / DevOps. CI, sandboxes, secrets. Harness engineering reuses those as sensors and execution environments. It adds the fact that the component in the loop is non-deterministic, so “the job returned zero” is not enough: you need independent tests of the claim.

Governance-as-PDF. Policy. Harness engineering is whether the tool call is reachable. How to evaluate AI governance platforms is the buying cousin.

Framework assembly. Writing LangGraph nodes is building a harness in code. Harness engineering is the ongoing discipline after the graph exists: sensors, ownership, eval. See agent harness vs agent framework.

Four layers, one ratchet

Thoughtworks’ July 2026 essay is the organisational map most engineering blogs skip. They split enterprise AI into four harness layers. Most companies have built one, maybe two. The gap is not a smarter model.

Layer 1 — the model. Substrate. Choice still matters for cost, residency, and task fit. It is the wrong unit of analysis for a programme. Teams that prototype, hit a failure, and buy the next flagship are looping on layer 1.

Layer 2 — the builder harness. Frameworks, tool access, memory, where inference runs. LangChain, Claude Agent SDK, AIP-style platforms, Nimbus’s hosted loop. Without layer 3, every team invents naming and review. Without layer 4, nobody owns failure.

Layer 3 — the user harness. Guides and sensors on the job. Böckeler’s taxonomy lives here. Thoughtworks add a useful matrix: feed-forward vs feedback, crossed with deterministic vs probabilistic. Deterministic feed-forward is a whitelist and a spend ceiling — cheap, auditable, default. Probabilistic feed-forward is a runbook retrieved at decision time. Deterministic feedback is schema validation after the act. Probabilistic feedback is an eval model on a rubric — expensive, use on critical paths only. A guide with no sensor is theatre.

Layer 4 — the organisational harness. Who may grant which autonomy, escalation, accountability when layers 1–3 all “worked” and the company still took harm. Thoughtworks’ public cases: Parloa, where versioned rules, skills, commands, and helpers lived in the repo (they report p95 latency drops they attribute to harness architecture, not a new model); Morgan Stanley, where hygiene and CVE triage used a delegation tier instead of a yes/no “do we trust the agent.” You do not need those vendors to accept the lesson: governance that is not versioned next to the work decays.

Harness engineering is the steering loop across those layers. Sensor data reveals a miss. Guides update. Hooks graduate. Templates change. The next job is cheaper. An organisation with that loop has a compounding harness. An organisation without one has markdown that rots while models improve.

A concrete week: Monday the agent comments out a flaky test (inner) or proposes Amount without CloseDate (outer). Tuesday a human fixes the artefact. That is operations. Harness engineering is Tuesday’s hook or schema sensor, Wednesday’s wiki or AGENTS.md line, Thursday’s replay that the new control fired. Friday you run the job ten times and count refuses. Nimbus makes the outer version of that week a product surface — governance queues, graph export — so operators are not waiting on a platform sprint to add the sensor. You still have to look at the refuse count. A product without a steering cadence is layer 2 with a nicer UI.

What good looks like

Good: a named owner for the harness (not “AI working group”), a cadence that turns incidents into controls, deterministic gates on knowable bounds, inferential checks only where judgement is required, versioned guides, exportable traces. Failure: a new system prompt after every incident; sensors the agent can skip; no owner; SWE-bench as the only score for a CRM job; layer 4 as a PDF.

Osmani’s ratchet and Thoughtworks’ steering loop are the same instinct. How to evaluate an agent harness asks whether your vendor lets you run that instinct.

Questions people actually ask

Who coined “harness engineering”?

The phrase circulated in early 2026 across OpenAI engineering notes (Ryan Lopopolo’s line of work), LangChain’s anatomy posts, Böckeler at Thoughtworks, and Osmani’s synthesis. Treat it as a shared 2026 name for work teams were already doing, not a trademarked method.

What is Harness Engineering

Words you’ll hear

Why you should care

The practice, not the slogan

How this differs from adjacent crafts

Four layers, one ratchet

What good looks like

Questions people actually ask

Who coined “harness engineering”?

Is this only for coding agents?

Do we wait for a better model instead?

How do we start this quarter?

How does Nimbus fit without becoming the definition?

What should I read next?

Sources

Related guides

Multiplayer AI vs multi-agent AI: what is the difference?

What is an Enterprise Agent Harness

See what governed AI looks like on your stack.