This is an introduction to agent harnesses for engineers who are comfortable with software but have not yet built much with autonomous AI agents. It covers what an agent is, the specific way agents fail, what a harness is and why you need one, how a harness differs from a tool like Claude Code or Codex, what a basic harness does, and where to start. It assumes no prior experience with agents.
From asking questions to delegating work
Three years ago, most engineers used AI by opening a chat window, asking a question, and copying the useful parts of the answer. You stayed in control of the work, and the AI helped with pieces of it.
An agent is different. An agent is given a task and allowed to work on it on its own: reading files, running commands, calling APIs, and deciding what to do next, for minutes or hours, without a person approving each step. The tasks have also grown larger. We are no longer asking an agent to fix one bug. We are asking it to build a feature, stand up a service, or migrate a data model.
This matters because once an agent can act on its own, it is making decisions you used to make: dozens of small decisions per run, with no one checking them.
How agents fail
Give an agent a clear task and it will often produce something that looks finished and is wrong.
Here is a real example. We asked an agent to build a UI component in a project that used a specific component library. The agent produced clean, reasonable-looking styles, but it never used the library. It rebuilt from scratch something the project had already standardized on. The output looked correct. It was not usable. When we checked, the agent reported high confidence in the work, both before and after we found the problem.
This is the failure that causes the most trouble, and it is not the kind most people prepare for. An AI that produces obvious nonsense is easy to handle: you see the nonsense and throw it away. The harder case is output that is wrong but plausible. It is wrong because the agent was missing a piece of context and continued anyway, without knowing anything was missing.
You cannot catch this by asking the model how confident it is. The confidence comes from the same system that made the error, so it is not an independent check. A model that is wrong is often confidently wrong.
What a harness is
A harness is the software you build around the model to control what it does.
The model is the part you cannot fully predict. It is fast and capable, and sometimes confidently wrong. The harness is the part you can predict: ordinary, deterministic code that decides what the model is allowed to see, checks what it produces, and decides whether the work is allowed to move forward.
The simplest way to state the division of labor is this. The model supplies capability. The harness supplies control. On its own, the model's capability is not trustworthy enough to delegate to. The harness is what makes it trustworthy enough.
How this differs from Claude Code or Codex
Engineers usually ask this next, because tools like Claude Code, OpenAI's Codex, and Cursor already wrap a model in a loop with tools and some safety checks. In a general sense, those are harnesses.
The difference is in who they are built for and how specific they are.
Tools like Claude Code are general-purpose and built for a person to operate directly. You give an instruction, watch what the agent does, correct it, and approve the risky steps yourself. In that setup, you are the control layer. This works well when one person supervises one agent on one task.
The harness described here is something you build for your own project, and it is meant to run with much less supervision. It encodes your project's specific rules: which context a given kind of task requires, the constraints in your system that must never be violated, what "done" means in your codebase, and which actions require a human's approval. You usually build it on top of a tool like Claude Code, not instead of one.
An analogy. Claude Code is a well-equipped workshop, and a skilled person can do a lot in it. A harness is the production line you set up around the work so it runs correctly without someone watching every step. You build the line using the workshop's tools.
What a harness does
You do not need a sophisticated harness to start. A basic one does four things.
First, it checks that the agent has what it needs before it starts. The component-library failure above happened because the agent did not know which library to use. A harness confirms the required context is present and unambiguous, and if something is missing, it stops instead of letting the agent fill the gap with a guess.
Second, it makes the agent ask instead of guess. When something is unclear, the correct behavior is to stop and ask a specific question, not to pick an interpretation and continue. Guessing is where the plausible-but-wrong failures come from.
Third, it fails loudly. When a test fails or a check does not pass, the work stops and reports exactly what went wrong, instead of working around the problem and passing it to the next step.
Fourth, it requires human approval for actions that cannot be undone. Deleting data, deploying to production, and spending money should wait for a person. That decision is based on what the action is, not on how confident the agent is.
None of this is new, and none of it is specific to AI. It is the same care you would apply to any system you do not fully trust. The difference is that you now apply it to the agent.
How your job changes
When you build with agents, your work shifts from writing prompts to building the system that supervises the agent. The prompt still matters, but most of the reliability comes from the structure around it: what the agent can see, what it is allowed to do, and how you detect when it is wrong.
You do not build all of this at once. Start with a narrow task. Watch where the agent goes wrong. Each failure tells you a rule you need, and you add it. Over time, those rules become your harness.
Where the field is
This is becoming a named discipline. The current term is "harness engineering," and a common shorthand is "agent = model + harness." It is usually described as the stage after prompt engineering and context engineering.
Martin Fowler's write-up is the standard reference. He describes a harness as a combination of guides that steer the agent (instructions and constraints) and sensors that catch it (tests, linters, and other checks). He also separates deterministic checks, such as a failing test, from checks that are themselves the judgment of another model. My view is that the deterministic checks are the foundation, not an option. The core problem is that a model cannot reliably check its own work, so the parts of the harness that enforce correctness should be plain code, not another model acting as the referee.
Fowler also describes the goal as keeping humans "on the loop" rather than "in the loop." In the loop means reviewing every result, which does not scale past a few agents. On the loop means you maintain the harness and let it handle the volume. This is the same shift described in the previous section.
Two other practices are now common. Run agent-written code in disposable sandboxes rather than on a real machine, and treat everything you put in the model's context as untrusted input. It is also useful to measure how good your context was; precision and recall, the same measures used to evaluate search systems, work well for this.
Where to start
The field is early, so there is no penalty for starting now. The tooling is immature and the patterns are still being worked out. But the central idea is stable and worth keeping in mind before you connect an agent to anything important: capability comes from the model, and trust comes from the structure you build around it.
Start small. Supervise closely. Add a rule each time the agent does something you did not want. That is how a harness gets built.
If you want more detail on the specific discipline a mature harness enforces, I have written about that separately. This is the starting point.
About Heavy Chain Engineering
Jason Vertrees is the founder of Heavy Chain Engineering (heavychain.org), which helps lower middle-market vertical SaaS companies and PE firms turn scattered AI usage into measurable delivery leverage — 85% faster feature velocity, six-to-eight-week projects shipped in days. If you want help building an AI-native engineering organization, book an AI Delivery Assessment (app.onecal.io/b/jason-vertrees/30-mins) or email jason.vertrees@gmail.com.