# What Is Harness Engineering? Agent = Model + Harness (2026)

> Harness engineering explained: why Agent = Model + Harness, feedforward guides vs feedback sensors, and a starter harness for AI coding agents.

Source: https://bytevancer.com/blog/what-is-harness-engineering · Published 2026-09-25 · ByteVancer · AI Engineering

**The model is the brain; the harness is everything that makes it reliable. What goes into a harness, why feedforward and feedback both matter, and a starter setup for your team.**

If you use Claude Code, Codex or Antigravity, you already use a harness. The model behind them is only part of what you are working with: around it sit tools, rules, memory, test runners and the loop that ties them together. Harness engineering is the practice of designing that surrounding layer on purpose instead of leaving it to defaults. This article draws on Birgitta Böckeler's piece on harness engineering for coding agent users (martinfowler.com), Vivek Trivedy's anatomy of an agent harness on the LangChain blog, and our own experience of what makes coding agents useful.

## Agent = Model + Harness

The equation is the shortest definition there is. The model is the brain: capable, but non-deterministic, and with no direct contact with the outside world. It cannot open your repository, run your tests or remember what happened yesterday on its own. The harness is everything else in the agent — every piece that lets the brain act, observe and correct itself. LangChain puts it bluntly: "If you're not the model, you're the harness."

Even a plain chat product is a harness. As LangChain notes, chat itself is a model wrapped in a while loop — the simplest harness there is. Everything a coding agent adds on top of that loop is harness, too.

## What's inside a harness

**Components drawn from LangChain's list and our own framing; the middle column is what each one gives the model.**
- **System prompts and rules** — What it gives the model: Clear instructions and coding standards from the first token; Example: AGENTS.md-style files injected into context at start
- **Tools and MCP servers** — What it gives the model: Ways to act, and to reach knowledge past the training cutoff; Example: Bash, code execution, web search, MCP tools such as Context7
- **Skills** — What it gives the model: Task know-how loaded only when it is needed; Example: A skill for code review or for bootstrapping a service
- **Memory systems** — What it gives the model: Durable state across sessions; Example: Memory files, a plan file, git history
- **Sandbox, filesystem, browser** — What it gives the model: A safe place to work and a way to see results; Example: Isolated execution, allow-listed commands, network isolation, screenshots
- **Orchestration and subagents** — What it gives the model: A way to split work and route it; Example: Subagent spawning, handoffs, model routing
- **Hooks and middleware** — What it gives the model: Deterministic steps the model cannot skip; Example: Compaction, continuation, lint checks

## Why a model needs a harness

According to LangChain, a model on its own cannot:

- keep durable state across interactions,
- execute code,
- access real-time knowledge,
- set up environments or install packages.

Each gap is closed by a harness primitive. LangChain calls the filesystem the most foundational one: a workspace, a place to offload context, and a collaboration surface between agents and people. Git adds versioning, rollback and branching on top. Bash and code execution act as the general-purpose tool, driven by a ReAct loop: reason, act with a tool call, observe the result, repeat.

Our view at ByteVancer is that a good harness does two things: it makes the model's output more accurate, and it gives the model a feedback loop to correct itself. Böckeler frames the outer harness the same way, with two goals — raise the probability the agent gets it right the first time, and self-correct as many issues as possible before a human reviews the work. The payoff she names is less review toil and fewer wasted tokens.

## The shift: from a one-way prompt to a two-way loop

**The old way**
Human prompt → AI model → Code generated

1. **Human prompt** — You describe what you want.
2. **AI model** — Generates an answer in one pass.
3. **Code generated** — Every mistake lands on your desk.

**With a harness**
Human prompt → Harness (feedforward) → AI model ⇄ harness tools → Code generated

1. **Human prompt** — You describe what you want.
2. **Harness (feedforward)** — Rules, skills and standards shape the request before the model acts.
3. **AI model ⇄ harness tools** — The model acts; tests, linters, logs and the browser answer back.
4. **Code generated** — Checked by the harness before you see it.

That two-way arrow is the whole story. In the old flow the model hears nothing back, so every error reaches you. In the new one, the model hears from the type checker, the test suite and the linter first — and fixes what they report before you review.

## Feedforward guides and feedback sensors

Böckeler splits harness controls into two kinds. Guides are feedforward controls: they steer the agent before it acts. Sensors are feedback controls: they observe what the agent did and help it self-correct. You need both. With feedback only, the agent keeps repeating the same mistakes; with feedforward only, your rules are encoded but the agent never learns whether they worked.

**Inside a coding agent's harness**
Human prompt → Harness → Coding agent → Reviewed, working code

- **Feedforward (guides)** (Skills, PRDs, Rules, MCP servers, Principles, Coding standards) —Feedforward→ Initial generation
- **Feedback (sensors)** (Review agents, Logs, Browser access, Unit tests, Integration tests, ESLint config) —Feedback→ Self-correction

Read the diagram top to bottom. The prompt enters the harness, not the model. Guides shape the first attempt; sensors check it and send the agent back to fix what failed. The output you see has already been through that loop.

## Computational vs inferential controls

Böckeler adds a second axis. Computational controls are deterministic and fast and run on a CPU: tests, linters, type checkers, structural analysis. Inferential controls use a model: semantic analysis, AI code review, LLM-as-judge. They catch things rules cannot, but they are slower, cost more and are non-deterministic. Her examples:

**Examples from Böckeler's article on martinfowler.com.**
- **Coding conventions** — Direction: Feedforward; Kind: Inferential; Example: AGENTS.md, skills
- **Bootstrap instructions** — Direction: Feedforward; Kind: Both; Example: A skill plus a bootstrap script
- **Code mods** — Direction: Feedforward; Kind: Computational; Example: OpenRewrite recipes
- **Structural tests** — Direction: Feedback; Kind: Computational; Example: A pre-commit or agent hook running ArchUnit on module boundaries
- **Review instructions** — Direction: Feedback; Kind: Inferential; Example: Skills

> **Make your linter speak to the agent** — A custom lint message that includes the fix instructions turns a sensor into a guide at the same time. Böckeler calls it "a positive kind of prompt injection".

## The steering loop

A harness is never finished. Böckeler's advice is to improve the feedforward or feedback controls whenever an issue recurs — and the agents themselves can help, by writing structural tests, drafting rules and scaffolding linters.

**Steering the harness**
Issue recurs → Improve a guide or sensor → Agent retries → Fewer repeats

1. **Issue recurs** — The same mistake shows up in review twice.
2. **Improve a guide or sensor** — Add a rule, a skill, a lint check or a structural test.
3. **Agent retries** — The next run is shaped and checked by the new control.
4. **Fewer repeats** — Human review moves on to problems a control can't catch.

## Keep quality left

Not every check belongs in the inner loop. Böckeler recommends running the fast checks first and the expensive ones later, with continuous and runtime sensors behind them:

**Where each sensor runs**
Before commit → Post-integration → Continuous drift → Runtime

1. **Before commit** — Linters, fast tests, a basic review agent.
2. **Post-integration** — Mutation testing, broader review.
3. **Continuous drift** — Dead code, coverage quality, dependency scanners.
4. **Runtime** — Degrading SLOs, log anomalies.

Böckeler also points to teams already working this way: an OpenAI team that enforces a layered architecture with custom linters and structural tests and runs recurring "garbage collection" against drift, and Stripe's "minions", where pre-push hooks run the relevant linters to shift feedback left.

## What a harness regulates

- **Maintainability** — What Böckeler describes: The easiest to build, because existing tooling already covers much of it
- **Architecture fitness** — What Böckeler describes: Fitness functions, performance tests, logging standards
- **Behaviour** — What Böckeler describes: The hardest: a spec as feedforward; AI-generated tests as feedback aren't good enough yet; the approved-fixtures pattern helps

## Harnessability and ambient affordances

Some codebases are easier to harness than others. A typed language gives you a type-check sensor for free; clear module boundaries let you write architecture rules. Böckeler borrows Ned Letcher's term "ambient affordances" for these properties. The uncomfortable corollary: in legacy code, the harness is most needed exactly where it is hardest to build.

She also suggests harness templates per service topology, and cites Ashby's Law of Requisite Variety — a regulator needs as much variety as the system it regulates. The human role does not disappear: the harness externalises developer experience, and the aim is to direct human input to where it matters most, not to eliminate it. In her framing, a user harness is a specific form of context engineering — the practice that makes guides and sensors available to the model.

## Harnesses for long-running agents

Long tasks add a problem LangChain calls context rot: models degrade as their context window fills. The harness primitives LangChain describes for long-horizon work:

- **Filesystem and git across sessions** — progress survives when the context does not.
- **The Ralph Loop** — a hook intercepts the agent's attempt to exit and re-injects the prompt in a clean context.
- **Planning** — a plan file the agent writes and follows.
- **Self-verification** — hooks run the test suite and loop errors back to the model.
- **Compaction** — summarising older context to free space.
- **Tool-output offloading** — keep the head and tail of a long output in context and write the full output to the filesystem.
- **Skills with progressive disclosure** — load instructions only when the task needs them.

## Evidence that the harness matters

LangChain reports that its coding agent moved from the Top 30 to the Top 5 on Terminal Bench 2.0 by changing only the harness. Same model, different surroundings, a very different result. That is the strongest argument for treating the harness as engineering rather than configuration.

**Same model, new harness — LangChain on Terminal Bench 2.0**
- **Top 30** Before — LangChain's coding agent with its original harness.
- **Top 5** After — The same model; only the harness changed.

*Leaderboard position, where a lower rank is better. Figures as reported by LangChain (Vivek Trivedy, The Anatomy of an Agent Harness).*

## A starter harness for your team

This is our own checklist, built from the controls above. Each item is small; together they cover both directions of the loop.

1. Write your conventions down in an AGENTS.md or CLAUDE.md file: coding standards, architecture rules and the commands to build and test.
2. Package repeatable know-how as skills, so it loads only when a task needs it.
3. Run lint, type checks and fast tests as hooks, so the agent sees failures before you do.
4. Rewrite custom lint messages to say how to fix the problem, not just what is wrong.
5. Add a review agent with written review instructions.
6. Give the agent browser and log access so it can verify its own work.
7. Keep memory and plans in files, and work through a git workflow so every change can be rolled back.
8. Close the steering loop: every repeated mistake becomes a new rule or a new sensor.

## Where harness engineering is going

LangChain expects some harness functions to be absorbed into the models themselves over time, while harness engineering likely remains useful. We agree: models will get better at the inner loop, but your conventions, your architecture and your definition of done are specific to your team, and only a harness can carry them. The same goes when you swap the model itself, say for an open model from the Hugging Face Hub: the harness is the part that carries over. Our guide to [what Hugging Face is used for](https://bytevancer.com/blog/hugging-face-for-ai-engineering) covers the Hub, Spaces and Inference Providers.

One more distinction worth keeping: harness engineering governs one agent; graph engineering wires many. When several agents share a codebase, each with its own mandate, read our follow-up on [graph engineering for multi-agent systems](https://bytevancer.com/blog/what-is-graph-engineering).

## Frequently asked questions

**What is harness engineering?**
Harness engineering is the practice of designing everything around an AI model that turns it into a reliable agent: system prompts and rules, tools and MCP servers, skills, memory, sandboxes, hooks and the feedback loops that let the agent check and fix its own work. The shorthand is Agent = Model + Harness.

**What is the difference between the model and the harness?**
The model is the non-deterministic brain that generates text and has no direct contact with the outside world. The harness is everything else in the agent. LangChain's rule of thumb: if you're not the model, you're the harness.

**What are feedforward and feedback controls in a harness?**
In Birgitta Böckeler's framing, feedforward controls (guides) steer the agent before it acts: rules, skills, coding standards. Feedback controls (sensors) observe what it did and help it self-correct: tests, linters, type checks, review agents. With only one kind, the agent either repeats mistakes or never learns whether the rules worked.

**Do I need harness engineering if I already use Claude Code or Codex?**
Those tools ship with a harness, so you are already using one. Harness engineering is about adapting it to your codebase: writing down your conventions, adding skills, running your linters and tests as hooks, and turning repeated mistakes into new rules or checks.

**How does harness engineering relate to context engineering?**
Böckeler describes a user harness as a specific form of context engineering. Context engineering makes guides and sensors available to the model; harness engineering decides which guides and sensors exist and how their feedback flows back into the agent's loop.

## Keep reading

- [What Is Graph Engineering? Designing Multi-Agent Systems as Graphs (2026)](https://bytevancer.com/blog/what-is-graph-engineering) — Graph engineering explained: designing multi-agent AI systems as explicit graphs of nodes, edges and loops, with governance tips and a LangGraph example.
- [All ByteVancer engineering articles](https://bytevancer.com/blog)

## Want coding agents that follow your standards?

We build cloud applications and set up the harness around AI coding agents — conventions, hooks, tests and review loops tuned to your codebase. See our [AI-assisted cloud application engineering](https://bytevancer.com/services/cloud-applications) or [talk to the team](https://bytevancer.com/contact).

## Sources

- [Birgitta Böckeler (Thoughtworks) — Harness engineering for coding agent users, martinfowler.com (Apr 2, 2026)](https://martinfowler.com/articles/harness-engineering.html)
- [Vivek Trivedy — The Anatomy of an Agent Harness, LangChain blog (Mar 10, 2026)](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness)

---

*This is the Markdown copy of https://bytevancer.com/blog/what-is-harness-engineering — the page itself has the interactive charts and diagrams.*