The conversation around AI in software development tends to focus on the model — which one is smartest, which one writes the cleanest code, which one is cheapest per token. That focus misses something important. A raw language model cannot read your files, run your tests, or open a pull request. Everything useful that an AI coding tool does happens in the layer around the model. That layer has a name: the agent harness.
If you have used Claude Code, Cursor's agent mode, or any of the recent coding agents, you have used a harness. Understanding what it does — and what it does not do — is the difference between treating these tools as magic and using them effectively.
What the Harness Actually Does
A harness sits between the model and the outside world. It is responsible for everything the model itself cannot do on its own:
- Tool definitions. The harness exposes a set of callable tools — read a file, edit a file, run a shell command, search the web — and tells the model how to invoke them.
- Tool execution. When the model decides to call a tool, the harness actually runs it. It captures the output, enforces permissions, and feeds the result back into the conversation.
- Context management. Source files, prior tool results, and conversation history all compete for a finite context window. The harness decides what gets loaded, what gets summarized, and what gets dropped.
- Permission and safety. Which commands are auto-allowed, which require confirmation, which are blocked outright. The harness is where that policy lives.
- Loop control. The model takes a turn, calls tools, sees results, takes another turn. The harness runs that loop and decides when to stop.
None of this is glamorous, but all of it determines whether the agent is useful or frustrating.
Why the Harness Matters More Than the Model
Two teams using the same model can have wildly different experiences. The reason is almost always the harness.
Consider a concrete example. You ask the agent to fix a bug in a 200-file codebase. A weak harness dumps every file it touches into the context window, runs out of room after a dozen reads, and starts hallucinating function signatures. A strong harness uses targeted search, reads only the relevant slices, summarizes older tool results, and keeps the model grounded in real code throughout the task.
The model is identical. The outcome is not.
The same dynamic shows up everywhere: a harness with a good diff-based edit tool produces cleaner changes than one that asks the model to rewrite entire files. A harness that can run the test suite and feed failures back into the loop catches regressions the model would never notice. A harness with a sensible permission model lets a senior engineer move fast without exposing them to destructive surprises.
The Pieces of a Good Harness
If you are evaluating a coding agent — or building one — these are the parts that matter:
A Tight Tool Set
More tools is not better. Every additional tool adds tokens to the system prompt and gives the model more ways to get distracted. A good harness ships a small, well-designed set: a way to read files, a way to edit them precisely, a way to search the codebase, a way to run commands. Specialty tools earn their place by solving problems that the general ones cannot.
Diff-Based Edits
The difference between "rewrite this whole file" and "change exactly these lines" is enormous. Diff-based editing keeps changes reviewable, avoids accidental rewrites of unrelated code, and dramatically reduces the cost of long sessions. Any harness worth using has this.
Real Context Management
Context windows are large now, but they are not infinite — and stuffing them full is its own failure mode. A good harness prunes, summarizes, and reloads on demand. It treats the context window as a working memory, not a transcript log.
Permissioned Execution
A harness that runs anything the model suggests is a harness that will eventually delete the wrong directory. A harness that asks permission for every action is one nobody will use. The interesting work is in the middle: clear defaults, configurable allow-lists, sandboxes for risky operations, and obvious escalation when something destructive is about to happen.
Observability
When an agent goes off the rails — and they all do, sometimes — you need to see what it tried, what it read, and why it made the decisions it did. A harness without good logs and transcripts is a harness you cannot debug or trust.
How This Shapes Our Workflow
At Keitri, we treat the harness as part of the engineering environment, not a black box. We tune permission rules so the agent can run our test suites and linters without prompting, but cannot touch infrastructure config without confirmation. We invest in hooks and skills that encode our project conventions, so the agent does not have to rediscover them every session. We pay attention to which tools are getting called and which are not, and prune anything that adds noise without adding value.
The result is an environment where the agent feels like a capable junior engineer who already knows the codebase — not a chatbot we have to babysit. None of that comes from the model. All of it comes from how the harness is set up.
What This Means If You Are Evaluating AI Tools
If you are deciding which AI coding tool to adopt for your team, the model matters less than you think and the harness matters more. Ask different questions:
- How does it handle large codebases? Can it search and read selectively, or does it try to load everything?
- How are edits applied? Diffs or full rewrites?
- What is the permission model? Can you configure it for your team's risk tolerance?
- Can you extend it with your own tools, hooks, or conventions?
- When something goes wrong, can you see what happened?
The model under the hood will get better every few months no matter what you choose. The harness is what determines whether your team can actually use it to ship.