Guides and Sensors: The Grid That Tells You Where Your Attention Goes
Guides and Sensors: The Grid That Tells You Where Your Attention Goes
Birgitta Böckeler's grid of guides and sensors, computational or inferential, used as a compass for deciding where a developer working with agents spends their attention, with examples from phax.
Part of the series: Attention Is All We Have · View all parts
Previously in this series: Attention Is All We Have
Thesis. Every piece of the harness fits in one cell of a four-cell grid: a guide or a sensor, computational or inferential. Progress means moving each judgement toward a computational cell, ideally before the code exists.
- An agent's harness has only two levers: steer before, check after.
- Each lever is computational or inferential, and only the computational one gives you your attention back.
- A computational sensor is only worth what it checks: it has to be kept apart from the one doing the work.
- An inferential sensor has a cost, and is only worth it for what no computational sensor covers.
- The next step is computational guides, which act before the code exists.
- As models improve, computational sensors stay and guides become a dial.
I don't read the code my agents write. For months I have had neither the energy nor the attention for it. I would hand the agent a plan, it ran it phase after phase, and I ended up in front of the result. The tests passed, and still it didn't work. I could see the error but not go in and fix it: the agent was my only pair of hands. I'd tell it "fix this", it did, and another error surfaced somewhere else. In the list of changed files, I didn't even know why a given file had been touched. So each error became a question: what would make the agent fix it, and stop this kind of error from coming back?
What helped me answer it was a grid. It comes from Birgitta Böckeler, in Harness engineering for coding agent users (martinfowler.com, April 2026), and I have used it as a compass ever since. She means the user's harness: what we put around the agent to steer and check it, as opposed to the vendor's harness, the loop and tools the model runs in. Every piece I added to phax fits in one of its cells. phax is the open-source orchestrator I build in public (on GitHub): it has an agent run a plan phase by phase, each in its own worktree, and commits a phase only when its checks pass. The comparison of phax with agentic practice lists them one by one.
An agent's harness has only two levers: steer before, check after
When the agent drifts, the reflex is to write a better prompt. That is one lever out of two. Böckeler calls them guides and sensors. A guide anticipates the agent's behaviour and aims to steer it before it acts: it works before the agent writes anything. A sensor observes after the agent acts and helps it self-correct: it works on what has been written.
A plan is a guide. So is a skill, a CLAUDE.md, a phase prompt. A gate that runs pnpm typecheck is a sensor, and so are a code review and an acceptance test. By gate I mean a quality gate: the checks a change must pass before it is committed.
Each lever is computational or inferential, and only the computational one gives you your attention back
The grid's second dimension separates what a program decides from what a model judges. A computational lever is deterministic and fast, run by the CPU: it answers true or false, and it gives the same answer every time. An inferential lever goes through a model: a skill it reads, a review it performs.
Two dimensions. A guide acts before the agent, a sensor after. Each is inferential, judged by a model, or computational, decided by a program. Inferential guides are a skill, CLAUDE.md, a plan the agent reads; a computational guide is a brief computed from the code. Inferential sensors are a review by a model or a person; computational sensors are the type checker, the linter, tests and fitness functions. Each practice moves a judgement toward computation, and the computational sensor is the optimum.
I learned it in the most expensive order. At first I had nothing but inference. Skills, detailed plans, architecture instructions, in the hope that the agent would follow them. Take a simple rule: the domain does not import the infrastructure. Written in a skill, the agent reads it. It follows it most of the time. On the fortieth iteration of a hard phase, with a saturated context, it imports an HTTP client from the domain because that was the shortest path to a green test. Nothing flags it. The rule is still in the skill, and I only find out when something breaks.
The same rule can live in another cell. It becomes a command, pnpm audit:architecture, which checks the boundaries between layers and fails if the domain touches the infrastructure. It goes into the gate profile. The project's very first phax.json, on 12 May 2026, already had it, next to pnpm typecheck, pnpm lint and pnpm knip. From then on, phax runs the command at every phase. If it fails, the phase does not commit: the failure goes back to the same agent session, which fixes it within its budget of attempts.
In the gate, the CPU carries it. After that, I locked down everything the language and the tools could check: the type checker in strict mode, the linter, the formatter, dead-code detection. Every rule moved from a skill to a gate is a kind of error that never comes back.
A computational sensor is only worth what it checks: it has to be kept apart from the one doing the work
A green gate says the commands pass. It does not say the commands check the right thing. And an agent allowed to edit its own tests has a very short path to green: edit the failing test.
phax took this problem from two ends. The first is reconciling what was planned with what was done. Since June, phax compares the files each phase actually changed with the files its plan announced (planned vs. done). Planned but not done, done but not planned, deleted, renamed: every gap is listed, and the agent has to justify it in its end-of-phase handoff. Looking at the list of changed files, I now know why each one was touched.
The second is acceptance tests written before the code, what the literature calls ATDD (acceptance test-driven development), which arrived at the end of October. One phase writes the tests that a later phase must satisfy. They are judged twice, by a provider you configure: first they must fail, since the code does not exist yet, then they must pass. The phase that writes the code does not touch the tests.
An inferential sensor has a cost, and is only worth it for what no computational sensor covers
That leaves the judgements no command can carry. Does the work respect the intent of the plan? Is the naming right? Is this the right solution? For those you need an inferential sensor: a model that reads.
phax has two. The compliance review, which arrived in June with phax review-compliance, reads the work against the plan and changes nothing. The headless code review, which arrived in October, runs in a read-only session. If the session changed anything in the worktree, phax puts the files back and refuses its answer. Both are optional per project, and each takes its own model and effort.
An inferential sensor costs tokens and time, and it can be wrong. If a model review spends its time flagging formatting mistakes, a formatter is missing from the gate.
The next step is computational guides, which act before the code exists
Computational sensors, even well separated, have one limit: they come after the code. The same is true of the fitness functions, in the sense of Building Evolutionary Architectures (Ford, Parsons and Kua), that I added next. A fitness function checks a characteristic of the architecture, automatically, on every change. The agent has already written the code, already spent its tokens, and the fix costs one more attempt.
I needed something that acts before, without relying on inference. It is the emptiest cell of the grid, the one where I struggled the most, and the one where I work now. phax put three things in it.
phax plans lint, in September, refuses a malformed plan before a run starts: a phase that edits a file no earlier phase creates, another that creates a file that already exists. Assignment bounds, in October, let the repository's owner hold certain files to a model and an effort range. A phase that departs from its bound without stating why is refused, by plans lint as well as when the run starts, before it has cost anything.
The third is the most important: a computational feed-forward, which phax calls the brief, arrived in October with phax brief. Before a phase writes, a brief provider computes from the code the guarantees that cover the files it is about to touch, with their state. The agent no longer receives a generic skill about architecture, and the gate will check the same guarantees afterwards.
As models improve, computational sensors stay and guides become a dial
One objection keeps coming back: models are getting better, and all this harness will become useless. Anthropic says as much: every component in a harness encodes an assumption about what the model can't do on its own (Harness design for long-running application development). Their own harness dropped pieces as the models improved.
The grid says which ones. A gate encodes no assumption about the model. It encodes what the change has to pass. A better model passes it more often, so it costs fewer attempts. And a model that is better at its work is also better at fooling a weak sensor, which is one more reason to keep the judge apart from the one doing the work.
Guides, on the other hand, become a dial. How much the plan spells out, which model runs each phase: these are choices that change with the models and their prices. A very detailed plan, written once by a strong model, can let a cheaper model run the phases. A lighter plan leans more on the gates and the fix loop.
What the grid does not tell you
The grid sorts practices. It does not tell you what to put in them. Knowing which architecture rule is worth computing is still your job.
Nor does it say when a sensor is written. Its before and after say when a lever acts, not when it was put in place. The rules of the type checker and the linter are set before, and an acceptance test is by definition: it is a contract, and the code could not shape it. Unit tests are written during, and often fitness functions too, because things have to be in place before you can write them. Once validated, they hold for the phases that follow. But when they are born, they can fit the code instead of judging it. The strongest sensor is the one you contract before the code is written.
The same grid, its computational sensor split by when it is written. Written before the code, it is a contract the code must pass and could not shape: type and lint rules, acceptance tests; this is the strongest. Written with the code, it can fit the code instead of judging it: unit tests, and often fitness functions.
The cells are not watertight. A spec is an inferential guide, since the agent reads it, but a person approved it, and phax records what it was approved against. I don't know yet how much of our judgement will end up computed.
For every judgement you still carry by hand, ask which cell it could move to.
A thought after reading?
If you would like to discuss about this article, you can write to me here. I share because I care and I want to learn. Please teach me with care.