A model is a brain in a jar. An agent is that brain given goals and tools. An agent harness is the structure those tools live in: which systems the agent can read, which it can write to, what it remembers between tasks, what happens when it errors, how its output is evaluated, and where the human checkpoints sit.
The distinction matters because model capability is now rented and commoditized. Two competitors calling the same frontier model get identical intelligence. The harness is where the differentiation and the risk both live: it encodes your permissions, your process knowledge, and your quality bar. Nobody rents you that.
Tool layer. The concrete actions the agent can take: query this database, draft in this CRM, open a pull request. Each tool is a deliberate grant, not a default.
Permission boundary. Read access is cheap to grant; write access is a policy decision. Good harnesses separate the two ruthlessly and log every write.
Context and memory. What the agent knows about your company: retrieval over your documents, structured facts, prior decisions. This is where fragmented data becomes a visible constraint.
Guardrails. Hard limits that do not depend on the model behaving: spend caps, rate limits, blocked actions, sensitive-data filters.
Evaluation hooks. Sampled review, regression tests on known cases, tripwire metrics. Without these you have no answer to "is it actually good?"
Recovery. What happens on failure: retries, escalation to a human, rollback. Agents fail; harnesses decide whether failures are incidents or noise.
For any agent in your company, demand one-page answers to six questions: What can it read? What can it write? What does it remember? What are its hard limits? How is its output evaluated? What happens when it fails? If any answer is "we are not sure," that is the work.
Because every question that keeps executives up at night about AI is answered in the harness, not the model. How do we roll out coding agents without risking company data? Harness: permission boundary. How do we control spend? Harness: caps and metering. How do we know the work is good? Harness: evaluation hooks. How do we avoid vendor lock-in? Harness: the model becomes a swappable component behind an interface.
When a vendor demos an impressive agent, the informed question is not "which model is this?" It is "show me the harness": what it can touch, what it cannot, and how you catch it being wrong.
Buy harnesses for commodity workflows (support triage, meeting notes) where vendors amortize the engineering across thousands of customers. Build thin harnesses around your differentiating workflows, the ones encoding how your business actually works. Rent the intelligence underneath either way.
The anti-pattern is the opposite: building bespoke chat interfaces (undifferentiated) while letting vendors own the harness around your core process knowledge (differentiating). That is how you end up locked in with nothing proprietary to show for it.
The agent is the model plus goals and tools. The harness is the surrounding infrastructure: permissions, memory, guardrails, evaluation, and recovery. The agent does the work; the harness makes the work safe and checkable.
Yes, in proportion. A spend cap, a read-only default, a log of writes, and a weekly sample review is a harness. It fits on one page and prevents the failure modes that make companies abandon AI.
The opposite. A well-built harness treats the model as a swappable component behind an interface, which is precisely what keeps you portable across vendors as the frontier moves.
Bring one AI question from this article. We will tell you what we would do, whether or not you hire us.
Book a 15-Min Chat →