The Model Is the Engine. The Harness Is the Car.

01It said "done", and nothing worked

You ask an AI to fix a bug. It confidently edits a file and reports "done". You run the app: still broken. You conclude the model is not good enough and reach for a bigger, more expensive one. Most of the time, that is the wrong diagnosis, and the more expensive model fails the same way.

The problem is almost never the model’s intelligence. It is that the model was working blindfolded: it never saw the actual error, never ran the tests, and had no way to check its own work. "Done" just meant it stopped typing. Fixing that is a discipline with a name, and it is where most of the real engineering in AI systems now lives.

02The model is the engine. The harness is the car.

The harness is everything around the model call: the tools it can use, the environment it runs in, the loop that feeds results back, and the check that decides when it is actually done.

03See it for yourself

Below is the same AI fixing the same bug, twice. First with no tools: it guesses, edits, and declares victory on a fix it never tested. Then with tools: it reads the error, runs the tests, sees red, and keeps going until they are green. Watch which one is actually done at the end.

04The naive harness: an expert, blindfolded

Here is the "harness" most people start with. It is a single model call. Nothing reads, nothing runs, nothing checks.

def fix_bug(repo, model):
    prompt = "Fix the bug in this code:\n" + repo.read_all()
    patch = model.complete(prompt)   # one guess, no feedback
    repo.apply(patch)
    return "done"                     # 'done' = the model stopped typing

Three things are missing, and each is a whole capability. The model never reads the specific error, so it guesses which file. It never runs anything, so it has no idea whether the patch worked. And there is no loop, so even if it could check, it gets exactly one attempt. This is a surgeon operating blindfolded and then announcing the operation was a success.

05The four capabilities that matter

Turn the blindfolded model into a working agent by adding four things. They are not equally valuable, and they have an order: a retry loop is worthless without something to run, and running is worthless without something to read.

The one that changes everything: verify-and-retry

Reading is table stakes. The capability that turns a demo into a tool is letting the model check its own work and try again. "Done" stops meaning "the model stopped" and starts meaning "the tests are green". The harness, not the model, owns the definition of done.

def fix_bug(repo, model, run_tests):
    history = []
    for _ in range(6):                       # RETRY LOOP
        failing = run_tests()                # RUN: a real signal
        if not failing:
            return "verified: all tests pass"
        context = repo.read(failing.file)    # READ: the real code
        patch = model.edit(context, failing.error, history)
        repo.apply(patch)
        history.append((failing.error, patch))
    return "gave up after 6 tries (still failing, and it KNOWS)"

06You do not have to write the loop

Once you see the shape, most of it is provided. A tool-runner SDK is exactly this loop, productised: you declare the tools, and it handles the calling, the feeding-back, and the looping until done.

runner = client.beta.messages.tool_runner(
    model="claude-opus-4-8",
    tools=[read_file, edit_file, run_tests],   # the harness, declared
    messages=[{"role": "user", "content": task}],
)
final = runner.until_done()   # it runs read -> edit -> run -> loop for you

A full coding agent (Claude Code, or an internal one) is the same idea at the next scale up: the same read/run/verify loop, plus a sandboxed workspace, memory, and sub-agents, so it can take on a whole task instead of one call. The model inside is unchanged. The capability is the harness around it.

07Now build one yourself (30 minutes)

The fastest way to believe "it is the harness, not the model" is to watch the same model succeed and fail on the same task as you add and remove one capability. Do this in half an hour with any model API.

1. 1

   Make a tiny broken repo

   One function and one failing unit test (say, a password validator that does not reject empty strings). Confirm the test is red.

2. 2

   Blindfold run

   Paste the whole file into the model, ask for a fix, apply the patch, and re-run the test yourself. Note two things: did it pass, and did the model CLAIM it passed? Often it claims success on a still-red test.

3. 3

   Add READ + RUN + LOOP

   Now feed it the failing test name and error, apply its patch, run the tests in code, and if still red, feed the new error back, up to six times. Watch it self-correct into green. Same model, different outcome.

4. 4

   Remove RUN, on purpose

   Take away the test run so it cannot check itself. Confirm it goes straight back to claiming success on a broken fix. That single removal is the entire lesson: without verification, 'done' is a guess.

5. 5

   Add a SANDBOX

   Run the tools in a temp directory or container. Prove it by giving the agent a tool that could delete files and confirming a wrong move is contained, not catastrophic. Capability without isolation is a loaded gun.

08Mistakes that send you shopping for a bigger model

1. 1Upgrading the model to fix a harness gap. The model "couldn’t" fix the bug because it could not run the tests, not because it was dim. A better harness beats a bigger model here, at a fraction of the cost.
2. 2Trusting "done". If nothing in your harness checked the result, "done" means "the model said done". Gate every success on a real check: tests green, output validates, the file compiles.
3. 3A retry loop with no verifier. Six attempts and no way to tell which one worked is six guesses, not self-correction. Add the verifier first, then the loop.
4. 4Tools with no sandbox. A shell and file access on a real machine means one confused or injected instruction can run a destructive command with your permissions. Isolate first.

09The whole thing in one screen

10Where to go next

This article is the on-ramp. The interactive lesson lets you bolt capabilities onto a bare model and watch the same task's success rate climb from almost never to almost always, then reason about the tradeoffs:

• Harness Engineering, assemble the harness capability by capability and watch the success rate move.
• Loop Engineering, the four guards that keep the loop inside your harness from running up a bill.
• New to the words? Start with the ten-word AI primer, then walk the AI Platform Masterclass.