Think / Essays

Check or go

The standard advice is to keep a human in the loop on everything an AI does. I tried that. It turned me into the bottleneck. Now I put myself only where it counts, and let the rest run.

3 min read

For the first few months of running my own AI agents, I approved everything. Every change, every draft, every small technical decision came to my inbox with a polite request for a yes.

It felt responsible. It was a mistake.

The system could produce far more than I could review, so the queue of things waiting for me grew every day. I had built a fast machine and then put the slowest part, me, in the middle of it. Anyone who has read The Goal knows what happens next. The whole line moves at the speed of its bottleneck, and the bottleneck was my attention.

The rule I use now

I wrote a one-line instruction for my agents, and it has done more for the system than any upgrade:

Reputation or money: check. Everything else: go.

If an action could put something public under my name, or touch my personal assets, the agent stops and asks. Once. Then it remembers the answer. Everything else, it decides and does, and tells me afterwards.

I’d add a third gate, borrowed from Jeff Bezos: anything that can’t be undone. A decision you can reverse in five minutes doesn’t need my opinion. A decision you can’t reverse needs it every time.

That’s the whole policy. Three kinds of decisions get a human. The rest get speed.

Why “human in the loop” is the wrong default

The phrase sounds safe, but it hides two problems.

The first is attention. If a person reviews everything, they stop reviewing anything properly. Approvals turn into reflexes. A gate that is always open isn’t a gate.

The second is responsibility. When the human checks every step, the system never has to get good at checking itself. I noticed I had become the one who found the mistakes, again and again. That isn’t oversight. It’s free labour for a system that should be catching its own errors. So the rule became: the machine finds its own defects before I see the work. I am the last line of defence, not the first.

What I do with the time I got back

The point of moving myself out of the loop wasn’t to do less. It was to do the parts only I can do.

I write the spec. The scarcest input in any AI workflow is a clear statement of the problem, the constraints and what “done” looks like. A vague request gets a confident, wrong answer. I spend more time on the first paragraph of a request than on reviewing the result.

I decide what matters. Agents are excellent at gathering, structuring, drafting and checking. They don’t know which of ten true things is the one my reader needs, or what to refuse.

I add the last twenty percent. Nothing goes out under my name until I’ve rewritten it and added a judgment only I could make. That includes this essay.

A short field manual

These are the working rules that came out of it. They apply to one person with a chatbot as much as to a fleet of agents.

  1. Spec first. Problem, constraints, definition of done. Then ask.
  2. The builder never grades its own work. A second model, or a second pass with a different brief, checks the first.
  3. Treat context as a budget. An agent that reads everything understands nothing. Give it what the task needs.
  4. Put the off switch where the work leaves. Guard the point of publishing or paying, not the place the request came in.
  5. Prune memory on purpose. What an agent remembers forever eventually misleads it.
  6. Every new tool is a maintenance bill. Count the upkeep before you celebrate the capability.
  7. “Unverified” is a task. Never let it sit as a status.
  8. Enforce rules in code. A policy the system can ignore will eventually be ignored.

The real lesson

Managing AI turned out to be a question of where to spend attention, which is the oldest question in management. A leader who signs off on everything isn’t in control. They are just in the way.

Check what can hurt you. Let the rest go.

These are my personal views, based on running my own system at home.

Written in Taipei. Last revised 10 October 2026 (revision 1).