You can take your agent’s success rate from 20 to nearly 100 percent with Harness Engineering.
Harness engineering means building the system that controls an AI agent. What it’s allowed to touch and see. And how you make sure the work is done right.
Harness Engineering applies to any AI agent doing real work on its own. A coding agent like Claude Code, a support agent, a deployment agent. You name it. Building a harness is normal engineering work.
It’s code designed to control an agent instead of running an app.
What are the elements of Harness Engineering?
A harness usually comes down to a few parts: permissions, context, memory, and verification.
Permissions decide what the agent’s allowed to do without asking. Usually a simple allow, ask, or deny rule for each action.
Context is what information it gets. Which files, tools, or past steps it can see.
Memory means it doesn’t forget everything between steps. A file or tracked list can be helpful since the model itself doesn’t hold onto anything. And verification is checking the work before calling it done. Tests or a separate check confirm the result is actually right.
Claude Code Example
A simple example of harness engineering is setting up permissions using Claude Code. By default, Claude Code checks with you before editing files or running commands. That’s fine. But it’s a blanket rule.
It doesn’t know the difference between something harmless and something that could break things. That control lives in a file called settings.json.
There you have rules for what’s automatically allowed, what it should always ask before doing, and what’s blocked no matter what.
Let’s add two simple rules.
- The first one is about creating a pull request. That’s a lower-risk action, so instead of blocking it, we’ll set it to ask first.
- The second is about git push. That’s the command that sends code changes to the shared repository, where the team, or even a deployment, would see them. We’re blocking that one completely.
{
"permissions": {
"ask": ["Bash(gh pr create:)"],
"deny": ["Bash(git push:)"]
}
}
Once it’s there, if the agent tries to push a change, it gets stopped immediately. That rule is a small piece of harness engineering.
We just decided what this agent can do on its own, what it has to check with us first, and what’s off the table completely. You also need to know that harness engineering costs more upfront. Anthropic ran a real test on this. They had an agent working completely alone. With no real harness around it.
The solo agent finished the task in 20 minutes for about 9 dollars. The project looked done, but it had a bug only visible after reading the code.
A second agent used a real harness. A planner, a builder, and a checker. It took 6 hours and cost about 200 dollars. More than 20 times as much. But it actually worked.
Another report found a coding agent’s success rate jump from 20 to almost 100 percent, just by adding a real harness. Different teams, with the same result.
Now, think about how your team ships regular software. You didn’t improve just by writing better code. You got reliability by building pipelines, staging environments, and rollback checks.
Harness engineering is that same idea, built for an agent instead of a person. Yes, harness engineering is more expensive. We just saw the numbers.
But skipping it seems more like a delayed bill and not a cheaper option. You pay for it eventually, either in the setup or even later.
If you’re now building anything with agents, this is where a lot of the work is. Not picking a model, but deciding what it can and can’t do.
