Agent = Model + Harness
When you actually operate an AI agent, you hit a wall: swapping in a smarter model does not make it as stable as you hoped. Even with the same model, "the probability that it follows instructions" changes greatly depending on how it is configured. What produces this difference is the harness.
The core equation
If we write the idea this guide is built on in one line, it is this:
Agent = Model + Harness
It means that an agent (the entity that actually gets work done) is determined not by the model alone, but by the combination of the model and the harness. The harness here is a collective term for the mechanisms that surround the model. Concretely, it refers to things like the following.
- rules — standards you want followed (naming conventions, verification procedures, prohibitions)
- skills — commands with packaged procedures, like
/debug - agents — specialized subagents that handle review or refactoring
- hooks — scripts that run automatically at specific moments
- MCP — a set of tools that call out to external documentation or structured reasoning
- memory — a mechanism that retains lessons across sessions
- verification loop — a loop that verifies output before considering it done (the Verify step of
/debugactually runs the tests and treats the output as evidence that the bug is "fixed")
These are built on a division of labor where "Claude Code provides the mechanism (📦), and the user writes the content (🔧)" (for details on the categories, see the legend).
The model is the "engine," and the harness is the "chassis." However high-output the engine, a car cannot properly drive on public roads without a steering wheel, brakes, and sensors. An agent's reliability depends far more on the design quality of this chassis than on the engine's horsepower.
An LLM is essentially "a model that probabilistically predicts the continuation of the preceding token." It may get smart, but it does not follow instructions 100% of the time. Promises like "run the tests before saying you are done" or "do not hard-code secrets" also slip through probabilistically. The harness is a mechanism for structurally plugging these "probabilistic slip-throughs."
With a harness vs. without one
Let us compare the same request, with and without a harness.
Request: "Fix the bug in this function"
→ Produces a plausible-looking fix
→ Sometimes does not run the tests
→ Says "fixed it," but actually another spot is broken
→ Accidentally writes a secret key directly into the code without noticing
Request: "Fix the bug in this function"
→ The /debug skill launches and follows a procedure of forming hypotheses and verifying them
→ An always-loaded rule (the verify-first principle) is in effect, prompting test execution
→ A hook blocks writes to .env in advance
→ At the end of the response, the Stop hook inspects the output and makes it rephrase things like plain-prose questions on the spot
(Both of the above are illustrative thought experiments, not measured logs from the author's environment.)
The difference is not "whether the model is smart." It is the difference between hoping for good behavior and structurally enforcing it. Harness engineering refers to the practice of designing the latter.
Why this guide watches the "motion"
The relationships among the harness's elements do not become visible just by staring at configuration files. That is because the files in rules/, the scripts in hooks/, and the MCP tools are each placed independently.
However, the moment you run a single command, these fire in sequence and form one flow. From the next chapter, using /debug as the subject, we trace that chain of firings in chronological order. Before that, the next chapter establishes "what kinds of elements there are, and how to classify and grasp them for a clearer view."
The key points are as follows.
- An agent's reliability is determined by the harness's design more than the model (
Agent = Model + Harness) - An LLM follows instructions only probabilistically, and the harness compensates for that structurally
- Each individual setting is static, but at command execution time they chain together into a single workflow
Next, in The Guides-and-Sensors cross-classification, we learn a framework for organizing the harness's elements.