Harness engineering is the discipline of designing everything around the model (rules, tools, memory, and verification) so an agent works reliably in production. Mitchell Hashimoto, creator of Terraform, named the practice in February 2026. The formula that sums it up, Agent = Model + Harness, comes from LangChain.
Note: "AI harness" here is the software concept — the infrastructure around an LLM that turns it into a reliable agent — not harness.io (the CI/CD platform) nor the literal harness/wiring sense of the word.
New here? Start with the canonical definition: what is an AI harness.
The term that showed up in 2026
Harness engineering is the engineering work on the harness: the layer of code, configuration, and rules that sits around the model. Mitchell Hashimoto named the practice in "My AI Adoption Journey" (February 5, 2026), writing that he didn't see an industry-accepted term yet and had grown to calling it harness engineering. His definition is operational: every time the agent gets something wrong, you engineer a permanent fix so that error never repeats. It isn't tweaking a prompt in the moment. It's turning each failure into a rule.
Not a rebrand: the proof
The obvious question is whether harness engineering is just a new name for prompt engineering. The answer came as a number. LangChain ran the same model (gpt-5.2-codex) on Terminal Bench 2.0 and, by changing only the harness, went from top 30 to top 5: from 52.8 to 66.5, a gain of 13.7 points (February 17, 2026). Same model, different harness, materially different result. That isn't renaming prompts. It's one benchmark, but the signal is clear: the lever isn't only in the model.
What it's made of: guides and sensors
| Component | What it does | Example |
|---|---|---|
| Guides (feedforward) | Anticipate and direct the agent before it acts | Operating rules, CLAUDE.md, allowed tools |
| Sensors (feedback) | Observe after the action and help the agent self-correct | Tests, linters, and typecheck as agent-readable signals |
| Memory | Turns each error into a permanent fix that survives the session | Versioned rules, error-to-rule loop |
| Quality gates | Block output that fails the criterion | Minimum coverage, zero new warnings |
| Observability | Makes the agent's behavior auditable | Per-phase artifacts: spec, plan, report |
Harness engineering isn't a framework, a prompt, or RAG
Worth separating. An agent framework (LangChain, LlamaIndex) is a library for building the loop; harness engineering is the discipline of designing the whole environment around it. Prompt and context engineering handle what the model sees; harness engineering includes that plus what the model can do, what it's forced to comply with, and what persists across sessions. RAG is a subcomponent, not a synonym. And there's an honest counter-argument: Nicolas Bustamante (Model-Harness-Fit, May 2026) shows model and harness are becoming inseparable, "you cannot just swap a model." He's right, and that's exactly why the harness is where the engineering happens: swapping the model forces you to re-engineer the harness around it.
The coding harness is the visible part
Almost everyone talking about harness engineering today means the coding harness: Claude Code, Cursor, agents that read a repository, edit files, and run tests. That's the visible part. The bigger part, and the one where almost no one is engineering with discipline, is the operational harness: the same pattern applied to running an entire business, AI beyond code, knowledge, memory, and governance. That's where Capiva works. We solve the coding layer with capivaOS, the open-source harness on top of Claude Code. The operational layer we build in production, and the account is in AI Harness in Practice.
The evolution of the AI harness: from a bare model to a self-improving system
The model is the talent; the harness is the job around it. Between 2019 and 2026 the harness grew in five layers — briefing, capabilities, quality and team, always-on runtime, and self-improvement — and each layer added a control enterprises did not have with a bare model. Mitchell Hashimoto named the discipline harness engineering in February 2026: whenever an agent makes a mistake, you engineer a permanent fix into its environment so that mistake never repeats.
Timeline · 2019–2026
Drag the marker or use the arrow keys to watch the harness grow.
01 / 13Version 0 · bare model
2019Bare model
The harness barely exists: a short instruction, a request, the model, and an output. No tools, no memory, no review.
New in the harnessRequest · Model · Output · Instructions
Layer 1 · Briefing: what the assistant gets before it starts
The briefing is the instructions, examples, playbooks, and limits the model sees before it acts. Without it, the harness barely exists.
What changed. In 2019 the loop was thin: short instruction, request, model, output. In 2020, few-shot examples showed that a richer brief beats retraining. In 2022, chain-of-thought made the path to the answer readable. Playbooks and hard limits on steps and access followed.
For the business, it’s like… Onboarding by example: instead of describing the report format, you hand over three finished ones and say “do it like these.”
What it unlocked. Consistent format and tone without retraining; adaptation to a new task in minutes; reasoning you can audit.
Governance you gain. The quality bar is written down. Examples are the spec the work is judged against. Step and access limits become policy, not hope.
Read next: what is an AI harness · harness vs RAG and context engineering
Layer 2 · Capabilities: tools, memory, and what the model may touch
Capabilities are everything beyond text: tools and systems (including MCP), editable memory, experience history, and — when needed — a tool built on the spot.
What changed. From 2021 on, models call real software instead of guessing (WebGPT, Toolformer). In 2023, MemGPT showed memory the model itself creates, updates, and discards. Anthropic’s Model Context Protocol (November 2024) standardized how tools are described and connected. Then came tools written on the spot: a small program, run, result used.
For the business, it’s like… Giving the new hire their system log-ins. Nobody expects the finance analyst to close the quarter in their head.
What it unlocked. Exact numbers and current information; actions in real systems; continuity across sessions; fewer dead ends.
Governance you gain. You decide, system by system, what the AI may read and what it may change. Memory becomes data with a retention policy. Code the agent writes and runs needs a sandbox and an approval step.
Read next: how to build an AI harness · capivaOS
Layer 3 · Quality and team: internal reviewer, subagents, and triggers
Instead of one pass, the harness reviews before a human sees the work, and one assistant can coordinate specialists with different briefs and access.
What changed. From 2022 to 2023, ReAct, Self-Refine, and Reflexion made the execute → review → fix loop practical. In 2024–2025, spawning helpers became a tool. On September 29, 2025, Anthropic released the Claude Agent SDK with subagents and hooks — the same core tools, context management, and permissions frameworks that power Claude Code. Triggers (message, meeting, schedule) started waking the work.
For the business, it’s like… Peer review plus a project lead who scopes, delegates, tracks, and consolidates.
What it unlocked. Fewer errors reaching customers and decision-makers; large projects no single pass can handle; specialization by brief and by access.
Governance you gain. QA moves ahead of the human, with a record. Budgets and limits cap cost and runaway behaviour. Specialists with separate access enforce segregation of duties.
Read next: guardrails and evals · how to create subagents in Claude Code · the Claude Code harness
Layer 4 · Always-on runtime: saved state and resume after failure
The assistant no longer exists only while someone has it open. The loop runs on a server, saves state at every step, and resumes after a crash.
What changed. Until here the harness was a session. By 2026, always-on agents live in their own runtime: triggers wake the work, an action check validates sensitive commands, and state survives a crash. Capiva runs this pattern in its own operation (capivaOS): the harness stays up; the model is swappable.
For the business, it’s like… A contractor who works only while you are in the room, versus a colleague with a desk, a log-in, and an inbox who picks things up overnight.
What it unlocked. Work that survives a crash and runs for days; tasks started by events, not only by typing.
Governance you gain. You decide what may wake it, which actions a second model checks, which wait for a person, and where credentials live. Untrusted input is data, never an instruction.
Read next: AI Harness in Practice · how we work
Layer 5 · Self-improvement: brief optimizer, version archive, business metric
A self-improving harness does not only run the brief better — it tries brief variants (and, in research, its own structure), archives every version, and promotes the one that hits the metric you defined.
What changed. With DSPy (2023), the system stops depending only on hand-written instructions: given good examples, it tries many brief versions, measures, and keeps the winners. In 2025, the Darwin Gödel Machine showed rewriting not just the brief but parts of the harness itself — tools, helpers, review — with a version archive. In 2025–2026, continual harnesses add experience history and, part product / part research, learning from real use.
For the business, it’s like… A/B-testing the job description at scale, then an ops team that redesigns its own org chart every week and promotes what delivers most.
What it unlocked. Better performance without hand-writing every instruction; fast re-tuning when you switch model or task; methods people would not think to try.
Governance you gain. Control shifts to the metric: whatever you measure is what the system will optimise. Choose it with care. Every version is archived and can be rolled back — governance becomes change management. When the model itself learns, oversight covers what it learns from and how that learning is reviewed.
Read next: how to build an AI harness
Prompt, context, and harness engineering: scopes that stack
They are not eras that replace each other. They are expanding scopes: harness includes prompt and context, plus execution, tools, state, verification, and governance.
| Scope | Cares about | Unit of design |
|---|---|---|
| Prompt engineering | Instructions, examples, formats, reasoning templates for a call | The model invocation |
| Context engineering | What the model sees at each step: documents, memory, prior turns | Information state |
| Harness engineering | Prompt + context + execution environment, tools, persistent state, lifecycle, observability, verification, and governance | The closed-loop system |
The Agent Harness Engineering survey (Li et al., 2026) treats the three as expanding scopes, not historical stages: the broader includes the narrower.
Read next: harness vs RAG and context engineering
Governance lens: every component is a control
The harness is where the enterprise actually decides permissions, memory, review, triggers, and metrics. Without a harness there is no agent governance — only a model that answers.
Australia’s ASD (cyber.gov.au), in Agentic AI harnesses (September 2026), defines the harness as the software layer that connects the LLM to data, tools, memory, and planning workflows, and that enforces action privileges. If the LLM is the brain, the harness is the body — and the control point.
| Harness component | Control | Risk it mitigates |
|---|---|---|
| Instructions, examples, limits | Policy and scope | Agent off-mandate |
| Tools / MCP / systems | Permission per system | Excess data and action access |
| Editable memory | Retention and privacy | Sensitive data that sticks without policy |
| Playbooks | Operational compliance | Inconsistent procedure |
| Tool built on the spot | Sandbox and approval | Unreviewed code in production |
| Internal reviewer / evals | QA before the human | Errors reaching customers or decision-makers |
| Team of assistants | Budget, limits, segregation | Runaway cost; privilege pile-up |
| Triggers + always-on runtime | Trigger trust, identity, secrets | Agent woken by hostile input |
| Metric + version archive | What is optimised; rollback | Wrong metric; change without a trail |
Frequently asked questions
What is harness engineering?▼
It's the discipline of designing everything around the model (rules, tools, memory, verification, and orchestration) so an agent works reliably in production. It was named by Mitchell Hashimoto in February 2026. The core idea: every agent error becomes a permanent fix in the harness, not a one-off patch.
Who coined the term harness engineering?▼
Mitchell Hashimoto, co-founder of HashiCorp and creator of Terraform, in "My AI Adoption Journey" (February 5, 2026). He named the discipline. The formula Agent = Model + Harness is separate: it came from LangChain (Vivek Trivedy, March 2026). Don't conflate the two attributions.
What's the difference between harness engineering and an agent framework?▼
A framework is a library for building the agent (you write the loop). Harness engineering is the discipline of designing the execution environment around it: rules, gates, memory, and tools. LangChain is a framework; designing the harness that runs on top of Claude Code is harness engineering.
What are guides and sensors?▼
It's Birgitta Böckeler's taxonomy (Thoughtworks), published on Martin Fowler's site on April 2, 2026. Guides are feedforward: they anticipate and direct the agent before it acts (rules, CLAUDE.md, allowed tools). Sensors are feedback: they observe after the action and help it self-correct (tests, linters, typecheck read by the agent).
Is harness engineering the same as context engineering?▼
No. Context engineering handles what the model sees (context retrieval and curation). Harness engineering includes that plus what the model can do, what it's forced to comply with, and what persists across sessions. Context engineering is one part of the harness, not a synonym.
How do I start with harness engineering?▼
Start with the correction loop: every time the agent errs, write a permanent rule instead of fixing it by hand. Then add guides (rules and allowed tools) and sensors (tests and linters the agent reads). For the coding layer, capivaOS gives you a ready harness on top of Claude Code; the operational layer is designed on your own stack.
How did the AI harness evolve?▼
In five layers from 2019 to 2026: briefing → capabilities (tools, memory, MCP) → quality and team → always-on runtime → self-improvement. Each layer added a control the bare model never had.
What is a self-improving harness?▼
A harness that tries brief variants (and, in research, its own structure), archives every version, and promotes the one that performs on a business-defined metric — with human-controlled rollback.
How does the harness help with AI agent governance in enterprises?▼
It is the layer where permissions, memory, review, triggers, and metrics are actually enforced. Without a harness, the AI is a box that answers; with one, each component becomes a control (ASD, Agentic AI harnesses, 2026).
Which harness components become governance controls?▼
Instructions and limits (policy), tools/MCP (permission), memory (retention), playbooks (compliance), sandbox (generated code), reviewer/evals (QA), subagents (segregation of duties), runtime/triggers (identity and trigger trust), metric and version archive (optimization and change management).
You swap the model. You engineer the harness, and it's the harness that decides whether the agent works.