Birgitta Böckeler, writing about harness engineering at Thoughtworks, draws a distinction that turns out to be more useful than it first appears: a harness contains guides and sensors. Guides point the agent toward correct behavior up front. Sensors catch the agent after the fact, when it has produced something that does not meet the bar.
Most teams that adopt agents at scale eventually invest in one of these and neglect the other. The neglect produces predictable failure modes. Naming the two categories explicitly is the first step to balancing them.
Guides
What I've been calling "guidelines" in previous articles
A guide is anything in the harness that shapes what the agent does before it produces output. Rules files. Example code in context. Skills and slash commands. Style guides referenced in CLAUDE.md. The repository's own existing code, which the agent reads as a source of patterns. All of these are guides; they all do the same job, which is to load priors into the agent's session that bias it toward the behavior the team wants.
Guides are cheap to add and easy to over-invest in. The marginal cost of a new rule is one sentence. The marginal value can be high (a well-placed rule prevents an entire class of mistake) or zero, if the rule duplicates something the agent already knew or wanted to do anyway.
The failure mode of a guides-heavy harness is rule fatigue. The file gets long. The agent loads everything, weights none of it, and starts ignoring the parts that conflict with its training. The team observes that the rules "stopped working" and adds more rules. The cycle continues until the file is unreadable and the agent's behavior is no more controlled than it was at the start.
A team that lives on guides is a team that has not yet discovered that guides have a ceiling.
Sensors
What I've been calling "guardrails" in previous articles
A sensor is anything in the harness that detects, after the fact, that the agent has produced output that does not meet the bar. Linters. Type checkers. Tests. Audits. CI checks. Static analysis. Code review, in its automated and semi-automated forms.
Sensors are more expensive to add than guides (a new test or a new lint rule takes more thought to write than a sentence) and more durable. A sensor does not depend on the agent reading it. The sensor runs regardless. The agent's response to a sensor is feedback-driven: it produced code, the sensor flagged it, it fixed the code. The loop is mechanical.
The failure mode of a sensors-heavy harness is the long loop. The agent writes a hundred lines, the test suite takes three minutes to run, the failure is at the bottom of a verbose log, and the agent has to context-switch back to a task it has half-forgotten. Slow sensors do not stop the agent; they just make every iteration expensive. A pipeline that runs in two minutes is a different harness from a pipeline that runs in twenty.
A team that lives on sensors is a team whose agents are accurate but unpleasantly slow.
Why each fails alone
A guides-only harness fails because guides are non-binding. The agent might follow the rule. It might not. It might follow it in 90% of cases and silently violate it in the 10% that did not pattern-match to the rule's example. Without a sensor to catch the violation, the team finds out about it in production, or in a code review where the reviewer happens to know the rule. This is the same failure mode as a style guide nobody enforces.
A sensors-only harness fails because sensors give late, expensive feedback. By the time the linter complains, the agent has already produced the wrong code; it now has to undo and redo, which costs time and tokens. More importantly, sensors do not tell the agent what should have been produced. They only say what should not. An agent caught by a sensor still has to guess at the correction, often badly, often producing a second sensor failure of a different kind.
The two together cover both gaps. The guide tells the agent what to aim for. The sensor catches when it misses. Neither is sufficient. Both is the minimum.
Which one your team is short on
The diagnostic is usually obvious once you look for it.
If your team's complaint about the agent is "it knows the rule but does not follow it," you are short on sensors. Add a check that mechanically fails when the rule is violated. The rule becomes binding when the build fails.
If your team's complaint is "the agent writes correct code that fails review because it did not know the convention," you are short on guides. The convention exists in someone's head, or in a wiki, or implicitly in the codebase. It is not in the file the agent reads at the start of every session. Move it.
If your team's complaint is "the agent is slow," and you have a long pipeline of sensors, the sensors are the problem. Make them faster, or move some of them out of the inner loop and into post-merge.
If your team's complaint is "we have rules and tests and it still produces garbage," something deeper is wrong, usually the rules are aspirational and the tests are weak. The diagnostic for that is a separate problem.
How to balance them
A useful rule of thumb: a new constraint should generally enter the harness as a sensor first and a guide second.
The sensor is what makes the constraint binding. The guide is what makes following it natural. A constraint with only a guide is a suggestion. A constraint with only a sensor is a wall the agent keeps walking into. A constraint with both is a path with a fence: the agent follows it because it is the obvious way, and the fence catches the rare miss.
This is, in essence, the same architecture as a well-run engineering team. The conventions are written down (guides). The tools enforce the important ones (sensors). The team learns the rest from the inevitable corrections. Agents are no different. They just go through the loop faster, which means the cost of imbalance is also faster.
The work, in either case, is to keep both sides funded. Most teams discover by attrition that one side has been quietly neglected. Naming the two categories makes the neglect visible.
Top comments (0)