Claire Vo, who built a bug-triage harness for her company ChatPRD, offers a usefully plain definition of an AI harness. The important part is that the intelligence does not live only in the model. Some of it lives in the surrounding code that prepares the work, limits what the agent can do, and decides what it must leave behind.
A harness is some code around an AI agent. Yes, you heard it here first. A harness is just code around an AI agent that makes it more effective. Can that code have AI in it? Sure. Does that code have to have AI in it? Not necessarily. What is the goal of a harness? To make the AI better. It is so simple, and I feel like the way that people have been talking about this has made it such a mystery that I wanted to make it very clear to you all. It is just writing more code around your AI to make it more useful for a specific use case.
Vo’s threshold for building one is equally practical: look for work where the setup and expected result recur.
So what are the parts of a harness? Well, a harness is going to have specific context. It’s going to be able to take specific actions, and it’s going to have a goal of specific outcomes. It’s just as simple as that. And I want to talk about when it makes sense to build a harness and when it doesn’t. I think you’ll want to build a harness when the same workflow needs the same setup and the same outcomes. It’s really when there is a combination of deterministic and non-deterministic workflow, step-by-step process, tools, and use cases you want your AI to follow to do a specific job.
That turns harness-building into a design problem. The work is choosing the job, shaping the workflow, narrowing the tools, specifying the artifacts, and creating an interface through which a person can direct and inspect the system.
I identified a specific workflow. I determined what the run against the task would look like. I made very opinionated calls to tools or data sources. I didn’t just say, “Use an MCP,” although that could be part of your harness. What I did is make adapters that made the calls to these external APIs and tools very specific. I thought about what the structured artifacts out of that workflow might be. I decided what rules and permissions I wanted to give this harness and which ones I didn’t. I decided whether I wanted to use Claude Code or Codex or a model router to actually run these things. And then I built a surface to interact with this agent. It could be a TUI. It could be a CLI. It could be a web app. But I built some way to interact with this.
The model supplies capability. The harness makes a repeatable workflow legible and enforceable.
