A Plan a Person Can Reject in a Minute

I run many client projects at the same time. AI agents, which are programs that carry out tasks on their own, do much of the work under my direction. The system I built to manage that is called HALO. Every pass of work in it, meaning one round of work on one task, starts with a written plan that a tool sets up before anything else happens. A session cannot finish a stage that has no plan, where a stage is one step in a larger job.

"Human in the loop" means a person checks the AI's work before it counts. In my system that person is me, and I read every plan before work starts. The plan is short and always the same shape on purpose, so I can read all of it and judge it quickly.

I've built for the web since 1994, and I do this work as a consultant or fractionally, never full-time. Everything here is how my system works as of late October 2026. The HALO manifesto covers the rest of how it runs.

Why does the human review sit at the plan, before work starts?

The review sits at the plan because a plan I can reject before work starts is the cheapest correction in my system.

Once work has run, I can reconstruct what happened, but reconstruction after the fact recovers a result and not a decision. The result is what the agents made, and going back through the record gives me that. Only the plan, read before anything ran, gave me the chance to make the decision.

You can test this in your own work. Take the last AI task that went wrong and ask where a person first saw the problem. If the answer is the finished output, the review sat at the most expensive point.

What fields does a plan someone can reject quickly have?

Every HALO plan has the same fixed fields: what the pass is for, what it rests on, the steps, the files it will change, what done means, what could make it wrong, the cost, the approval boundary, and the earlier mistakes that apply to its stage. Because the fields never change, I know where to look in every plan, and that fixed shape is what lets me read and judge each one quickly. I don't have to hunt through prose for the purpose, the evidence or the cost. Each sits in its own field.

What the pass is for fits in one sentence. If it needs a paragraph, it is two passes.

What the plan rests on is its evidence: file paths, command output, a prior record or a quote from the client. A file path is where a file sits in the project. Command output is what a program prints when it runs. An assumption with nothing behind it does not go in this field.

The steps come next, then the files the pass will change. A plan that cannot name its outputs cannot be verified, because there is nothing to hold the finished work up against. What done means is written as something checkable, never as a feeling.

What could make the plan wrong names the one or two assumptions that would waste the whole pass if false. The cost field gives the cost with its ceiling, meaning the most the pass may spend, or says none.

The approval boundary says who must review before anything in the plan has an effect outside the repository, which is the project's own set of files where work stays until it is published or sent. When nothing leaves the repository, the plan says "none" instead of leaving the field blank. I wrote about drawing those boundaries up front in my post on the approval map.

Why does a second AI model review some plans?

A second AI model reviews any plan that changes client copy, redirects or compliance records before the pass runs, and its findings go into the plan. I added that rule on 2026-09-16. A redirect is an instruction that sends a visitor from an old web address to a new one.

The case that prompted the rule: a review of one plan by a second engine found three blockers before any work ran. A blocker is a problem that would stop the plan from working as written. The same review run afterward would have cost a full re-run, meaning the whole pass done over again.

The second model's review doesn't replace mine. I'm still the human who reads the plan and decides whether the pass runs.

What stops a weak plan or a careless session from getting through?

Two checks hold work to the plan: one refuses a plan that skips past earlier mistakes, and one refuses file writes from a session that hasn't stated its intent. Each plan quotes the earlier mistakes that apply to its stage. Under each one, I or the agent must say in a sentence how this pass applies it. The check refuses the plan while any answer is blank.

On 2026-09-25 I added the second check, a gate that refuses file writes until the session has said what it intends to do. A session is one run of an agent at work. Once, a bug in how the gate recorded intent refused every write in one workspace. The refusal itself named the steps that were failing.

A gate that cannot be satisfied is worse than no gate. I fixed the bug and wrote down that a control that fails closed, meaning it blocks everything when it breaks, with no route through just gets switched off by the next person.

What checks the work after the plan is approved?

It depends on the kind of work. For a podcast episode, I'm the human at three points: I read and edit the script, I listen to the render, and I approve the push. The render is the finished audio, and the push is publishing it. For a long unattended run, where the agents keep working without me watching, the finish line is set by the other AI engine's review.

On those long runs I keep a ledger on disk, which is a list saved in a file, with one row per deliverable, each row being one piece the client gets. I build every row first and run the full checks once, at the end.

The lesson I wrote on 2026-09-28 says built is not done. A run is done only when the other AI engine has reviewed it and found nothing.

Common questions