The Two-Brain Rule: When to Trust the Agent and When to Check

Agent trust is a spectrum, not a binary. After two years I have a simple rule I call the two-brain rule that decides when I verify output and when I let it ship. It has kept me out of trouble on client projects more times than I can count.

The Rule

Before accepting agent output, ask two questions:

Could I verify this is correct in under thirty seconds?
If it is wrong, what is the blast radius?

Cross the answers in a two-by-two grid:

Fast to verify, low blast radius: ship without checking
Fast to verify, high blast radius: always check (quick cost, big payoff)
Slow to verify, low blast radius: ship, catch in review or tests
Slow to verify, high blast radius: stop, decompose, or run the work yourself

The fourth quadrant is where projects burn. Big decisions that are hard to verify should not be delegated to agents without decomposition first.

Examples in Practice

A CSS tweak: fast to verify, low blast. Ship.
A database migration: slow to verify, high blast. Decompose into read-verify, then write.
A commit message: fast to verify, low blast. Ship.
An auth refactor: slow to verify, high blast. Stop and design first.

The rule does not say do not use agents on hard problems. It says do not accept agent output on hard problems without a verification plan.

The Verification Plan

For fourth-quadrant work, I write a verification plan before the agent starts. Concrete checks, in order, that I will run on the output. The plan constrains what the agent produces, because the agent sees the plan in context and shapes output to pass it.

Where This Came From

The rule crystallized after an agent-generated migration script deleted a production column silently. The bug was fast to write, hard to verify. I had not asked either question. The fix was not better agents. It was better habits.

The Pushback

Some readers will say this slows you down. It does, for about a week. Then it becomes reflex and actually speeds you up, because the fourth-quadrant disasters stop eating afternoons. The cost of verification is always smaller than the cost of unverified work in production.

Nassim Taleb's writing on asymmetric risk points at the same underlying math, framed differently.

The Team Adoption

When I introduce this rule to client teams, it sticks faster than any other agent-era habit I teach. Engineers already intuit blast radius. Putting a name on verification speed completes the picture. Two questions, fifteen seconds of evaluation, a shared vocabulary that scales across the team.

The Honest Admission

I still get the quadrants wrong sometimes. I still ship a fourth-quadrant change under time pressure and regret it. The rule is not perfect. It is meaningfully better than no rule, and the bad outcomes have become rare enough that the rule has earned its keep.