Ask three engineers what an AI "harness" is and you will get three confident, incompatible answers. The vendor engineer means the orchestration loop and sandbox their product ships with. The framework author means every line of code that is not the model. The developer down the hall means the CLAUDE.md and the custom linters in their repository. All three are right, which is exactly the problem — the term is going through what Martin Fowler long ago called semantic diffusion.
The cleanest anchor comes from LangChain's Vivek Trivedy: Agent = Model + Harness. "If you're not the model, you're the harness" — every piece of code, configuration, and execution logic that isn't the model itself. Birgitta Böckeler adopted that equation and immediately flagged it as "a very wide definition, and therefore worth narrowing down for common categories of agents." Addy Osmani arrived at the same place independently: a coding agent is the model plus everything you build around it.
We agree with the equation, but the narrowing is where the useful insight lives. Most published material obsesses over the inner layer — the layer you mostly buy; the outer layer is the one you build, and it is where your leverage is. In this post we split the harness into those two nested systems with two different owners — the agent harness and the work harness — walk through what lives in each, and then use that vocabulary to revisit the Delivery cluster of our Harness Model (in short words the execution — how work gets done). The punchline: the jump from Stage 3 to Stage 4+ is not a smarter agent. It is a change in which harness you, the human, are talking to.
Two Harnesses, Nested
Peel the buzzword apart and two layers fall out — with two different builders.
The agent harness is the control layer the vendor ships around the model. It contains:
- System prompts — the behavioral baseline you never see
- Orchestration — subagent spawning, handoffs, model routing
- Building-block interfaces — tools, skills, hooks, MCP support, and their descriptions
- Bundled infrastructure — filesystem access, sandboxes, memory, browser
- The user interface — terminal, IDE plugin, web app
This component list converges across sources that have no reason to agree: LangChain's anatomy, Osmani's restatement (which adds observability), and the architecture taxonomy in a 138-talk practitioner study all describe essentially the same machinery. Anthropic says it plainly: "The Claude Agent SDK is a powerful, general-purpose agent harness adept at coding..."
The work harness is everything your team builds on top of that, for your codebase and your delivery process: AGENTS.md and CLAUDE.md files, skills, MCP servers and CLIs, hooks, the tests and linters wired into the agent loop, and the workflow definitions that string them together. The vendor cannot ship this layer — it does not know your module boundaries, your compliance constraints, or your definition of done. Stripe's minions are the textbook example: "our custom minion harness tightly integrates with that tooling" — the developer-productivity stack Stripe built for its humans — because "if it's good for humans, it's good for LLMs, too."
Terminology, openly. "Work harness" is our coinage — no published source uses it. Böckeler calls this outer layer the user harness (also "outer harness"), and her name for the inner layer is the builder harness; the Zenn writeup that names the split most cleanly calls the two layers Agent Harness and User Harness. We prefer "work harness" because it names the work, not the user — the layer exists to make a specific body of work deliverable, regardless of who triggers it.
One boundary case before the picture: teams that build their own orchestration — with LangGraph or similar — own both layers, and the test is ownership, not vendor. Whatever your team builds and iterates on is your work harness; what you consume as shipped is the agent harness.
The layers nest: the model sits inside the agent harness, and both sit inside your work harness.
Most of what is published today — benchmarks, orchestration tricks, context management — covers the inner layer. Useful, but as we said up front: that is the part you purchase. The work harness is the part you engineer, and the rest of this post is about how.
Inside the Work Harness: Guides and Sensors
Böckeler's decomposition of the outer harness is the canonical one, and we have not found a better axis. Everything in the work harness is either a guide or a sensor:
- Guides (feedforward controls) steer the agent before it acts. They raise the probability that the first attempt is right.
- Sensors (feedback controls) observe after the agent acts and feed the result back, so the agent can self-correct before a human ever looks.
Each comes in two execution flavors: computational — deterministic, fast, CPU-run — and inferential — LLM-run, slower, more expensive, non-deterministic. That gives a practical 2×2:
| Computational (deterministic, CPU) | Inferential (LLM-run) | |
|---|---|---|
| Guides — steer before the act | Bootstrap scripts, codemods, language servers | AGENTS.md conventions, skills, reference docs |
| Sensors — observe after the act | Linters, type checks, tests, module-boundary checks | Review agents, LLM-as-judge, semantic duplication checks |
You need both directions. As Böckeler puts it: "you get either an agent that keeps repeating the same mistakes (feedback-only) or an agent that encodes rules but never finds out whether they worked (feed-forward-only)." A well-built work harness serves two goals — it increases the probability the agent gets it right the first time, and it self-corrects as many issues as possible before they reach human eyes.
The two controls wrap the agent from both sides — guides steering the input, sensors observing the output — with the human tuning both:
Where do workflow definitions — slash commands, pipelines, triggers — fit? They are a component of the work harness that sequences guides and sensors into a repeatable process, not a third axis. That distinction matters later, because workflow definitions are exactly what migrates as teams mature.
We have already built one of these in public: our harness engineering for E2E tests post is a worked example of a guides-and-sensors stack — scenario corpora as guides, pytest-in-Docker plus reviewer agents as computational and inferential sensors.
The Steering Loop
If guides and sensors are the parts, the steering loop is the operating principle. Böckeler:
"The human's job in this is to steer the agent by iterating on the harness. Whenever an issue happens multiple times, the feedforward and feedback controls should be improved to make the issue less probable to occur in the future, or even prevent it."
This is the same practice Mitchell Hashimoto described as engineering the harness so the agent "never makes that mistake again" — the founding move of the Harness Model. Your job is not to babysit the agent through each task. Your job is to notice the second occurrence of a mistake and turn it into a guide or a sensor. That is the loop the diagram above closes: recurring issues flow back to the human, who hardens the guides and sensors.
Two warnings come with the loop. First, it never finishes — Böckeler observes that building the outer harness "is emerging as an ongoing engineering practice, not a one-time configuration." Second, stopping early is the most common failure. The Zenn article makes the point sharply: if your work harness is CLAUDE.md plus some skills plus a few hooks, you are missing the computational sensors — linting, type checks, verification loops in the agent's path — and you are missing measurement. Can you demonstrate, with data, that your harness actually works?
Guides without sensors is vibes with extra files.
Driving the Agent vs Running the Work Engine
Now the payoff, and a part we want to flag honestly: what follows is our own synthesis. No published source maps the harness layers onto a staged maturity ladder — what the literature supports is the steering loop underneath it. We think the mapping earns its keep.
In the Harness Model, the early stages share one trait across the Delivery cluster: whenever a human works with AI at all, they interact with the agent harness. You open the terminal or the chat window, you prompt, you watch, you correct. Your prompt is the workflow, and it evaporates when the session ends.
At Stage 4+, the human's hands move one layer out. You interact with the work harness: you trigger a versioned workflow, the work harness drives the agent through guides and sensors, and what comes back has already survived the feedback loop. The whole stack — work harness wrapped around the agent — becomes what we call a work engine.
"Work engine" is also our coinage — but not from thin air. LangChain's own framing is that harness engineering exists to turn models into "work engines." We are extending their phrase one layer up: the model becomes a work engine only when your harness, not just the vendor's, wraps it.
The shift in one sentence: at Stage 1-3 your prompt is the workflow; at Stage 4+ the workflow is versioned in the repo and you trigger it. That is not a model upgrade. It is a change of interface — and of what you spend your day improving.
Walking the Delivery Cluster
The two-harness vocabulary makes the three Delivery dimensions of the Harness Model concrete.
If you have not read that post: the model spans five stages, from No AI Process through Chatbot-Assisted and Human-in-the-Loop to Systematic Harness and Agentic Flywheel. Across the Delivery cluster, the early stages mean that whenever a human works with AI at all, their hands are on the agent harness — prompt, watch, correct — while at Stage 4+ they move to the work harness and trigger versioned workflows.
Human-Agent Interaction
Kief Morris's loop progression — outside the loop, in the loop, on the loop, flywheel — restates cleanly: "on the loop" literally means your hands move from the agent harness to the work harness. And the reason you cannot skip ahead is documented. Böckeler's catalogue of coding-agent steering found that even in successful sessions, "intervention, correction and steering happened all the time" — what she calls "supervised agent" mode, exactly the Stage 1-3 territory of our model. Until your guides and sensors absorb that steering, a human has to supply it live, on the agent harness.
Workflow & Process
Maturing here means workflow definitions migrate from ad-hoc prompts into the work harness. Stripe is the Stage 4+ exhibit: "A typical minion run starts in a Slack message and ends in a pull request which passes CI and is ready for human review, with no interaction in between" — over a thousand merged PRs per week, with deterministic lint and test steps interleaved into the agent loop so required checks always run. OpenAI's harness engineering post compresses the same operating model into four words — "Humans steer. Agents execute." — and notes they have "pushed almost all review effort towards being handled agent-to-agent." Review itself became a sensor inside the work harness.
Reliability & Operations
Unattended operation is only trustworthy if the work harness carries state and verification, because the agent harness alone cannot. Anthropic's long-running agent pattern is the machinery: a specialized initializer agent sets up an init.sh, a claude-progress.txt log, and an initial git commit; every later session reads the progress file and git history, verifies the app still runs, and commits incremental work. Their motivating finding — "compaction isn't sufficient" — is the reliability argument in miniature: durable state lives in the filesystem and git, which are work-harness artifacts, not in the agent harness's context tricks. This is the same investment as the runbook and alert-handling axes in the matrix: agents earn operational trust through structure, not optimism.
It's Engineering, Not Model Magic
If this sounds like a lot of unglamorous systems work — it is, and the skeptical evidence says that is precisely the point. A study of 138 practitioner talks on deployed agent systems concludes: "allocate most of your resources to integrating tools and APIs, designing memory and workflow layers, implementing orchestration, and setting up observability and debugging. These engineering tasks dominate development time more than model behavior." (Fair caveat: that is the authors' qualitative takeaway from self-selected talks, not a measured-hours figure.)
The 2025 DORA report lands the organizational version of the same finding. It warns that existing delivery bottlenecks will "neutralize any gains from AI", because "Every line of AI-generated code still needs to go through your review process, your test suite, and your deployment pipeline." The teams positioned to capture the value are the ones that treat internal platforms as real products with dedicated ownership. Pipelines, tests, fast feedback, governance — DORA does not say "work harness," but it is describing one.
Our conclusion from both: the agent harness is necessary, and the vendors are racing each other to build it for you. The work harness is what gates the value, and nobody is going to build it for you.
Start Building Your Work Harness
The vocabulary in one breath: three layers (model, agent harness, work harness), two owners (the vendor builds the inner layers, your team builds the outer), one loop (steer the agent by iterating on guides and sensors). And one marker of maturity: which harness your humans touch all day.
Two things to do this week:
- Audit the interface. Watch where your team's hands actually are. Mostly prompting, watching, and correcting in a terminal? You are on the agent harness — pre-Stage-4 territory, and that is fine, as long as it is a deliberate stop and not a permanent address.
- Convert one recurring mistake. Pick the agent error your team has corrected at least twice this month and turn it into a guide (a rule, a skill) or a sensor (a linter, a check in the loop). That single move is the steering loop in practice.
And if you are earlier in the journey — no agent in your daily work yet, nothing to audit — start with our getting-started guide. The two moves above will still be here when you are ready.
We are collecting patterns across teams for the Q2 2026 update of the Harness Model — if your team has moved a workflow from prompts into a work harness (or tried and bounced off), we would like to compare notes. Email us at contact@handsonarchitects.com or DM either of us on LinkedIn: Maciej · Tomasz.
TL;DR
"Harness" is one word for two different systems. The agent harness is the control layer that ships with the product — orchestration, tools, sandboxes — and the vendors are racing each other to build it; whatever edge it gives you, your competitors rent at the same price. The work harness is the layer your team builds on top: the conventions agents read before they act, the linters, tests, and review agents that check what comes out, and the versioned workflows that string them together. Nobody will build that layer for you — it encodes your module boundaries, your compliance constraints, your definition of done — and it is the part you own and the part that compounds.
The budget translation: most of the published excitement is about the layer you buy, but the returns are gated by the layer you build. The empirical evidence points the same way — across deployed agent systems, integration, workflow, and observability engineering dominates development time more than model behavior, and DORA warns that existing delivery bottlenecks will "neutralize any gains from AI": every AI-generated line still passes through your review process, your test suite, and your deployment pipeline. Funding the work harness largely means funding those.
A walk-the-floor diagnostic for your next review: watch where your engineers' hands are. If the day is spent prompting, watching, and correcting agents in a terminal, the prompt is the workflow and it evaporates with the session — fine as a stage, expensive as a permanent address. The maturity marker is engineers triggering versioned workflows whose output has already survived automated checks before a human looks at it. That jump is not a model upgrade you can purchase. It is an interface change you have to engineer.
Two questions to ask your leads this month: which harness do your hands touch all day? and which recurring agent mistake did we convert into a guide or a sensor? Then place your team on the Delivery rows of our maturity matrix.