Four kinds of work sit behind any agent, and each has a name that sounds harder than the thing it describes: prompt, context, loop and harness engineering. This note is about harness engineering. The other three have notes of their own, and they can be read in any order.
Picture sending a friend to the shop for you. How you word the request is prompt engineering. What you send with them — the list, the money, a photo of the empty fridge — is context engineering. What they do when the shop has no milk is loop engineering. The bag, the bus fare and the rule about how much they may spend is harness engineering.
So: the bag, the bus fare and the spending rule — everything around the request, the list and the return trip. Or think about setting up a kitchen for a child who is learning to cook. Sharp things out of reach. Ingredients where they can be found. A bin for the mistakes. A grown-up within earshot. You are not teaching the recipe at that point; you are arranging the room so that the recipe can go well and going wrong is survivable.
In short
- What
- The setup around the model: the tools it can call, what it is allowed to touch, what it is shown at each step, where its work is written down, and what happens when something fails.
- Why
- It decides what is possible at all. No wording lets a model do something it has no way to do, or reliably stops it doing something nothing prevents.
- When
- The moment an agent does anything real — reads a file, calls a service, spends money, or changes something a person will see.
- How
- Give it exactly the few things it genuinely needs, make every action readable back afterwards, and give every failure a defined outcome.
What the harness is
Everything that is not the model and not the words. Which tools exist and what they are called. What each one is permitted to do, and to what. What the agent is shown at each step and what is hidden. Where its work gets written down so it can be read later. What happens when a step fails. How a person steps in, and how easily.
None of that is clever writing. It is closer to carpentry — building the room the work happens in.
Why it decides what is possible
Two sentences carry most of this. No amount of wording lets a model do something it has no way to do. And no amount of wording reliably stops it doing something that nothing actually prevents.
A prompt is a request. A harness is the shape of the room. Asking politely that a system never delete anything important is not a permission system; it is a hope. If deleting is possible, it will eventually happen — after an odd instruction, an unusual input, or simply a mistake.
The reverse is the cheerful half. A modest model in a well-built harness does careful, useful work, because the room only allows careful work. The strongest model in a badly built one will tidy the wrong room very efficiently.
When you reach for it
The moment anything real happens. Reading a file, calling a service, writing to a database, sending a message, spending money, changing something a person will see. Up to that point you have a conversation; after it you have an actor.
There is a second, less obvious moment. When the same kind of mistake keeps coming back despite clearer instructions and better context, that is usually a sign the fix is structural rather than verbal. If a thing keeps getting knocked over, the answer is to move it, not to keep asking for more care.
How to build one
List what the agent genuinely needs to touch for the job in front of it, and give it exactly that. Not the neighbouring things, not the whole account. Narrow is easier to reason about and easier to explain to someone else later.
Keep the tools few and plainly named. Twenty near-identical tools is not only a permissions problem; it is a context problem, because now the model has to spend its attention choosing between them.
Put a confirmation in front of anything that is hard to undo. A person saying yes once is cheap. Reversing a bulk change is not.
Make every action readable back afterwards — what was called, with what, and what came back. When something goes wrong, the difference between a ten-minute answer and a lost afternoon is almost always whether that record exists.
Give failures a defined outcome. A tool that quietly returns nothing teaches the agent that the step succeeded. Say what happened, and say what should happen next: retry, skip, or hand it to a person.
And test the room, not just the cook. Ask what the worst plausible action is, and check whether the setup allows it. If it does, the prompt is not the place to fix it.
The four together
They are layers, not rivals, and it helps to go down them in order when something misbehaves. Doing the wrong job — look at the prompt. Doing the right job with the wrong information — context. Giving up too early, or going round in circles — the loop. Could not do it at all, or did something it should never have been able to do — the harness.
None of the four is a finding. They are vocabulary: four names we use often enough in our own work on agents that it seemed worth writing them down plainly, for anyone who has heard the terms and quietly wondered what they meant.
