Author
TL;DR An agent harness is the runtime layer around a large language model that lets it operate as an agent: tool dispatch, memory and state, sandboxed execution, context management, guardrails. The word was pulled from software testing, not minted for AI, and the commercial question a harness raises is one software has answered before: a vendor selling in its own units while buying in a supplier’s.
What an Agent Harness Is
An agent harness is the software infrastructure that surrounds a large language model and lets it operate as an agent. The harness dispatches tool calls, holds memory and state across steps, executes actions inside a sandbox, manages what enters the model’s context window, and enforces permissions and guardrails. The model produces text; the harness turns that text into observed, bounded action and feeds the results back in. The compact form: an agent is a model plus a harness. The same layer is also called agent scaffolding.
One boundary up front: this is the agent a vendor ships, not the agent a buyer sends to purchase software, a separate subject.
What does an agent harness do?
A language model by itself is stateless: prompt in, text out. The harness closes the loop: it turns intentions into tool calls, holds state across steps, sandboxes what runs, manages what the model sees, and enforces the rules the operator set. Take it away and the agent stops being an agent.
Agent harness vs. agent scaffolding: is there a difference?
No stable one. Scaffolding was the earlier, looser usage; harness is the word the field is converging on. Compare component lists, not labels.
What is inside a harness?
Five components recur:
- Tool dispatch. Turns the model’s intent into function calls and commands, then routes results back.
- Memory and state. What the agent knows across steps and sessions.
- Sandboxed execution. A contained environment where actions cannot reach anything they should not.
- Context management. What the model sees at each step: instructions, history, tool output.
- Permissions and guardrails. What runs unattended, what requires approval, what is refused.
Where the Term Came From, and Why That Matters
Harness is a borrowed word twice over. Harness comes from tack. Software took it decades ago as the test harness, standard vocabulary long before language models. AI inherited it through reinforcement learning, where the environment closes the loop around an agent that turns observations into actions. The vocabulary attached to language-model systems only recently, in early 2026.
Is “harness” a new term?
No. The test harness has been standard software vocabulary for decades; only the application to language-model agents is new.
What is a test harness, and how is it related?
It is the environment that exercises code under controlled conditions: stubs stand in for missing pieces, drivers invoke the code, the harness records what happened. An agent harness does the structurally similar job for a model. The inheritance is direct.
Who coined “agent harness”?
The coinage is contested. Mitchell Hashimoto and Vivek Trivedy are both credited, and Trivedy’s “Anatomy of an Agent Harness” is the cleanest derivation of the agent = model + harness formula.
A Framework, a Runtime, or a Product?
One complication first: the term has more than one referent, and the literature that popularized it says so. “Agent harness” is used for a whole shipped product, such as a coding agent. It is used for an evaluation scaffold that runs a model against a benchmark. And in the outer-harness sense, it covers the instruction files, MCP servers, and skills a user assembles around an agent they already own. That last one has no vendor, no grant, and no metric, so it raises no licensing question.
The genus the field actually uses is runtime layer. A framework supplies building blocks; a harness is a full runtime with opinionated defaults about tools, memory, sandboxing, and control, often built on a framework underneath. An agent harness is a runtime layer around a model, and where a vendor ships one as a product, it is a product with a boundary and a grant like any other.
Is a harness a framework, a runtime, or a product?
A runtime layer first, a product when a vendor ships it with a boundary and a grant, and a user-side assembly when the operator builds the outer harness themselves.
Does “harness” mean one thing?
No, and the three senses split the commercial question. The shipped product carries a grant and needs a metric. The evaluation scaffold is internal machinery. The user-assembled outer harness belongs to the user. Only the first is a pricing question.
Are You Pricing the Harness or the Product It Ships Inside?
When ‘agent harness’ has three distinct referents, your licensing, packaging, and pricing decisions shift depending on which one you’re actually selling. Find out where your architecture stands.
What You Actually Charge For When You Build One
The question the engineering explainers never reach, and every company shipping a harness meets within its first quarter: what do we charge for?
The metric has to describe the capability. Choosing it is the value metric decision, the ordinary licensing decision, taken in the order the architecture composes: licensing first, then packaging, then pricing. Value metric, licensing metric, metric, and meter all name this one decision.
Why token-based pricing breaks at the harness layer
Generative AI inference carries real, roughly usage-linear marginal cost, so the temptation across AI software pricing is to meter the thing you can already count: the token. But tokens measure the model’s work, and the harness is your work. A price denominated in tokens bills the customer for your engineering choices, how many calls, how much context, how many retries, rather than for what they received. Cost-plus pass-through prices nothing you built.
What is the value metric for an agent product?
There is no universal answer. The pattern we see most: the defensible unit is one the customer recognizes as the work delivered, at a grain they can predict and audit. Choosing it means running the value metric decision on your own capability instead of inheriting the supplier’s meter, and it is taken in order: licensing, then packaging, then price.
Does a thicker harness justify a higher price?
Not by itself. Engineering effort is not a value metric, and buyers do not pay for your bill of materials. A thicker harness justifies a higher price only through what it changes at the boundary: what the agent can now do, unattended, that it could not before.
The Harness Is an OEM Play, and It Inherits OEM Problems
A harness built on a frontier vendor’s model is buying a component and reselling what it makes of it. That is an OEM relationship, and it raises the question OEM licensing always raises: whose units is the grant denominated in? The harness vendor’s costs are denominated in the model provider’s tokens; its product sells in units of its own; and the harness obscures the token consumption behind an answer, which is precisely what an OEM does to its supplier’s meter. The customer sees the output, never the input.
Two twists separate the harness from the classic embedded-component case. The supplier is often a direct competitor selling its own agent to the same buyer. And the gross margin on a thin wrapper runs slim enough that the metric choice decides whether the product makes money.
That leaves the same two options an OEM has always had, and no third one:
- Pass the consumption through. Simple, legible, and it prices the supplier’s meter rather than anything the harness vendor built. It also hands the customer’s bill to a rate card the vendor does not control.
- Recast on a different basis. Charge on something the harness produces, not on inherited credits, the work delivered rather than the tokens spent. It requires actually choosing a metric, the licensing decision, and absorbing the variance between your unit and your supplier’s.
Neither is free, and the choice is not a preference: it is the first structural decision an agent vendor makes, deliberately or not.
Should a harness pass through token costs or price separately?
Those two are the whole menu. Pass-through pins your invoice to a supplier’s rate card; recasting earns the right to price your capability and obliges you to manage the variance. Which fits is per-vendor judgment, not a rule.
Whose units is your pricing denominated in?
Read your own grant. If the unit in your contract is the unit on your supplier’s invoice, you price in someone else’s currency, and every change to their rate card passes straight through to your customers.
The Test
For a harness specifically, the check is two questions. Which sense of the word applies to what you sell: a shipped product with a grant, an evaluation scaffold, or a user-assembled outer layer? Only the first carries a pricing decision. And whose unit denominates your price? The runtime layer is genuinely new engineering; the unit question underneath it is not.
So ask it of your own product: if your inference spend doubled next quarter, which part of your pricing architecture responds, and is that the part you built?
Naming the unit is the easy half. Deciding whether it survives your next hundred renewals takes diagnosis. If you are building on someone else’s model and selling in units of your own, describe the situation and talk to a pricing expert: bring the grant, not the rate card.
