What Is a Harness Engineer? Agent = Model + Harness

A harness engineer builds everything in an AI agent except the model. The model produces text. The harness turns that text into reliable work by deciding what the model sees on each step, what it's allowed to do, how its output is checked, and what gets remembered afterwards. By 2026 the field had settled on a shorthand: agent = model + harness.

Below: what the term means, what a harness contains, what the job involves day to day, and what it looks like in systems I have shipped.

What is an agent harness?

An agent harness is the software that surrounds a large language model so it can act as an agent: call tools, take multi-step actions, keep state across sessions and stay within limits. A model on its own is stateless and only emits tokens. The loop, the tools, the memory, the guardrails and the logs are all harness.

Products you may already use are harnesses around a model. Claude Code, OpenAI's Codex and Google's Antigravity each put a model inside a harness, and so does a support agent in a CRM or a project-manager agent in a task tracker.

The vocabulary of harness engineering took hold in early 2026, and who coined it is contested. Some accounts credit a February 2026 post by Mitchell Hashimoto, which described engineering a permanent fix into an agent's environment after each mistake. Others credit LangChain's "Anatomy of an Agent Harness". Writing from OpenAI, Anthropic and Thoughtworks then spread it. The idea is older than the word, though: an agent's reliability comes from the system around the model.

What does a harness contain?

Thoughtworks' Birgitta Böckeler gives the clearest split. A harness is made of guides, which steer the agent before it acts, and sensors, which observe what it did so it can correct itself. I add a third group, limits, because a production agent needs bounds that hold even when the guides and sensors fail.

Guides

The first guide is the tool contract. Each tool has a typed input, a typed output and a description the model can act on; a tool that returns a vague string is a guide that fails silently.

Next come instructions and skills. Instead of one giant prompt, the harness has layered, versioned instructions covering what the system is, how work is done here and what "done" means. Skills package a workflow so different agents can reuse it.

Context assembly decides what the model sees on this step: the relevant records, the last few tool results, the plan. It doesn't hand over the whole transcript. Re-reading an ever-growing conversation is the most common reason agents get worse as a task goes on.

Approval tiers complete the set. The harness knows which actions are reads, which are reversible writes and which are irreversible, and it routes each kind differently.

Sensors

Every model output that feeds code is parsed against a schema and rejected if it doesn't fit. On top of that sit verification passes: a second, cheaper model call that re-solves or checks the first. For generated questions that means solving them again, and for extracted data it means checking against the source.

For coding agents the sensors that matter most are tests, linters and type checkers, and the agent's work isn't accepted until it passes them. Every run also leaves a trace of the steps taken, the tools called, the tokens spent and the outcome, so failures can be replayed and budgets enforced.

Limits

Limits are the blunt instruments. Each agent and each run has a budget with a hard stop. Permission scopes set which tools, records and environments the agent can touch. Writes that matter go through a human checkpoint, as an approval queue rather than a chat prompt. And every agent ships switched off, behind a kill switch, until someone turns it on deliberately.

What does a harness engineer do all day?

The role sits between application engineering and AI engineering. In practice the work breaks into six parts:

1. Designing the loop. Where the model is called, what goes in, what comes out, and where the loop ends. That includes choosing between a single call, a loop inside the request and a background job.
2. Building and maintaining tools. Most agent failures are tool failures: bad descriptions, ambiguous parameters, missing error messages. Of all the work in a harness, tool design pays back the most.
3. Context engineering. Deciding what the model needs to see, and building the retrieval, summarisation and memory that supply it. Persistent memory means a structured store the harness reads from, not a longer transcript.
4. Evaluation. Writing the regression suite: real tasks with known-good outcomes, run against every change to the harness, with cost tracked alongside accuracy.
5. Governance. Permissions, approval tiers, audit logs, data handling (what gets masked before the model sees it), and the switch that turns the agent off.
6. Fixing the environment, not the prompt. When the agent fails, the fix goes into the harness as a validator, a tool, a rule or a test, so the same mistake can't happen again. Prompt edits come last because they're the hardest change to verify.

Harness engineering versus prompt engineering

Prompt engineering changes the words the model reads, and harness engineering changes the system it runs in. That matters because prompts work probabilistically and harnesses don't. A schema validates or it doesn't; a budget stops the run or it doesn't; a tool returns a typed result or an error. Good harness work moves as much behaviour as it can to the deterministic side and leaves the model to do what only the model can do.

Model upgrades make this more true, not less. A better model makes a good harness worth more, because the harness is what gets the model's capability to the user safely. A harness built around one model's quirks, on the other hand, breaks on the next release.

What it looks like in real systems

These are systems I have built or maintain. The details describe what each harness actually does today.

The first is an AI project manager inside a task platform. The agent is an assignable employee: it reads each project it's assigned to, works out what a project manager would do next, and acts, whether that's chasing status, unblocking work or fixing the board. Its harness gives it per-project memory, a budget with hard stops, an approval queue for high-risk changes and a single admin toggle, and it shipped switched off. In one real end-to-end tick it reasoned about a project, applied a safe fix on its own, proposed a risky action for approval and wrote to memory, for about eleven cents of model usage.

Claude Code skills are harness components too. The seo-ai-search skill packages an SEO and AI-search workflow as instructions, reference documents and a zero-dependency audit script the agent runs. The study-material skills for a tuition company encode page rules, gates and verification, so generated books are checked before they print.

Then there are RAG assistants with sensors and data handling. A portal support assistant retrieves from resolved support tickets, and a website chatbot uses self-hosted embeddings and reranking so no data leaves the stack. Both mask personal data before the model sees it, and generated content passes an evaluation step before it's used.

The last example is a maths question generator running on a local open model. It re-solves every generated question in a second call and corrects the answer when the two disagree. That one sensor catches the model's most common failure with no person in the loop.

How to tell whether you need one

You need harness engineering once an agent touches real data, real money or real customers. The warning signs are familiar: a demo that impressed everyone and then stalled before launch, an agent that behaved differently after a model update, a support bot that answered confidently and wrongly, a monthly cost nobody can predict. Each one is a missing guide, sensor or limit.

If your agent plan is a model and a prompt, the harness is what's missing, and it's the part I build.

Further reading

• Birgitta Böckeler, Harness engineering for coding agent users (martinfowler.com): the guides-and-sensors framing.
• Agent harness on Wikipedia: the definition, the components and the history of the term.
• What Is an Agent Harness? (Firecrawl) and The Agent Harness (MongoDB): practitioner descriptions of the same architecture.
• My earlier article, How AI Agents Actually Work, covers the loop itself in more detail.
• What Is Jev? looks at TypeSafe AI's decision model, a fast sensor you can put inside a harness.