There are two failure modes for tools that run coding agents, and they are mirror images.
The first is the autonomous demo: one sentence in, a merged pull request out, no human in the loop. It looks incredible for ninety seconds and then ships a migration that drops a column. The second is the babysitter: the agent asks permission for every file write, every shell command, every decision, until the human is doing more work supervising than they would have done typing.
Both come from the same mistake, which is treating “how much autonomy” as a single dial.
Separate the decisions from the actions
Most of what happens during an engineering change is action: edit this file, run that test, create a branch. Actions should run within authority you granted once, up front, as part of the project’s execution rules. Interrupting for them is noise.
A small number of moments are decisions: judgments where the outcome depends on context the agent does not have, or where being wrong is expensive and hard to reverse. Those deserve a human, every time.
For an ordinary engineering change we count two:
- Is this the right plan? After the PRD and task graph exist and before anything runs. This is where you catch the misread requirement, the task that should not exist, the dependency nobody noticed. It is cheap to fix here and expensive everywhere after.
- Is this ready to deliver? After verification, before a pull request is opened. You are looking at evidence, not at a promise, so the review is short. But the act of putting a change in front of your team is yours.
Make the first one optional, never the second
Plan approval can be skipped for missions you trust, on a per-mission basis. Some changes are routine enough that the plan is not worth reading. That is a judgment you make explicitly, each time, by passing a flag.
Delivery approval cannot be skipped. There is no setting for it. We considered adding one for CI-style use and decided that a tool which can open pull requests in your name without a human saying so is a tool you will one day regret installing.
Everything else goes to an inbox
Between those two gates, the crew will still have questions: an ambiguous requirement, a merge conflict, a provider that ran out of quota. These are decisions too, but they are not blocking decisions for the whole mission. They go to a decision inbox with a note on which dependent work is waiting. You answer them on your schedule, and the parts of the graph that do not depend on the answer keep running.
Steering is not interrupting
One more distinction. Sometimes you watch a task and realise it is heading the wrong way. You should be able to redirect it in place, with a sentence, without cancelling and restarting. The provider gets interrupted cleanly, the worktree is checkpointed, and the task continues with your note at the top of its prompt. That is you exercising authority, not the agent asking for it.
Two gates, an inbox, and a steering wheel. That is the whole design, and it is the one we would want for a human team as well.