Start with the failure mode, because it is what the design is for.
An agent with permission to act does something plausible and wrong. It emails a journalist with the wrong name. It publishes a post quoting a price you changed last month. It marks a task complete and moves on, and the artifact behind it does not exist. None of these are exotic — they are the ordinary output distribution of a language model given a send button.
Now ask who is accountable. Not the model. The person whose name and domain it went out under, who did not see it, and who in most jurisdictions is legally responsible for it. That gap between who acts and who answers for it is the actual problem, and no amount of model quality closes it, because the gap is structural rather than probabilistic.
The boundary is not a setting
The tempting version is a checkbox: "require approval for outbound actions", default on, switchable off for power users.
That is not a boundary, it is a preference, and it fails the only test that matters — whether there is a code path that reaches a send without a human decision. If there is, then the boundary is a UI convention, and every incident report will start with the sentence "the setting was off".
A real boundary is architectural. In our case there is exactly one route that lets work leave the building, and it is the approval route. Nothing in the agent loop — snapshot, decide, execute, brief — can send, post or spend. The loop's terminal state is a draft in an inbox. That is a constraint the code enforces, not a policy we intend to follow.
What it changes underneath
This is the part that gets underestimated. Adding an approval step is not adding a step. It changes four decisions.
You charge at approval, not at attempt. If work waits for a decision, you cannot bill when the work is produced, because most of what you produce might be rejected. So the charge moves to the approval, which is also the only honest place for it — the alternative is billing people for output they looked at and declined. Once the charge sits at approval, a failed generation costs the user nothing by construction rather than by refund policy.
Execution has to be idempotent. Approvals get double-clicked, retried on a flaky connection, and resumed after a timeout. Charging on the approval path means a duplicate approval is a duplicate charge unless the spend is idempotent at the database level. Ours goes through a single Postgres function that will not bill the same attempt twice; the naive version of this is a support queue.
Every completion claim has to resolve to an artifact. An inbox creates a promise: this is what I did. If a line in the log says a post was drafted, clicking it has to open the post. This sounds obvious and is the single most commonly broken property in agent products, because it is much easier to record that a step ran than to record what it produced. Typed references from the action to the artifact are what make the log a receipt instead of a narrative.
The quality bar goes up, not down. A draft nobody approves is wasted compute, so the incentive flips: it is cheaper to bin weak work than to surface it. That means a quality floor that rejects output — and then, unavoidably, telling the user it happened. "I drafted this, it did not meet my bar, I binned it, no credit touched" is a strange sentence to design toward and a much better one to receive than a silent gap.
What it costs
Honestly:
- You cannot make the big claim. "Wakes up and runs your business" is not available to you. That claim sells, and you are choosing not to make it.
- Latency becomes a product problem. Work sits between prepared and executed for an unbounded time. Anything time-sensitive has to survive going stale, or expire honestly.
- You build an inbox. An entire surface — states, batching, expiry, skip-tracking — that a fire-and-forget agent does not need.
- Approval fatigue is real and is your fault if you cause it. An agent that asks about everything trains people to click yes without reading, which is worse than no gate, because now there is a record of consent that means nothing. The defence is asking less: fewer, better-formed decisions, and a cooldown when someone keeps skipping a suggestion type.
What it buys
The agent is allowed to be wrong. This is the whole return. A system where mistakes are caught before they are externally visible can take real swings, because the cost of a bad draft is a rejected card. A system that acts directly has to be conservative to be safe, which makes it less useful — the interesting suggestions are exactly the ones you would not let it send unsupervised.
Liability stays where the law already puts it. The person responsible is the person who decided.
Trust becomes checkable rather than asserted. "Nothing ships without your approval" is either true of the code or it is not, and anyone can test it in an afternoon. Compare that to "enterprise-grade safety".
What we do not know yet
This is a design argument, not a validated one. We have built it this way and we believe it is right; we do not yet know whether the market agrees.
The specific thing that could be false: founders may say they want approval and behave as though they want it done. If most people approve everything without reading within a week, the boundary is providing ceremony rather than control, and the honest response would be to reduce what it asks about rather than to remove the gate.
We will know from approval rates and from how long people spend on a card before deciding. If it turns out we are wrong, that gets written up too.
If you want to see what an approval inbox actually looks like in use, paste a product URL — the launch video is the first thing our agent prepares for approval, and it is free with no account. The channel playbooks are the reasoning it works from.