TL;DR
A harness is the scaffolding around something that has power but cannot run on its own.
The word is old. A horse harness aims a horse. A test harness runs your code. An AI harness makes a model useful.
Every harness has the same five parts: instructions, tools, memory, a loop, and gates.
A harness is the scaffolding around something that cannot run on its own. The thing in the middle supplies the power. The harness decides where that power goes, what it can touch, and when it has to stop.
That definition is the whole post. Everything below is the same idea drawn twelve times, in the places the word actually gets used.
I am writing this because the word turns up constantly in AI conversations now, usually as jargon, usually assumed. It is not jargon. It is one of the oldest ideas in engineering, and once you see the shape you see it everywhere.
Start with the horse
The word did not come from software.
A horse can pull. That is raw capability, and on its own it goes nowhere useful. Put a harness on it and the pulling becomes a cart that moves in the direction you chose.
Notice what the harness does not do. It does not make the horse stronger. It adds no power. It converts power that already existed into work that was not happening before.
Every harness in this post does exactly that job. Nothing more.
The word already lived in software
Long before anyone said this about AI, programmers had a test harness.
Your code sits in the middle. On its own, it is a function nobody called. The harness is the rig it sits inside: it feeds in prepared inputs, runs the thing, catches what comes out, compares that against what should have come out, and reports pass or fail.
Same shape as the horse. The code has the capability. The harness turns it into a result you can trust.
That is why the word felt natural to reach for again. The situation repeated.
Why AI brought the word back
A language model does exactly one thing. Text in, text out.
It cannot open a file. It cannot run a command. It cannot remember what you told it yesterday. It cannot check whether its own answer was right.
Ask it to fix a bug and you get a confident block of text describing a fix, with no way to apply that fix and no way to learn whether it worked.
So the model is a horse with no cart attached. Enormous capability, zero traction. The word came back because the problem came back.
The one sentence to remember
Core plus harness equals something that works.
Swap in whatever core you like. Horse plus harness equals a moving cart. Code plus harness equals a test result. Model plus harness equals an agent.
The core is where the capability lives. The harness is everything else: what it was told, what it is allowed to touch, what it remembers, how many attempts it gets, and what it is stopped from doing.
Most arguments in AI right now are about which core is best. The harness usually explains more of the outcome.
The five parts of a harness
Take apart any working harness and you find the same five parts. The names change between tools and fields. The parts do not.
Instructions. What it should do.
Tools. How it touches the real world.
Memory. What it knows from before this moment.
The loop. How it tries, checks, and tries again.
Gates. What it is not allowed to do.
That list is the whole map. The next five sections walk through it slowly, one picture each.
Part one, instructions
Instructions are the standing brief. Not the request you make today, but the things that are true every time.
In a test harness that is the setup and the fixtures. In an AI harness it is usually a plain text file loaded at the start of every session: how this project is laid out, what to never touch, how you want answers shaped.
The useful mental picture is a new colleague on their first day. Instructions are the onboarding doc you hand them. Good ones make every later request shorter, because you stop re-explaining the basics.
One warning for later. Instructions are requests, and requests can be ignored.
Part two, tools
Tools are the hands.
A tool is any specific action the core is allowed to trigger: read a file, write a file, run a command, search the web, call an API, query a database. The core does not perform the action itself. It asks, the harness performs, and the harness hands back the result.
That handback is the part beginners miss. A tool is not just an outgoing capability. It is a round trip. The system acts, the world answers, and the answer becomes new information to think about.
Zero tools gives you a chat window. Three good ones gives you something that can finish a task.
Part three, memory
Memory is what survives.
Every model has a context window, which is the amount of text it can hold in mind at once. When a conversation gets long the oldest parts fall out. Nothing announces it. The system simply stops knowing them.
Memory in a harness is anything that writes facts down outside that window so they can come back later. Files, notes, a database, a log of decisions. When an old fact is needed, the harness fetches it and puts it back in front of the core.
This is why a well-built setup seems to know your project and a fresh chat does not. Somebody wrote things down.
Part four, the loop
The loop is the engine.
One question and one answer is not a working system. A harness runs a cycle: look at the goal, pick an action, take it, look at what happened, decide whether it is done, and go again if it is not.
That is the difference between asking for advice and getting work finished. Advice is one pass. Work is a loop that keeps going until a check passes.
The loop is also where things break in interesting ways. Too few turns and it gives up mid-task. Too many with no exit condition and it circles forever. I wrote more about that in what is real and what is hype about agent loops.
Part five, gates
Gates are the parts that say no.
A gate is code that runs whether the core wanted it to or not, and can stop an action outright. A test that must pass before work counts as finished. A check that blocks a write to a protected file. A rule that refuses to send anything containing a password.
The distinction from instructions matters, so here it is plainly. An instruction is read and interpreted. A gate is executed and cannot be talked out of it.
If a rule genuinely must hold, it belongs in a gate. If it is a preference, leave it in the instructions and accept that it will occasionally be ignored.
Three harnesses, one shape
Now the payoff for the general definition. Put the same core in three different harnesses and you get three different products.
An eval harness measures it. Prepared cases go in, scores come out, and the point is a number you can compare against last week.
An agent harness makes it act. Tools, memory, a loop, gates, and the point is a finished task.
A test harness proves it works. Known inputs, expected outputs, and the point is a red or green build.
Same five parts every time. What changes is the job you pointed them at. This is why the word is worth learning as a general idea rather than as one vendor’s feature name.
Same core, two harnesses
Here is the version of that comparison that costs people the most money.
Take one model. Put it in harness A: no tools, no memory, one pass, no gates. You get a confident paragraph of advice and no work done.
Put the same model in harness B: four tools, a notes folder it can read and write, a loop that runs until the tests pass, and a gate that blocks anything outside the project directory. You get a finished, checked change.
Same core. The gap between those two outcomes is not intelligence. It is the harness.
Which is also the build order, if you want one. Start with instructions and nothing else. Add one tool. Add memory when you catch yourself repeating a fact it should know. Close the loop with one check. Add one gate, for the one thing that must never happen. If you want a finished example, the second brain I run on Claude Code is all five parts in public, at github.com/eugeniughelbur/obsidian-second-brain.
Frequently asked questions
What is a harness?
A harness is the scaffolding around something that cannot run on its own. The thing in the middle supplies the capability. The harness aims it, feeds it, limits it, and decides when it stops.
Is a harness only an AI thing?
No. The word is much older. A horse harness converts pulling into a moving cart, and a software test harness runs your code against prepared inputs and reports pass or fail. AI borrowed a word that already fit.
What is a test harness?
A test harness is the code around your code: it supplies inputs, runs the thing under test, captures the output, compares it against what was expected, and reports the result.
What is an agent harness?
An agent harness is the specific case where the harness exists to make a model act. Instructions, tools, memory, a loop, and gates, wrapped around a language model so it can finish tasks instead of describing them.
What is the difference between a harness and a framework?
A harness is the arrangement of parts around your core. A framework is a product that packages a harness for you. You can build a working harness with a text file, one tool, and a loop, and never install anything.
Which part of a harness should I build first?
Instructions, then one tool. Memory, the loop, and gates each solve a problem you have not hit yet, so building them early means guessing at what you need.
Key takeaways
A harness is the scaffolding around something that cannot run on its own. It adds no capability, it converts capability into work.
The word is not AI jargon. A horse harness and a software test harness are the same idea in different materials.
Every harness has the same five parts: instructions, tools, memory, a loop, and gates.
Instructions are requests that get interpreted. Gates are code that gets executed and cannot be talked out of it.
Same core, three harnesses, three products: an eval harness measures, an agent harness acts, a test harness proves.
The same model in two different harnesses produces two completely different results, which is why the harness often explains more of the outcome than the core does.
Further reading
What is an agent harness? Inside a real one - the builder-level version, with the anatomy of a real one.
AI agent loops decoded - what is real and what is hype about the loop part.
Claude Code as a second brain - all five parts running together on a real setup.
Claude Code hooks reference - the official documentation for the gate layer, if you want to build one today.
obsidian-second-brain on GitHub - the open-source harness the examples come from, MIT licensed.
About the author
Eugeniu Ghelbur builds production AI agent systems and the tooling around them. He maintains obsidian-second-brain, an open-source Claude Code skill that runs an Obsidian vault as a living knowledge system, starred by over 4,000 developers on GitHub and MIT licensed. He writes The AI Operator, where this post first appeared.