After the agent, the workflow and the memory: the harness
Harness, agent runtime, agent loop. The term is on every AI conference slide and in every tool release. And just like with the earlier buzzwords, the hype hides something concrete.
In our series we wrote what an AI agent is, an LLM that calls tools, how you connect single steps into an agentic workflow and how a knowledge graph works as memory. In those pieces the word harness kept coming up without us explaining it. This is that piece.
A language model on its own does one thing: predict text. It sends no email, opens no file and remembers nothing from the previous turn. The harness is the software that turns that into an agent that acts. You rarely operate the raw model; what you use is the harness around it. Claude Code, Cursor, the agent in your support tool: all of them are harnesses around the same kind of model.
What a harness actually is
The model is the engine. The harness is the rest of the car: the steering, the brakes, the dashboard and the chassis. An engine on a test bench revs loudly and goes nowhere. Only in a car does it become transport. In the same way a model only becomes an agent once a harness sits around it that gives it tools, runs its answers and keeps the whole thing on course.
A bare model
Predicts text and nothing more. No actions, no memory between calls. You ask something, you get words back.
A model with tools
Function calling added: the model can call a tool. A step becomes an action, but it stays at that one step.
A harness
Runs the loop: model, tool, result, model again. With context management and guardrails around it. This is where capability becomes a working agent.
A model predicts text. A harness lets that text do something, step after step, within boundaries you set. Whoever builds an agent is mostly building the harness.
The loop is the heart of the harness
The beating part of every harness is the agent loop. The model does not talk to your systems itself; the harness sits in between and repeats the same cycle until the task is done.
The harness sends the context
The model receives the task, the available tools and everything that has happened so far, delivered in one package.
The model picks a tool
It answers with a tool call instead of text for you: call this function with these parameters.
The harness runs the tool
An API, a database query, a file being edited. The harness runs it and reads the result back.
The result goes back to the model
With that new information the model decides the next step. Another tool, or a final answer.
The loop repeats until it is done
Step by step the system works through a whole task this way, with the harness directing every round.
This is exactly what Claude Code, Cursor and every coding agent run under the hood. What sits underneath is a clean loop that hands the model the right context and the right tools time after time. That is all it is.
What else sits in a harness
The loop is the skeleton. What lets a harness hold up on real data are the layers around it.
Context management
A model's context window is finite. The harness decides what goes into the prompt each turn, summarizes what grows too long and pulls in the right memory. This is where a knowledge graph plugs in as a source.
The tool layer
The bridge between the model and your real systems. Define tools, read the model's tool calls, run them safely and return the answer in a form the model understands. MCP standardizes that.
Error handling
A tool fails, an API is down, the model asks for something impossible. The harness catches that, retries or stops cleanly, so a single failed step does not take down the whole run.
Guardrails
What the agent may do on its own and what a human has to sign off on. Permissions, hard limits and a human in the loop for irreversible actions.
The context window is the model’s workbench. The harness decides what lies on it: too much and the model gets lost, too little and it misses the fact it needed.
Harness, workflow or agent?
These three terms run together in every discussion. They describe different layers, and whoever keeps them apart sees through any pitch.
The agent: what it can do
The model with tools. The capability to do something instead of only returning text.
The harness: what runs it
The software that makes the agent run. The loop, the tools and the control underneath. The engine of the whole.
The workflow: how you order it
How you connect multiple steps into a system that finishes a task. The structure on top.
So an agentic workflow always runs inside a harness somewhere. The workflow says which steps there are and in what order; the harness actually runs each step and keeps it inside the lines.
The agent is what it can do. The harness is what runs it. The workflow is how you order it. Three words for three layers that need each other.
Why the harness is half the work
When an agent suddenly performs much better, the model gets the credit. Often rightly, and just as often a large part of that jump comes from the harness around it. The same model behaves completely differently depending on what you build around it.
A weak harness loses the thread halfway through a long task, cannot recover from a failed tool and has no brake on irreversible actions. A strong harness keeps the model on course across dozens of steps, catches errors and knows when to ask a human. The model you license from a vendor and swap when a better one comes along. The harness is the part that is yours.
A stronger model gets the credit. A large part of what an agent can do comes from the harness around it. That is where your reliability, your safety and most of the engineering sit.
Off the shelf or build your own
Most people already use a harness without calling it that. Claude Code, Cursor or a platform’s agent runtime are off-the-shelf harnesses. That is exactly right as long as your task fits a standard shape. You build or customize one yourself only once you need your own tools, your own boundaries and write access to your own systems.
Use an existing harness
Your task fits a standard shape: writing code, answering questions about your documents, an assistant inside your tool. Claude Code, Cursor or a platform's agent runtime do the work. Building your own is needless complexity there.
Build or customize a harness
You need your own tools, your own guardrails and controlled write access to your systems, tuned to your risk. Then the harness becomes the part you genuinely want in your own hands.
Start as simple as possible here too. You build your own harness only once an existing one truly gets in your way. Every layer you add is also one you have to maintain while the models underneath keep changing.
The hard part is keeping the loop running
You write an agent loop in an afternoon: a loop that calls the model, runs the tool and sends the result back. That is the easy part. The real work starts the moment that loop runs on real data every day, with write access to your systems, while the models underneath keep changing.
Then the context management has to grow with longer tasks, every error has to be caught, the guardrails have to hold for irreversible actions, and you have to be able to see what happens in production. This is exactly the layer we build for clients: AI agents and automation that keeps working after the demo. The growth system underneath the site you are reading runs on it itself: every change goes through such a loop, with guardrails and a human who signs off on what goes out.
You write an agent loop in an afternoon. A harness that holds up on real data for months without going off the rails, that is engineering.
Conclusion: the model delivers text, the harness delivers an agent
A harness becomes clear once you see it as the engine around the model. The model predicts text; the harness runs the loop that turns it into actions, and sets the boundaries within which that happens safely.
The loop is the heart
Model, tool, result, model again, until the task is done. That is what every agent runs under the hood.
The control lives in the harness
Context management, error handling and guardrails make the difference between a demo and something that holds up on real data.
You swap the model, the harness is yours
Models change. The harness around it is where your tools, your boundaries and your reliability sit.
Start with an existing harness, learn where it gets in your way and build your own version only once you genuinely need it. Working in a demo and reliable in production are two different things, and the difference lives in the harness.
What is an AI harness?
What is the difference between a harness and an AI agent?
What is an agent loop?
Do I need my own harness or can I use an existing one?
Why does the harness decide whether an agent is reliable?
An AI agent that runs reliably on your own systems?
We build the harness around the model: the loop, the tools, the context management and the guardrails that keep your agent on course while your systems and the models change. From first setup to ongoing management.
