Surface the Decision, Don't 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, and noticing that is what this post is about.
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 stay honest 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 "need about ten resolved before this scores honestly" instead of a clean-looking hit rate computed from two data points. A two-sample win rate dressed up as a real number is a lie with a decimal place.
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, observed honestly, 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 |
So here is where the two jobs meet. A good advisor surfaces the decision and refuses to make it, draws its boundary in code instead of willpower, declines to assert what it has not verified, and proves itself on one case before scaling. Those are the rules for any system, human or machine, whose job is to inform a decision without owning it, and they hold from either chair.
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
Keep reading
I Don't Trust My Own Findings
The most dangerous result is the one you want to be true. Your own review is compromised by the same motivation that produced the finding, so the fix is a standing skeptic whose job is to refute, not confirm, before you act on anything.
Leverage by Subtraction
The instinct with agentic tooling is to add: more agents, more skills, more clever prompts. The leverage runs the other way. Here is the test I use to decide whether a piece of work should be a script, a hook, a skill, or an agent, and why most of them should not be an agent at all.
The archetypes split by time, not by person
Boris Cherny mapped five execution archetypes on the Claude Code team, and noted they cut across job titles. His framework describes a team dividing labor across people. Run a fleet alone and the same five split a different way: across your calendar and across the agents you have built. Here is which ones I keep in my own hands, which I time-slice, and which I pushed down into machinery.
Institutional Memory for a Team of One
A team holds its hard-won knowledge across many heads. A solo operator holds it in one, and that one forgets. The fix is to externalize memory into structured records the tools read by default, so the system remembers what the person cannot.
Building an AI-Native Platform: A Retrospective
A year of building and operating a small fleet of finance and content products almost entirely through an AI coding agent. What worked, what was hard, the honest failures (including a flagship signal that measured nothing and an edge that vanished net of costs), and the lessons that transfer.
Hello Again, Opus
Four days after I said goodbye to Opus, an export-control directive pulled Fable 5 offline and the fallback became the workhorse again. What I shipped in the window, what it cost, and the model-tiering plan for when Fable comes back.
Follow the work
New tools and writing as they ship — pick a channel.