The agent harness matters more than the model you buy

An agent harness is the product. Not the model name on the slide, and not the demo that worked once in a conference room.

The agent harness is everything around the model that lets it act, remember, and stay on the rails. Tools it can call. Context it can see. Memory it can keep. A control loop that decides what happens next. LangChain's anatomy write-up puts the split in one line: Agent = Model + Harness. A raw model is not an agent. It becomes one when a harness gives it state, tool execution, feedback loops, and constraints it cannot talk its way past.

Owners keep asking which model to buy. Wrong question. On most firm work, swapping the model rarely changes the outcome. Same model, different agent harness, different result. If you are not the model, you are the harness. You do not own the lab that trains the weights. You do own the system you hand a client.

That is the buying rule. The model is rented. The harness is the product. If you want a plain map of how that system sits in a firm, start with how it works before you pick a vendor logo.

What an agent harness actually is (tools, context, memory, control loop)

Microsoft Learn defines an agent harness, sometimes called an AI harness, as the runtime scaffolding that turns a language model into an agent that can perform work. Google Cloud describes an agent harness as a software environment that surrounds the model, so it can interact with outside tools, remember past interactions, and execute multi-step tasks.

Four working parts sit inside that definition.

Tools are what it can touch. Your CRM, your calendar, your document store, a sandbox, a browser. Not the open internet. Named actions, with named limits.

Context is what it can see at the moment of decision. The standing instructions. The file in front of it. The last tool result. The rule for what a qualified lead looks like in your firm.

Memory is what survives the session. Databricks notes that base models do not retain memory beyond the current context window. Skip that design, and the agent meets every client as a stranger. Databricks is also blunt about the gap: without a harness, a model can answer questions, but it cannot reliably run code, call APIs, access files, remember prior work, or complete a multi-step workflow on its own.

The control loop is what happens next. The main agent execution pattern today is a ReAct loop: the model reasons, takes an action via a tool call, observes the result, and repeats. Shunyu Yao and coauthors introduced that loop in 2022, in the paper ReAct: Synergizing Reasoning and Acting in Language Models. The loop is old news. The discipline around it is not.

Picture an engine on a stand. It can rev. It cannot take a client to a closing. The model is the engine. The agent harness is the car.

The wedge does not move. The harness is the product. A digital employee is not a chat window with a job title. It is this system, pointed at one queue of work, with a human still accountable for the outcome.

Why the model stopped being the bottleneck

LangChain notes that models mostly take in text, images, audio, or video and return text. Out of the box they cannot keep durable state across interactions, execute code, reach realtime knowledge, or set up an environment and install what the job needs. Those gaps are not a prompt problem. They are a harness problem.

This guide to agent harnesses repeats a line worth using in a partner meeting: "The model is commodity. The harness is moat." Phil Schmid at Hugging Face frames the model as the CPU and the harness as the operating system. A slightly faster CPU does not save a firm if the operating system drops files and emails the wrong person.

Manus, the autonomous agent that went viral in early 2025, spent six months and five complete architectural rewrites on their harness before it was production-ready. The model was not the six-month project. The harness was.

So the owner question changes. Not which model. What surrounds it. What can it touch. What can it see. What may it do without asking.

If each step in a multi-step agent pipeline succeeds 95% of the time, chaining 20 steps together drops the end-to-end task completion rate to 36%. A slick demo hides that math. The model did not get worse. The chain got long.

Agent harness vs agent (and vs framework)

Three words get mashed together in sales calls. Separate them so you can say them back.

Agent: the thing that does the work. It has a job, a queue, and a definition of done. For example, a refund agent might review a request. The agent is who the client thinks they are dealing with.

Agent harness: the system that makes that agent reliable. The same guide calls this the infrastructure layer that wraps an AI model and manages lifecycle, context, tool access, verification, and safety in production. That is the asset. That is also where lock-in lives.

Framework: the scaffolding developers build the harness on. A toolbox, not a finished system. Microsoft's Agent Framework provides an opinionated, batteries-included harness for research, coding, data analysis, and other long-running work. It composes existing building blocks rather than defining a separate agent runtime. The create_harness_agent factory returns a fully configured agent. Useful. Still not a system a managing partner can run on Tuesday.

A toolbox does not know your approval rules, your matter types, or which email may leave the building. Confusing a framework with an agent harness is how firms buy a library and call it an employee.

The agent does the job. The agent harness makes the job repeatable. The framework is how engineers assemble the harness. Rent the framework if it saves time. Own the harness.

The five parts of a harness you can ship

You can ship five parts. Skip one and the demo still looks fine. The Tuesday queue will not.

Tools

Tools are the only hands the agent has. Name them. A scheduling tool. A CRM read. A document fetch. A sandbox. LangChain notes that harnesses ship with a bash tool so models can write and execute code, and that sandboxes give agents safe operating environments.

Google Cloud notes that many modern agent harnesses use the Model Context Protocol (MCP), which standardizes how agents connect to data sources and external tools. Swaps get easier. Safety does not decide itself.

For example, a refund agent might see "issue refund" and "draft refund for approval" as two tools. The first moves money. The second moves a draft. If both sit on every turn, you do not have a policy. You have a coin flip with API access.

Name what it cannot touch. No wire. No delete. No client send until a human clears the first batch. The absent tool is a design decision.

Context

Context is the packet at the moment of decision. Databricks defines a system prompt as the standing instructions given every run: who the agent is, what it is trying to accomplish, and which rules it must follow. Then the live facts. This file. This fee rule. This tool result.

Bad context is a dump of the wiki. Good context is the page a sharp associate would pull. As the thread grows, the harness decides what stays active and what gets summarized. Databricks calls that context compaction.

Harnesses ship with filesystem tools. LangChain calls the filesystem the most foundational harness primitive, because the agent can read the brief, write the draft, and leave a trail. Git adds versioning so the agent can track work, roll back an error, and branch an experiment. That trail beats "the AI said so."

Memory

Session memory dies with the chat. Durable memory is what you choose to store: preferences, open loops, the last promise, the escalation that already happened.

Throw away the chatter. Keep the commitment. For example, a mortgage desk does not need every sentence from last month. It needs the rate lock date, the missing document, and the fact that this borrower already asked twice.

Guardrails

Guardrails are rules built into the harness that block unsafe or unapproved actions. Google Cloud calls the agent harness a security checkpoint between the language model and your external systems. A sandbox, in Databricks' terms, is an isolated workspace where the agent can act without affecting anything outside that environment.

Human in the loop is a named checkpoint. Who approves. On what threshold. In what window. A partner can live with an agent that drafts. An agent that sends is a different risk talk. Put the checkpoint in the harness.

Evaluation loop

The fifth part is how you know it works before a client does. Define the task, the pass, and the failure before launch. A vibe check from the builder is not a shippable harness.

Ship the five together. Tools without guardrails is a liability. Memory without context is a junk drawer. A loop with no evaluation set is a hamster wheel.

Harness engineering: context, tools, guardrails

Harness engineering is the discipline of designing the system around the model, not the clever line inside the prompt. LangChain states it cleanly: harness engineering is how we build systems around models to turn them into work engines.

Prompt engineering writes the standing instructions. Useful. Narrow. It does not give the model a filesystem, a sandbox, or a stop button. A perfect prompt inside a system with no brakes still sends the wrong email.

Context engineering decides what the model sees on this turn. The brief, the policy, the last tool result, and nothing that would distract it.

Harness engineering sits above both. The parts list includes system prompts, tools, skills, MCP connections and their descriptions, bundled infrastructure such as a filesystem, sandbox, and browser, orchestration such as handoffs and model routing, and hooks for compaction, continuation, and checks. Microsoft's runtime exposes switches to turn pieces off, including file memory, web search, tool auto-approval, and compaction. A production harness is defined as much by what you disable as by what you turn on.

Three levers move reliability more than a new model release.

What the agent can do. Fewer tools, named well, beat a drawer of APIs. Google Cloud notes that pre-built connections to common tools and APIs mean developers spend less time writing integration code. Those connectors do not pick the right three for your firm.

What the agent can see. The right page, not the whole drive.

What it may do without asking. Money, client email, and record changes wait. Drafts and lookups can move.

Opinion: an AI operating system is a harness built around the model. Not a pile of chats. Shared tools, shared memory rules, and a shared evaluation set, so each new agent inherits the rails. That is the bet behind an AI operating system. The model stays replaceable. The harness does not.

The evaluation loop

You cannot ship what you cannot measure. Vendor pages skip this because a screenshot is easier than a pass condition in your language. Do not skip it. This is the part that separates a pilot from a harness you can hand a client.

Run this before launch, and again every time you change a tool, a prompt, or a model.

1. Write the task the way the work arrives. A forwarded email. A half-filled form. A voicemail transcript. Not a cleaned prompt from the builder.
2. Write the pass condition in one sentence a partner would accept. Booked, qualified, and on the right calendar. Or draft only, correct file, no client send.
3. Write the failure you will not tolerate. Wrong client. Invented fee. Money moved. A promise the firm cannot keep.
4. Freeze real scenarios and replay that same set on every change. New model, same scenarios. New tool, same scenarios. If you only retest the path you just fixed, you are grading your memory.
5. Tie the score to the business line. Bookings kept. Time to first response. Error rate. Escalation rate. If the loop cannot name those, it is a demo reel.

For example, a refund agent might pass only when the draft cites the policy clause, stays under the approval threshold, and lands in a human queue. A polite apology that refunds the wrong amount is a fail.

The 95% step that becomes 36% across 20 steps is why the set has to be end to end. Partial credit keeps pilots alive in the meeting and dead in the inbox.

Keep the set mean. Angry client. Missing document. Lookalike name. A request that should be refused. A harness that only passes polite scenarios is not ready for a service business.

Cost and reliability: what a good harness saves

A bad harness burns spend on retries, loops, and bad tool calls. The model rereads a long transcript, calls the wrong tool, apologizes, and calls it again. You pay for every lap. A tight harness cuts that waste: smaller context, fewer tools, a stop when the pass condition is met.

Retries are the quiet bill. A loop that calls the same tool again because the context was vague is not intelligence. It is a missing stop rule.

Do not manage cost per token. Manage cost per completed task. Token price is a vendor number. Completed tasks are yours: a booked consult, a qualified file, a draft a human can send. If the task did not finish, the tokens were overhead.

Reliability is the real line item. Fewer escalations. Fewer corrections. Fewer apologies. An agent that is cheap and wrong is not cheap. The partner still spends the hour. The client still remembers the miss.

No magic ratio belongs here. The queue, the tools, and how often a human catches the wheel set your number. What holds without a figure: a good harness spends calls on the step that moves the file, and refuses the step that creates a cleanup project.

A sandbox that contains a bad action is cheaper than an incident. An approval on send is cheaper than a retraction. Guardrails are how you stay fast without lighting up risk.

If a vendor cannot show the evaluation set and the escalation path, you are buying a model subscription with a costume. Owning the rails is a pricing conversation only after the work is named.

Agent harness examples, and the build-or-buy decision

Keep the names short. None of them is your firm.

Microsoft Agent Framework is a batteries-included harness for research, coding, data analysis, and other long-running work. It composes existing blocks. It also ships default guidance, and switches you can turn off, including file memory, web search, tool auto-approval, and compaction. A reference for what included can mean. Not your approval policy.

LangChain's anatomy is the parts list: model plus harness, from prompts to sandboxes to the ReAct loop. Use it to audit a build.

Databricks and Google Cloud publish the operator read: infrastructure that lets a model act, plus compaction, guardrails, and a security checkpoint. Read them when a seller says "agent" and cannot point to the checkpoint.

The longer guide adds the moat line and the Manus lesson. Production took harness rewrites, not a model press release.

Build when the workflow is your edge. The way you qualify, price, and follow up is the business. Own the tools, the memory fields, and the evaluation set. Buy when the work is standard and low risk. Rent a finished agent if the rails match your risk, and keep your own scenarios so a vendor update cannot silently change the pass rate.

Question	Build	Buy
Is this workflow how we win clients?	Own the agent harness.	Do not hand the edge to a vendor default.
Is the work standard and low risk?	Only if you already have the team.	Buy, then keep your evaluation set.
Can we swap models next year?	Own the harness. Rent the model.	Ask who owns the harness if you leave.
Who approves money and client sends?	Put the checkpoint in your harness.	Confirm the checkpoint is real, not buried.

The harness is where the lock-in lives. Own the harness. Rent the model. A framework can speed the build. It is not the asset.

The case studies show the work in a service firm. The industry pages show where the same rails get pointed. The AI Diagnostic on the AI Blueprint is the short test of whether your queue is a build, a buy, or a do-not-touch. A workshop is the longer room if partners need a whiteboard.