Todd Stuvé ‹ all explainers

Beginner guide

What is a harness?

The word sounds technical. The idea is not. It is the single most useful concept for understanding why one AI assistant feels brilliant and another feels useless, even when both run the same AI.

A harness is just code wrapped around an AI that makes it better at one specific job.

Claire Vo, on her show How I AI

That is the whole thing. Not a framework, not a product, not a buzzword. Code around an AI.

And here is the part that surprises people: that code does not have to contain any AI of its own. A plain rule that says "never touch the production database" is part of the harness. So is the checklist the AI reads before it starts. So is the report it has to fill out when it finishes.

Plain-English decoder. A model is the AI itself, the thing that reads and writes. An agent is a model that can actually do things: read files, search the web, run programs. A tool is one of those things it can do.

The other definition

Take an agent. Remove the model.

Whatever is left over is the harness. Mike Chambers of AWS puts it that way, and it is the same idea approached by subtraction.

Agent equals model plus harness A box labeled Model, the raw brainpower, plus a box labeled Harness, everything wrapped around it, equals a box labeled Agent, something that gets work done. Model raw brainpower the engine + Harness everything around it the rest of the car = Agent gets work done a car you can drive
An engine on a garage floor goes nowhere. Bolt it into a car with a steering wheel, brakes, a dashboard, and seatbelts, and now you can drive somewhere.

The word itself is borrowed. The dictionary says a harness is a set of straps and fastenings used to control an animal. Swap the word animal for the word model and the definition still works. A workhorse is pure power with no direction. The harness does not make it stronger. It connects the horse to the cart, points it where you want to go, and stops it wandering into the road. Same animal, completely different outcome.

Where the two definitions disagree, and it is fine. One says code wrapped around the agent. The other says whatever is left when you take the model out of the agent. The boundary moves depending on who is talking. You will hear both. Neither is wrong, and noticing the difference means you understood, not that you missed something.

Open the box

What is actually inside one

Eight parts. You already use most of them without calling them by these names.

Memory

What it remembers between conversations, so you do not re-explain yourself every morning.

Tools

The things it can reach for. Narrow beats broad here.

Claire Vo's bug-triage harness (How I AI) skips a general connection to the error tracker. The adapter pulls exactly the handful of fields a bug report needs, so it never wanders through thousands of traces.

Rules

Written instructions it reads every time. How you like things done. What never to touch.

Skills

Step-by-step playbooks it loads only when a task calls for them, so nothing gets wasted.

The loop

The cycle of think, act, look at the result, try again, until the job is finished.

Guardrails

Hard stops it cannot talk its way out of, because they run outside the AI.

Her harness has an investigate-only mode. Not "please do not edit my files" as a request. The harness structurally cannot write code in that mode.

The sandbox

The fenced yard it plays in. Limits the damage when something goes wrong.

Watching and grading

Seeing what it did, and scoring whether it was any good. The part almost everyone skips.

Why anyone should care

The harness decides more than the model does

This is not a hunch. It shows up on the scoreboard.

Bottom 30 to top 5

One team moved their coding agent from outside the top thirty to the top five on a public benchmark by changing only the harness. They did not change the model. Same AI, better wrapping, ten times the rank.

Terminal Bench 2.0 · via The New SDLC With Vibe Coding

The everyday version. Two people use the exact same AI. One gets sharp, useful work. The other gets confident nonsense. The difference is almost never the model. It is what got wrapped around it.

The practical payoff

When the AI fails, do not blame the AI

Most agent failures are configuration failures. Something in the harness was missing, vague, or full of noise.

Check the harness first

  • Did it have the tool it needed for this job?
  • Was the rule clear, or was it vague?
  • Was there a guardrail to catch this, or none?
  • Was it drowning in irrelevant context?
  • Did anything check the answer afterward?

The reflex to resist

  • "This model is dumb, try a different one."
  • "Let me rewrite the prompt one more time."
  • "I will just paste in more context."
  • "The new model comes out next month."
  • "It sounded confident, so it is probably right."

One word, two situations

The agent you use, and the agent you build

Mike Chambers of AWS draws this line, and it clears up most of the confusion around the word.

1

Agents you use

Claude Code, Cursor, and the rest. Here the harness is memory, your rules file, the tools you plug in, and your team's standards. Coding standards have existed for decades. Now teams have harness standards too.

tune it however you like
2

Agents you build

Everything above, plus the hard parts: running the loop at scale, identity, payments, isolation between customers, and the grading. Chambers puts watching and grading last on his slide and says it should be first.

think carefully, people depend on it

The line worth remembering. The model of the month changes every few weeks. If you believe your advantage is which model you picked today, you will lose it by winter. The harness is the part that lasts.

The decision

When is it worth building one?

The test is simple. Build a harness when the same workflow needs the same setup and produces the same outcomes, over and over.

Build one when

  • You do this job repeatedly, the same way each time
  • It mixes fixed steps with real judgment
  • You always want the same thing produced at the end
  • You keep re-explaining your intent to the AI
  • You want to be prescriptive, even micromanaging, about how it gets done

Do not bother when

  • The job is one-off or exploratory
  • Every run looks different from the last
  • The whole thing is deterministic, in which case write a script
  • A general-purpose assistant already gets you there
  • You cannot yet describe the workflow on paper

The everyday tell, Claire Vo's example. With a general assistant you write "please look at this bug, here is the link, and remember to file a ticket afterward" every single time. With a harness you paste the link. It already knows the job, the tools, and what you want at the end.

Closer to home

You have already built one

HQ passes the test exactly. Same workflow, same setup, same outcomes, every session.

The rules file

CLAUDE.md is read at the start of every session. It is the standing instruction set: how to talk to you, what never to touch, when to delegate.

The memory

Four layers, each with a job. Auto-memory for facts that must survive anywhere. gbrain for searching. Vault files for reading. Instructions for following.

The skills

Tailor, session-handoff, storm-research. Playbooks that load only when the task calls for them, so the everyday sessions stay cheap. These get invoked and trusted.

The guardrails

The em dash gate. The check that reads the shipped file, not the draft. Nothing publishes without your yes. These are code, so they fire whether or not anyone remembered them.

Why this matters for the pitch. Harness engineering is the vocabulary for the thing you already do every day. Most people who want to hire an AI builder cannot name it yet. You can name it, and you can show the receipts.

Once the word stops being mysterious, it starts showing up everywhere. Cursor is a harness. Claude Code is a harness. Every tool anyone has wrapped around an AI over the last three years is one, whether or not the builder used the word. Claire Vo closes her episode on exactly this note: the skill was never exotic. Wrap enough structure around a model that it does one job well, every time, and hand a human a decent way to drive it.