Answer in brief
The prompt is not the process. The process is the harness. I have been saying some version of that for months. This fall five people from different corners of software each described one part of it, from executable checks to who gets to call work done. None of them said my sentence, and none of their work proves anything about mine. Together they describe a delivery system you design on purpose, not a prompt you keep rewriting.
What I mean by the harness
When an agent does real work, a prompt is one input among several. Around it sit the things that decide whether the result can be trusted: what the agent is allowed to touch, how a task is handed to it, which checks run without asking it, who is allowed to accept the work, and what record is left when it is done. That surrounding structure is the harness. You can swap the model inside it. You cannot swap out the harness and keep the same quality.
Five people, five parts of the same idea
Robert C. Martin, talking with Matt Pocock, described what happens to a long list of rules given to an agent. The models treat them, he said, in the Pirates of the Caribbean sense: "They're more like guidelines". The rules in the middle of a growing context lose their weight, and his conclusion was short:
"deterministic tools don't disappear that way."
That is his practitioner judgment, not a measured result. The part I take from it is that the rule you most need should live in a check that runs on its own, outside the model's context.
The zeroshot project puts a second part in bold under the title of its README:
"The agent that writes the code should not be the one that decides it works."
That is a design claim by its authors; I have not run their tool. It names the separation I care most about: the maker does not accept its own work.
Rise8, on its Mission O/S podcast, made the same move for security in government software:
Control is part of how the work moves, not a document at the end of it.
Alex Lieberman of Tenex, speaking at Harness's Unscripted event (the company name is a coincidence), said the models are already exceptionally intelligent, and most of the value will keep collecting at the harness layer: how you orchestrate that intelligence and how you manage context. Then:
Bad tickets and loose scoping go in, and the factory does what it was given. The quality of what enters the harness is part of the harness.
Josh Lehman, on The ClawCast, described letting a slow, expensive model call a fast decision model as a tool. It worked, and it still seemed wrong, or at least not the full picture. His conclusion was that routine choices, such as whether a response needs tools at all, belong in the harness itself, which he described as deterministic code. I am paraphrasing him here because the only transcript I have is a rough machine one.
Put together: bounded inputs, separated roles and authority, checks that run on their own, feedback that goes back to the maker, and evidence tied to the actual result. That synthesis is mine, not theirs.
What it looks like in my own operation
I run a fleet of AI agents on real work. Three pieces of it are harness rather than prompt, and I can show each one.
An agent cannot mark its own work done. The system that tracks our work refuses a completion when the verifier is also the author, and there is a test that exercises that refusal through the same route the agents use. That is one configured condition, not proof that every path to self-approval is closed.
Work is handed off as a task, not a chat. A spawned agent gets a packet that names its role, its sources, what it must not do, where the deliverable goes, and how it will be verified. Work moves from build to test to review to verification, and a failure goes back to build. Builders and testers are separate agents. The next step I want is two independent reviewers looking at the same change in parallel. I believe every change should have them, and they are not in place yet.
Some guards have been broken on purpose to prove they work. Our rule for a new guard is to seed the failure it should catch and watch it refuse. For a bug fix, the test has to fail before the fix and pass after it. These are named examples, not a claim that every guard in the fleet has been tested this way.
Where this goes next
This is evidence for a direction, not a measured result yet.
- Measuring the harness itself. I have built a replay test for it: nineteen scored cases, most of them drawn from real failures in our own work. Its first baseline run, with a rework rate taken from our own task records, is the next step.
- One change traced end to end. One is being traced now, from the task through its tests to acceptance by an agent that did not build it. The release and what is running live come next, with the leftover risks written down.
- Stronger checks. Mutation testing is planned. There is no fleet-wide coverage threshold yet.
The question for your own delivery
If you swapped the AI model you use tomorrow, what in your delivery would still catch a bad change? Whatever answers that question is your harness. It is the part worth your time, and it is the part your prompt cannot do for you.