Why an agent tool should surface the decision, not make it
In a single working session this week I did two jobs without noticing they were the same job. I designed a read-only advisor: a morning ritual that reads my private trade journal, ranks what actually needs a call today, scores how well past calls have held up, and hands the decision back to me untouched. And for most of that same session I was the customer of an advisor myself, leaning on a stronger reviewer model to check my work before I shipped it. Building one and being advised by one ran on the same short list of rules.
The lead idea is restraint: a trustworthy advisor surfaces the decision and never seizes it, a boundary worth enforcing in code rather than trusting to good intentions. The companion disciplines are the ones I rely on when I am the one being advised: verify before you assert, pilot before you fan out, and say so when the evidence is thin.
The advisor that refuses to act#
The structured output I already had was precise but dense. Numbers, ratios, a rank delta. Correct, and exactly what you want underneath a decision, but it failed at two jobs: it never said in plain English what mattered this morning, and it threw away the story sitting in the journal about whether the past calls were any good.
So the advisor layer adds three pieces on top, without removing the precise data underneath. A plain-English lead (a one-sentence bottom line and a single "look at this one" pointer). A ranked priority triage that sorts what is true right now into CRITICAL, WARN, and INFO. And a calibration scoreboard that grades the track record: how often the forecasts hit, whether they were over or under confident, whether the book is sized to conviction.
The hard rule sits underneath all of it. The advisor speaks only in framing verbs ("decide today", "resize or restate", "pre-decide the exit") and never a trade verb. It tells me a position broke a line I drew. It does not tell me to sell it. It surfaces the decision and leaves the decision to me. That is the whole posture, and it is the same posture the reviewer model took with me all session: it saw exactly what I had done and told me where it was weak, and it never once had its hands on the merge button.
A boundary you enforce, not remember#
A rule that matters cannot live in the author's good intentions, because the day it matters most is the day someone is moving fast and forgets it. So the read-only boundary is backed by a test: a list of trade verbs that must never appear in any rendered line of priority, bottom line, or scoreboard. Cross the line in a template and the build goes red. The advisor cannot accidentally start giving orders, because the suite refuses to let it.
This is the same reason the reviewer I leaned on is safe to lean on. It is wired to comment, not to commit. It reads the full context and pushes back hard, and the irreversible actions (the merge, the deploy) stay behind a gate it does not control. An advisor with its hands tied to suggestion is more useful, not less, because I can take its push at face value without wondering whether it is about to do something I cannot undo.
Verify before you assert#
The most dangerous advisor is the confident one that has not checked. So the scoreboard refuses fabrication: every statistic carries a sufficiency flag, and on a thin sample it prints a "need about ten resolved" notice instead of a clean-looking hit rate computed from two data points.
I was making the identical move from the other chair an hour earlier. The assistant had added diagrams to a batch of posts, and the check I cared about was not "did the build pass." A diagram renders at view time, so a green build proves nothing about whether readers see a picture or a broken box. The real check was to render each one and look at it, in both the light and dark themes, before trusting it.
Pilot before you fan out#
The advisor surfaces one "look at this," not a wall of forty flags. One question per ritual, one written answer. The restraint is the feature: a single forced decision at the moment it is cheap to make beats a dashboard that asks nothing of you and gets ignored.
The same instinct ran the session. Before changing six posts I changed one, rendered it, and looked, and only then committed to the other five. Prove the pattern on a single case under real conditions before you spend the effort to repeat it. Whether you are an operator triaging a book or an agent editing a fleet of files, the cheap insurance is the same: one pilot before the fan-out.
Two sides of the same rule#
The parallels line up cleanly:
| Building the advisor | Being the one advised |
|---|---|
| Surfaces the decision, never seizes it | The reviewer comments, never holds the merge button |
| Refuses to compute a stat on a thin sample | I render and look before I trust a diagram |
| One "look at this" per ritual | One pilot before fanning out to six |
| Read-only boundary enforced by a test | Irreversible steps gated by process, not memory |
Related:
- I don't trust my own findings, the verify-before-you-believe half, from the skeptic's side
- Leverage by subtraction, why the boundary belongs in a test and not a person's memory
- Autonomy is mostly knowing when to stop, the same restraint applied to an autonomous loop