Checkpoint, Don't Hover

The Build Loop, same as every rung — spec, direct, checkpoint, verify. This time we're sharpening the third turn: the moment the work pauses and comes back to you.

You already know how to supervise work you didn't do yourself. You've reviewed a colleague's deck without rebuilding it slide by slide. You've run a check-in that catches a project drifting without sitting in on every working session. Somewhere between rebuilding it yourself and the drive-by glance, you long ago found the supervision distance that actually works.

Then you start directing an agent, and you lose it — almost everyone does, in one of two directions. Either you hover, watching every step scroll past, ready to pounce, which makes you the bottleneck and defeats the point of delegating. Or you gate: let the agent run and click "approve" at the end, which turns you into a rubber stamp. I did the second for weeks. My checkpoints were a yes/no question — "done, continue?" — and here's the embarrassing part: a yes/no question, asked often enough, trains you to stop reading before you answer it. The gate was there. My attention wasn't.

Ask a better question than "proceed?"

The fix wasn't more supervision or less. It was a different question at the pause.

A gate asks: do you want to proceed? A decision point asks: how do you want to proceed? That one word changes everything. Instead of stopping the agent to approve what it's done, you stop it to choose what it does next — from a few real options it lays out for you. Apply everything as-is. Narrow to just these files. Revise this part and re-run. Go back and show me the source material first. Your choice doesn't just allow the next step — it shapes it.

And notice what that does to the attention problem I just confessed. A gate you can answer without reading. A fork you can't. The structure of the question does the work your willpower was failing to do — you can't pick between four real options without actually looking at what's in front of you.

This is a skill you've used for decades

I didn't get this from research literature — that's what an engineer would do, and I'm not one. I got it by noticing a pattern across unrelated corners of my own work and putting them together into something none of them held alone. That's not computer science. It's the cross-domain pattern recognition you've used for years in strategy, positioning, running teams — the thing you were told wasn't "technical."

The only difference now is speed. For years, you could see a pattern instantly and then wait weeks for someone to build it — by which point the insight had been filtered through planning cycles into a diluted version of itself. Now the insight, the design, and the brief that directs the build can happen in one sitting. Your design arrives at the build undiluted. That's the payoff worth keeping: a thing you conceive before lunch can be a buildable spec before you stand up.

One warning, learned the useful way: when you make a leap like that, don't let the agent applaud it — make it argue. Ask directly: are these options too vague to tell apart? Is this more complexity than the job can carry? Your lived insight can genuinely collide with a real constraint, and you want that collision at the design table, not three builds later. Respect the pushback more than the agreement — and say so in the spec.

Keep the decisions, not just the output

Here's the quiet second prize. Every fork you take is a decision with a reason attached — and if you have the agent write each one down as it happens, you get a decision log: a plain-text record of what was chosen, when, and why. You already keep something like this after a steering meeting. Now it writes itself.

The log outlives the session, and that's the point. Next week, when you wonder why the tool skipped half the files, the answer is written down, not reconstructed from memory. Next month, a new build inherits your past judgment instead of re-asking settled questions. The deliverable was never just the output. It's the output plus the trail of decisions that shaped it — and now you reliably get both.

So: don't hover, don't rubber-stamp. Design the pauses so each one puts a real decision in front of you with the reasonable options already laid out, and capture what you chose. Decisions at checkpoints, not approvals at gates.

→ The companion — In Tropo: Your First Checkpoint — has you turn a yes/no gate into a real decision point, and start a decision log that writes itself.

Power Play

Make the agent design its own checkpoints. Before it starts a build of any size, ask:

"Before you begin, tell me the two or three moments in this build where you'll hit a decision I might make differently than you would. At each one, stop and give me the real options — not 'continue?', but the actual choices, in plain language."

Now the pauses land exactly where your judgment matters and nowhere it doesn't. You've delegated the placing of the checkpoints while keeping every decision at them — which is the whole art of supervising work you didn't do.

Terms worth knowing

• Checkpoint — a pre-set point where a build pauses and waits for you before going on.
• Gate vs. decision point — a gate asks yes/no ("proceed?"); a decision point offers real options ("how?") and your choice steers what happens next. This rung is about turning your gates into decision points.
• Decision log — a running record of the choices you made at checkpoints, with the reasons. Keep it as a plain file the agent can add to and read back later.
• Human-in-the-loop — the industry's term for any system built to pause for human judgment at set points. Everything in this rung is a way of doing it well.