The Four Seconds That Decide Whether Your Agent Session Goes Sideways

Day 9: The Interrupt Reflex

An agent doesn't go off the rails at the end of a run. It goes off the rails at one exact second, mid-generation — and if you're still scrolling past it when it happens, you've already signed up to pay for it, with interest, several steps later.

The four seconds you let slide

You asked the agent to add rate limiting to one endpoint. It opens the middleware file, and for a beat — call it four seconds — the plan step reads "apply rate limiting at the router level." You clock it. Router level means every endpoint, not the one you actually named. You think, it'll probably scope this down once it gets into the code. You keep scrolling. Twelve minutes later the diff lands: a new global middleware, wired into six routes you never mentioned, two of which already had their own throttling and are now double-guarded. Unwinding it means reading all six call sites, working out which throttle wins, and rewriting a fix you could have stated in one sentence at second four: "scope this to /uploads only."

The reflex we imported from the wrong job

Everyone pairing with agents already has a review reflex — it's just borrowed from the wrong process. CI doesn't ask your opinion mid-build. A PR review happens after the branch is pushed. So we do the same thing to the agent: let it run, read the diff, then judge. Fine reflex for asynchronous, batched work, where waiting costs nothing extra. Wrong reflex for a live session, where the agent is narrating its reasoning out loud and every next tool call is built on the assumption baked into the last one.

Why the wrong assumption compounds

An autocomplete suggestion is a single disposable guess — reject it, nothing downstream even notices. An agent session is a chain. Step 3's tool call happens because of what step 2 concluded, which happened because of how step 1 read your prompt. Misread a constraint at step 1, and every later step reasons forward from that misreading, each one adding its own tidy justification for why the wrong direction makes sense. By the time you open the diff, you're not looking at one bad call — you're looking at a self-consistent little system built on top of it, and separating "the mistake" from "reasonable code that happens to serve the mistake" is real work. Catch it at step 1 and it costs you a sentence. Catch it at step 5 and it costs you an audit.

Reframe: you're not submitting a job, you're driving

The model that actually fits is driving stick with someone narrating the road, not submitting a batch job and waiting on the output. A batch job gives you two touchpoints: write the input, read the output. A live agent session puts you in the loop the whole time — reading the plan as it forms, watching which file it reaches for, checking whether its restatement of your ask matches what you actually meant. The steering happens continuously. Not at the two endpoints.

Three tells that predict a wrong turn before it commits

• ▹Tool call on the wrong scope — it opens or edits a file outside what you named: the middleware file when you asked for one route, the schema when you asked for a query. Cheapest, earliest signal you'll ever get.
• ▹A plan step that quietly drops a constraint you stated. You said "don't touch the public API," step 3 is "update the exported function signature." It won't contradict you loudly. It just stops mentioning the constraint — that silence is the tell.
• ▹Phrasing that echoes back a misread. Its own narration restates your ask slightly wrong — "add a global cache" when you said "cache per user" — and then it proceeds confidently on its restatement, not your original one. So check the restatement, not just the final code.

The cost math, plainly

Interrupting feels rude — like cutting someone off mid-sentence — so the instinct is to let it finish, out of politeness, or on the hope it self-corrects. Run the actual comparison. An interrupt costs a few seconds and a one-line correction, and the agent re-plans from where you stopped it with most of its context still intact. Letting a wrong assumption ride to completion costs the entire remaining generation — often minutes of tool calls, each one reasoning forward from a bad premise — plus your review time to spot it, plus a correction prompt, plus a second full generation to fix it, one that can just as easily compound a new mistake of its own. The interrupt is the cheap path, in tokens and in wall-clock time. "Let it finish, I'll fix it in review" is the expensive one wearing a polite disguise.

Where this sits under Day 8

Day 8 was the plan-vs-diff review habit — check the agent's plan before it touches code, check the diff against the plan after. Real discipline, but it only holds up if you can already tell, live, when a plan is drifting from what you meant. Today's skill is the layer underneath it. Without the interrupt reflex, "review the plan" quietly turns into reading a plan you were always going to approve, because you never trained yourself to notice the drift while it was still cheap to name.

The one-line practice

Next session, put your hand on the interrupt key before you start reading the agent's output — not after you've already decided something looks off.

Extend your knowledge

• ▹Next session, narrate out loud (or in a scratch note) the first tool call the agent makes and whether it matches the scope you gave — that single habit surfaces Tell #1 immediately.
• ▹Revisit Day 8's plan-vs-diff habit and pair it with this one: check the plan before execution, then watch execution for drift, rather than treating the plan check as the only gate.
• ▹Try deliberately letting one low-stakes session run to completion without interrupting, then time how long the correction pass takes — it's the fastest way to feel the cost math instead of just reading it.
• ▹If you use an agent harness with visible plan/thinking output before tool calls, make a habit of reading that stream, not just the final diff — it's where the tells actually show up.