The model is not the agent: What the “harness” means when you buy an AI agent

The demo is running in the sales meeting: an AI agent answers inquiries, creates tasks and prepares quotes. The slide shows the name of a well-known language model, with a price underneath. You wonder whether that means you have bought the agent. The honest answer is no. You have bought the reasoning capability. What turns it into a replacement for an employee who gets things done in your company sits in the shell around it. In technical circles, that shell has recently been called the “harness”.

This article is an evergreen topic, not breaking news. There is no product you can switch on from today, only a mental model that explains why two agents running on the same model can work in completely different ways. We draw on three published explainers: the post by Vivek Trivedy on the LangChain blog dated March 10, 2026, the article by Matt Abrams at Builder.io dated April 6, 2026, and the explainer by Khalid Abdelaty at DataCamp dated May 15, 2026. We read all three ourselves. Where numbers appear, they are the respective authors’ figures, which we have not independently measured.

What “harness” means: agent = model + shell

The LangChain post of March 10, 2026 condenses the idea into a short formula: “Agent = Model + Harness”. The author, Vivek Trivedy, defines the harness as everything that is not the model itself. In his words: “If you’re not the model, you’re the harness.” A language model on its own takes in text and returns text. It remembers nothing beyond the conversation, it does not open a file and it does not call an interface. Only the software around it turns it into something that acts. The post sums it up in one sentence: the model contains the intelligence, and the harness makes that intelligence usable.

Builder.io describes the same thing from a practical angle. A raw model, it says, is a “stateless text predictor”, in other words a text predictor without a memory. The harness is all the code, configuration and execution logic that surrounds the model. It handles state management, tool execution, memory, orchestration and constraints. The author, Matt Abrams, puts it this way: the model is the constant, the harness is the variable. The point is that when two agents behave differently, the cause often lies not in the model but in what has been built around it.

As a reminder, so the terms stick: the model thinks. The harness decides what the model may see, which tools it may use, what it remembers and when a person is asked.

What a harness is made of

The three sources name similar building blocks, with slightly different emphasis. The LangChain post lists five: system prompts, meaning the standing instructions to the model; tools, skills and MCP connections together with their descriptions; provided infrastructure such as a file system, sandbox and browser; orchestration logic, for example launching sub-agents, handovers and choosing the model for each task; and hooks and middleware, meaning fixed rules that run independently of the model. The post calls the file system “arguably the most foundational harness primitive”, perhaps the most fundamental building block. Our reading: an agent that can store intermediate results can carry work forward across several steps.

Builder.io adds memory and search, for example rule files such as AGENTS.md, as well as the file system and Git for durable storage. Under hooks, the article explicitly mentions “confirmation gates” (“Bestätigungsschranken”) and deterministic enforcement. For companies, this is the most important point: the harness is where it is decided whether someone is asked before a critical action. DataCamp names its own building blocks: memory and state (short-term and long-term), guardrails and permissions, and observability and tracing, meaning the traceability of what the agent has done.

For your decision, this translates into a simple list. Behind every offer labeled “AI agent” there are at least these questions:

• Which instructions and rules apply permanently, and who can change them?
• Which systems may the agent access, and with what permissions?
• What does the agent remember, where is it stored, and for how long?
• Who starts, who stops and who monitors the individual steps?
• At which points does the system ask a person before something happens that cannot be undone?
• Can you trace afterwards what the agent has done?

What the sources show about impact, and what they do not

One argument for the importance of the harness is measured results, and caution is called for here. The LangChain author writes that he moved his coding agent “from Top 30 to Top 5” on the Terminal Bench 2.0 benchmark through changes to the harness alone. Builder.io takes up the same idea and describes how the same model with a different harness can jump from rank 30 or lower into the top five. DataCamp reports that LangChain measured a jump of 10 to 20 points on a subset of the tau2-bench benchmark after adding model-specific harness profiles.

These are observations from software development, measured on coding benchmarks and reported by vendors and specialist authors. They do not say that your invoicing process would improve by the same amounts with a different harness. They show something fundamental: the quality of an agent is not purely a question of the model. We do not claim more than that.

An offer that names a model describes the brain. The question that decides the benefit concerns the hands, the memory and the rules of the game.

No industry standard: why the terms wobble

DataCamp points out explicitly that the formula is a mental model and not an industry standard. Vendors use “harness”, “framework” and “scaffold” partly as synonyms. The article nevertheless draws some lines: a framework supplies building blocks such as model calls, tool definitions and a loop structure. A runtime provides durable execution, stored state, retries and approval by humans. The harness sits above that, with more decisions already made about tools, planning, file system and context management. According to DataCamp, Harrison Chase compares this to Next.js and Express on one side and Node.js on the other.

According to DataCamp, “scaffold” is considered an older name for the same concept. The term “scaffolding” suggests a temporary support structure that disappears once the models are good enough. The harness, by contrast, is understood as a permanent part of the system. As a point in time, the article cites February 2026, when Mitchell Hashimoto is said to have spoken of “harness engineering” in a blog post. For you, this means: if one vendor talks about a “framework” in the conversation and another about a “harness”, follow-up questions about the content matter more than the choice of word. Ask to be shown what each one includes.

Availability: a concept, not a product

There is nothing here for you to unlock or order. The harness is not a product with an availability status but a way of building that is present in the background of every agent tool. As examples of harnesses, the sources name, among others, Claude Code, Codex, LangChain Deep Agents, the Anthropic Agent SDK and the OpenAI Agents SDK. We do not evaluate these products here and say nothing about their availability in the DACH region, because that was not the subject of our review.

What matters is the converse for your practice. If you buy a ready-made agent offer, you buy the vendor’s harness along with it, whether you want to or not. If you build it yourself, you build one, even if you do not call it that. A model without a well-thought-out harness, on the other hand, remains, in the words of Builder.io, a text predictor without a memory: it answers, but it does not get anything done reliably.

A thought experiment: two offers, one model

Imagine two vendors who name the same model in their presentation. The example is entirely invented and serves only to make the questions tangible. Vendor A shows an interface in which the agent answers inquiries. Asked what it is allowed to do with the inbox, the answer is: everything the account is authorized for. Vendor B answers the same question with a list: reading yes, drafts yes, sending only after confirmation, deleting never.

From the sources’ point of view, the two offers differ not in the model but in the building blocks of permissions, hooks and confirmation gates. Which variant is better for you depends on the process. For a workflow in which a mistake costs little, a generous permission may be acceptable. For anything that goes outside the company, there is a lot to be said for Vendor B’s list. What matters is that you can see this difference at all. Anyone who looks only at the model name does not see it.

The same applies to memory. Asked what the agent remembers, one vendor may answer “everything, so that it keeps getting better”. Another discloses what is stored, where it is kept and who can delete it. Whether this is relevant for your data, please clarify case by case, if necessary with your data protection officer. The point here is only to note that this building block, too, is part of the shell and should be examined in the offer.

What this means for a company with 10 to 250 employees

First: choosing a vendor is a question about the shell. If you ask only for the model name, you are comparing the wrong thing. Ask about tool integration, memory, permissions, logging and approval logic. If a vendor cannot or will not answer these questions, that is an answer in itself.

Second: the same model does not mean the same behavior. The sources see the model as the constant and the harness as the adjusting screw that changes the result. For you, this is a reason never to base comparison offers on the model name alone. It is also a pointer for ongoing operations: if something changes in the model or in the shell, the behavior can change. So ask who tests such changes in advance and how you will find out about them.

Third: a model with a few documents is not yet an agent. This is our assessment, derived from the rule of thumb. Anyone who gives a model some documents and hopes it will handle processes on its own has the ingredient without the recipe. Tools, memory, rules and approvals are missing, which are precisely the building blocks of the shell.

Which agent: the Memory-Layer as part of the shell

On amazing-agents.com, we assign this topic to the Memory-Layer, the eighth of the eight agents. The website describes it with two statements: shared context across all agents, and nothing has to be explained twice. That is the memory side of the harness. The distinction matters to us: the Memory-Layer is not the whole harness. It is the part that keeps context available between steps and between agents. Tools, permissions and approvals belong to other building blocks.

On approvals, we restate what is on our website: every agent runs within a defined framework, with approval steps for critical actions. Emails, for example, are created as drafts and not sent directly. In the control center (“Steuerzentrale”), the place where you see and steer what is running, critical actions need your approval. We do not claim more than that, and we do not generalize it to functions that are not listed there.

Why memory belongs in a discussion of limits at all becomes clear from the sources. Builder.io treats the decay of context over long tasks, keyword “context rot”, as a real problem and works through examples. The LangChain post names techniques such as compaction and offloading tool outputs to counteract exactly that. A shared memory can help, but it does not decide what the agent is allowed to do. That takes limits.

With and without an approval step in the harness

Without an approval step, the harness alone decides which tool the agent uses. An agent with access to your mailbox and your customer system can then act even when the instruction was ambiguous. Errors only show up afterwards, in the worst case at the customer. There is no point at which a person would have seen the process.

With an approval step, the critical tool calls are defined in the harness as confirmation gates. You decide in advance which ones they are: payments, deletions, or anything that goes outside the company, such as an email to a customer. The agent prepares, a person approves, and only then is it executed. That costs a moment of attention and prevents the mistakes that cannot be taken back.

Honesty is needed here too: a confirmation gate is not a cure-all. If people confirm every prompt without reading it, the gate is worthless. A well-built harness asks only at the few critical points, but binds firmly there. Where these points lie depends on your business.

What you should prepare now

Availability is not an issue, because there is nothing to activate. Preparation begins in your head and on paper. Five steps you can complete this week without any tool:

1. Choose a process: Find a workflow that an agent should take over and describe it in five sentences, from trigger to result.
2. List the tools: Which systems does the agent have to touch for this? Inbox, customer management, file storage? The fewer, the better for a start.
3. Mark critical actions: What may happen without asking, and what may not? Anything that goes outside the company or moves money belongs on the approval list.
4. Define the memory: What should the agent remember, and what explicitly not? Note who can later view and correct it.
5. Question the vendor: Ask the six questions from the section on building blocks. Note what you get back in writing and what only verbally.

What we do not know and do not claim

Finally, the limits of this article. We have no measurement for businesses of your size, and we claim no savings. The benchmark values mentioned come from coding tasks and are the authors’ figures. According to Builder.io, the formula “Agent = Model + Harness” comes from Vivek Trivedy at LangChain; Builder.io does not name an inventor of the word “harness” itself. DataCamp explicitly confirms that the terms are used inconsistently. And we have only checked what is in the three texts named, not how individual products behave in practice.

What remains is a rule of thought you can apply to every purchasing decision: never ask only which model is inside. Ask what the agent is allowed to do, what it remembers and who is asked before a critical action. The difference that ultimately matters is the one between an agent that simply carries on and an agent with limits and an approval step.

Sources

• Vivek Trivedy, LangChain blog, 10 March 2026 (langchain.com/blog/the-anatomy-of-an-agent-harness)
• Matt Abrams, Builder.io blog, 6 April 2026 (builder.io/blog/agent-harness)
• Khalid Abdelaty, DataCamp blog, 15 May 2026 (datacamp.com/blog/agent-harness)
• amazing-agents.com: Agents (Memory-Layer), control center, frequently asked questions