When all of this started becoming mainstream, there was a lot of talk around artificial intelligence like: “It can already do everything,” “It will replace everyone soon,” “Just give it a task and it will do it.” I spent quite a lot of time using AI, experimenting with it, and trying to understand not only what it can do, but how it actually behaves in real tasks.
Even before MCP, when structured output, JSON input/output, API integrations, and attempts to make models behave in a more predictable way were only starting to become common, I kept coming back to one thought: there needs to be a software layer between the human and the AI.
AI is an extremely powerful tool. It knows a lot, can analyze, write code, work with images, make decisions, and solve fairly complex tasks. But it is not a magic wand. If you simply give it a task, it will not always do exactly what you need, exactly how you need it, and carry it all the way from start to finish.
A Smart but Lazy Worker
I have always seen AI a little bit like a very smart, very fast, but lazy worker. Not literally, of course. It is just that its behavior often looks like this: it knows how to do a lot, but if there is a shorter path to a result, it will often try to take it.
Sometimes that is enough, sometimes it is not. Especially when the task is large, the context grows, there are many terms, files, intermediate decisions, images, requirements, and all of those things begin to overlap. At some point, the model can lose the original thread of the task, forget something, or simply decide that the result is already good enough.
You say: “Do this.” It produces something convincing and says: “Done.”
But is it actually done? Was the result checked? Was something lost along the way? Did it break something that was already working? Was the task completed fully, or only the part that the model decided was the main one?
This is exactly where harness comes in.
What Harness Actually Is
For me, harness is that software layer around AI that defines not only what should be done, but also how the task itself should be executed.
Harness defines the agent’s behavior: which stages it should go through, which tools it should use, what needs to be checked after execution, when it should go back, what counts as an error, and at what point it can actually say that the work is finished.
Instead of a simple flow:
request → response → done
you get something much closer to a real working process:
task → analysis → execution → verification → correction → verification again → done
And this is where there is a huge difference between a model that is capable of doing something and a system that is capable of bringing the work to a result.
Closing the Agent Inside a Loop
One of the key parts of harness is the loop. The agent should not be able to simply decide: “Well, looks good enough” and stop.
It performs an action and then checks the result. If the check shows a problem, it analyzes what went wrong, makes a specific correction, and returns to verification. This continues until the task actually matches the conditions that were defined.
A run from my own document harness: one reference invoice in, twelve recorded revisions out. It starts on a compile failure and ends approved at R12 — because nothing here is allowed to declare success from inside the model’s own head. Every revision is compiled, rendered and compared against the reference by ordinary code.
But the loop itself is not magic either. You can force an agent to repeat the same wrong action ten times and still get nowhere. So what matters is not just the loop, but the structure inside it: when to analyze, when to act, when to use a particular tool, what exactly to verify, and what should happen when something fails.
So harness is not simply: “Keep doing it until you finish.”
It is more like: do it, verify it, understand what exactly is wrong, fix only what needs to be fixed, and verify it again.
AI Should Not Do Everything
There is another important part that has always seemed obvious to me: not everything should be delegated to the model.
If you need to sort data, compare JSON, calculate something, check a hash, determine which files changed, parse a structure, inspect an exit code, or perform another deterministic operation, there is no reason to make the AI reason about it and spend tokens.
That is what normal code is for.
You can write a small program in Python or Java, use shell, or any other suitable tool. It will do the job faster, cheaper, and, most importantly, the same way every time.
AI should handle the parts where intelligence is actually useful: understanding context, analyzing, making decisions, working with ambiguity, and choosing the next step. Everything else is often better handled by ordinary software.
This is why a good harness becomes a combination of two worlds: on one side, the probabilistic intelligence of the model; on the other, normal predictable software.
The model decides what to do. Code performs precise operations. The model analyzes the result and decides what comes next.
MCP Alone Does Not Solve the Problem
The arrival of MCP was an important step because it made it much easier to give agents access to external tools and data. But having MCP does not automatically mean having a good harness.
You can give an agent one hundred tools and it can still perform the task badly.
Because the main question is not only which tools are available, but whether the agent understands when and why to use each one.
MCP provides capabilities. Harness defines behavior.
It decides which tool is needed now, in what order actions should happen, what to do with the result, and how to determine whether the task is actually complete afterwards.
State, Revisions, and Control Over Changes
A very simple example shows this well. Imagine that AI created an interface for you. The result is good, but you say: “Make the sidebar a little wider.”
In a normal interaction with a model, something strange can happen. It makes the sidebar wider, but at the same time changes typography, spacing, colors, or a few other elements because it decided that this would look better.
You asked to change one thing and suddenly received a new version of half the project.
In a properly built harness, there is already an accepted state. There is a finished result that we do not want to reinterpret from scratch, and there is one new task: change the width of the sidebar.
So the sidebar changes, and then the system checks that the requested change actually happened while everything else stayed the same.
The same idea on a CV layout. Ten revisions, each one a stored, inspectable state rather than a message somewhere in a chat log. The last change here was spacing refined — a targeted revision on top of an accepted result, not a fresh reinterpretation of the whole document.
That already looks much more like normal work with a real developer. If a developer finishes a task and the manager says: “Everything is fine, just change the header here,” the developer does not start rewriting the whole project. They change the header.
That is why state, revisions, scope control, and understanding what has already been accepted are extremely important for a good harness.
The Horse Needs a Bridle
I still like the horse analogy here, even if it sounds a little unusual.
A horse can be very strong, very fast, and very capable. It can run and jump extremely well. But by itself, it will not necessarily follow the exact route that the human needs.
There is a rider who understands when to accelerate, when to slow it down, where to turn, when to jump, and how to get through the whole course.
The horse provides the power and the speed. But control over that power is what turns it into a result.
I see AI in roughly the same way. The model is already incredibly powerful. Harness becomes that bridle that directs it, keeps it on the task, and makes sure it goes through the whole path instead of stopping where it decided that the result was already convincing enough.
From a Tool to a Worker
And this is where, for me, an important line appears.
If, when working with AI, you constantly have to stand next to it and say: open this file, now look here, fix this, now check that, go back there, do not forget this — then you are still working with a very powerful tool.
It accelerates you, but you are still controlling every step.
With harness, the approach starts to change. You give it a task. The agent goes through the defined process, uses the right tools, checks itself, fixes mistakes, and brings you the result.
After that, you interact with it more like a manager working with a developer. You review the finished work and say: this part is good, this part needs a small correction, change this here. Then the agent performs a targeted revision instead of destroying the work that is already done.
This is where AI starts to move from being just a tool toward being something closer to a worker.
Not the Benchmark, but the Work Being Done
Today, a lot of attention is still focused on which model is smarter, which one has a higher benchmark score, which one has a larger context window, which one writes better code, or which one performs better on difficult reasoning tasks.
All of that matters. But models are already smart enough for a huge amount of real work.
For the end user, it is not always that important whether one model scored 89% and another 92% on another benchmark. There is a much simpler question:
Was the job done or not?
Was the work completed from beginning to end, or did the model simply solve a few pieces of the problem well?
And this, in my opinion, is where one of the most important stages of AI development is happening now. We do not only need models that become slightly smarter. We need systems that can turn the intelligence we already have into completed work.
Systems that understand when to use a tool, when to write a small program instead of spending reasoning on it, when to verify the result, when to go back, what should no longer be changed, and at what point they can actually say: “Done.”
Why Harness Is Becoming So Important
This is why I see harness as one of the key directions in the development of agentic AI.
Not because models are not smart enough. Quite the opposite — they are already extremely capable.
The problem is increasingly becoming something else: how do we take that intelligence and make it predictable, controllable, and capable of carrying work from A to Z?
AI can be our incredibly fast and intelligent horse. But without a bridle, it can still run in the direction that seemed right to it.
Harness is the system that directs that power where the human actually needs it to go.
And maybe the next major stage of AI development will not only be about making models smarter. It will also be about learning how to take the intelligence we already have and turn it into a worker that can be given a task and return with the work actually done.