AI Agent Harness vs Wrapper: Why the Model Is Not the Product
Every AI product calls the same handful of models. What separates one that finishes work from one that writes about work is the harness around the model.
Published 2026-08-02
Everyone rents the same engine
There are maybe five frontier models worth building a product on, and every AI vendor you are evaluating calls one of them over an API. The one with the impressive demo is not using a secret model. It is renting the same one as the one with the disappointing demo.
So when two AI products behave completely differently on the same task, the model explains almost none of the gap. What explains it is the software around the model: how many times it is allowed to act, what it is allowed to touch, what it remembers, and what happens when step three fails.
That software has a name. The harness. It is the actual product — the model is a component inside it, the way a database is a component inside your CRM.
What a wrapper is, precisely
Not as an insult. As a description:
- Take the user's message.
- Prepend a system prompt.
- Call a model once.
- Post the answer somewhere fixed — a chat bubble, an email draft, a Slack thread.
One call in, one answer out. Nothing persists between runs. It cannot open anything it was not handed, cannot execute anything, and cannot check whether what it just produced is true.
For a large class of jobs that is the correct engineering. Summarise this. Translate that. Answer a support question from a knowledge base. Draft a reply. If the job is genuinely one step and the input genuinely fits in the message, a harness is overkill and the wrapper wins on both cost and latency.
The problem is not that wrappers exist. It is that hardly any business process is one step, and wrappers get sold as though every process were. That mismatch is why adding AI tools made your team busier.
The arithmetic nobody puts on the pricing page
Take a task with several steps, and assume the model gets each individual step right 90% of the time — a generous number for anything involving your data.
One shot, the steps multiply:
Steps in the task — Chance the whole thing is right
3 — 73%
5 — 59%
10 — 35%
20 — 12%
That is not a criticism of any model. It is multiplication. And it is why AI demos look like magic while AI in production feels unreliable: a demo is one step, and your Tuesday is not.
The failures are also quiet. A wrapper that got step four wrong does not stop. It writes the remaining steps in the same confident prose, and you find out on Friday.
The only way out is to stop multiplying — to check each step against reality before taking the next one. A single API call, by construction, cannot do that.
The loop
A harness runs the model in a loop: propose an action, actually execute it, read what came back, decide the next one.
It sounds mundane. It is the entire difference, because it swaps prediction for observation. Instead of predicting what the export probably contains, the employee opens it and reads it. Instead of assuming the update went through, it checks. When a column in your CSV gets renamed, a wrapper writes a beautiful summary of the wrong numbers; an employee in a loop notices, adapts, finishes, and tells you what it changed.
Errors stop compounding and start getting caught. That is the whole game.
What the harness adds on top
The loop is the foundation. Everything commercially interesting is built on it.
Tools — deterministic work done by deterministic code. The employee does not recall the file, it opens it. Does not estimate the total, it computes it. Does not assume the invoice was paid, it queries. Every step handed to real software is a step that cannot be hallucinated, and the model's intelligence gets spent on judgment instead of recall.
Context management. A large context window is a resource, not a solution — what matters is what goes into it. The harness decides: pull this file now, search rather than load the whole drive, compress the early part of a long job so the part that matters stays sharp. Two products on the same model, one loading the right five thousand words and the other loading a hundred thousand wrong ones, do not perform the same.
Memory that survives the session. The model remembers nothing between calls. Persistence is a harness feature, and it is written as files: who the employee is, who you are, how your company does this specific thing. SOUL.md, USER.md and AGENTS.md is our version of it.
Delegation. A large job gets split across sub-agents that each work in their own context and hand back a conclusion. That is not only about speed. A research step that would otherwise flood the main context with two hundred pages returns half a page instead, and the employee finishes the job still thinking clearly.
Verification. The harness can give the model an oracle — a test that passes or fails, a schema, a total that has to reconcile. An employee that can check its own output is allowed to be wrong privately and fix it before you ever see it. That is what reliability looks like in practice, because nobody's first draft is right.
Permissions and an audit trail. Anything that can act can act wrongly, so a harness ships the brakes with the engine: what needs approval, what is forbidden, a hard stop, a log of every action. The controls are what make the autonomy possible — nobody leaves an unattended system running on production data without them. Here is how ours works.
Six questions that tell you what you are buying
Every vendor deck says autonomous AI agent. These questions do not care what the deck says:
- Can it open a document I did not paste into the chat?
- Can it run something — a script, a query, a calculation — and use the result?
- Show me what happens at step three when the export comes back empty.
- Does it know what it did last Tuesday, and where is that written down?
- Can I add a procedure you have never seen, without waiting for your next release?
- Where is the log of what it actually did, action by action?
A wrapper answers 1 and 2 with no, and 3 with a paragraph about how capable the underlying model is. That is the tell. When a product cannot show you a failure, it is usually because failure is not a state it has — it returns text and stops.
The honest limits
A harness is not free, and pretending otherwise is how people end up disappointed twice.
It costs more per task, because one job is many model calls instead of one. It is slower, because a loop that checks its work takes longer than one that does not. It needs guardrails, and guardrails are work. And it needs the procedure written down: a harness with nothing specific in it is just an expensive wrapper, since a loop only helps when there is a real goal to iterate towards.
That is why setup is a week or two rather than an afternoon — and why a fixed catalogue of nine agents is the right purchase for a genuinely standard process. If the job really is one step, buy the one-step product.
What we run
OpenLabor employees run on an agentic harness. Each one gets a workspace it reads and writes, a shell it can execute, connectors to your tools, skills you define for the procedures that exist nowhere else, org files every employee reads before acting, and a per-employee log of every action taken.
We have changed the model underneath more than once. The employees kept doing their jobs, because the model was never the product. It is the same reason build your own custom GPT stalls at the demo: the prompt was never the hard part either.
The question to ask a vendor
Not which model do you use.
How many times is your model allowed to be wrong before I see the answer?
A wrapper's answer is zero. One shot, and whatever comes out is what you get. A harness's answer is as many times as it takes, privately, until the work is actually done.
Get access, or book a call and describe the process that never fits in one step.
All OpenLabor blog posts