Designing the Approval Gate

The fleet

I design, build, and operate a set of agents that do real work on real accounts. Not demos — things that run on a schedule, unattended, against live systems:

• Outreach agents that research prospects and write to them in a specific voice
• A social agent running a two-week content calendar across several channels
• A support and executive-assistant agent handling inbound mail and calendar
• An operations service for a rental property — dynamic pricing, turnover scheduling, vacancy response, weekly reporting
• A lead pipeline that watches a Slack channel, classifies what lands there, and appends qualified leads to a shared sheet
• A trading bot with a risk engine, running in paper mode
• An orchestrator sitting above the roster

Six of them run as scheduled jobs on my machine. I did not learn agent design by reading about it; I learned it by having to decide what these things were allowed to do without asking me first.

The real design surface

Everybody building AI products talks about prompts, models, and tools. In practice, once an agent can actually act, the question that consumes the design is narrower and much harder:

For this specific action, does a human have to say yes?

Answer “always” and you have built a very expensive way to write your own emails. Answer “never” and you eventually wake up to something irreversible, sent in your name, to someone who matters.

So the gate is not a setting. It is the design. And it has to be decided per action, not per agent.

Four patterns I ended up with

1. Draft-only, with the tool deliberately withheld

The outreach agents stage every message as a ready-to-send draft and never send. The rule is written to survive a future where sending becomes easy:

Do not auto-send, even if a send tool becomes available, unless I explicitly change this rule.

That clause matters. Most safety rules fail not because the model disobeys them but because the environment changes underneath them — a capability appears that the rule never anticipated. Writing the rule against future capability rather than current capability is the difference between a constraint and a coincidence.

2. Two gates, at the two points where taste lives

The social agent has two separate approvals, because there are two different judgments and collapsing them into one produces bad work.

Gate one is visual. Designs are built where I can see and comment on them, and revised until I am happy — before anything reaches the scheduling tool.

Gate two is publication. Every post is staged as a draft. My approval is the only thing that publishes. The rule is written as an absolute:

You never publish or schedule a post. Approval is the only thing that publishes.

A draft may hold a calendar slot with a placeholder image while the real design is still in review — which lets the agent keep working without ever getting ahead of me.

3. A hard floor that is categorical, not conditional

Across every agent, the same floor applies, phrased as a category rather than a list of examples:

Never commit money, pricing, revenue splits, contract or exclusivity terms, or legal promises. Propose; never commit.

Propose; never commit is the most portable thing I have written in this whole project. It gives the agent a useful job on exactly the questions where it must not have the final word, and it degrades safely — an agent that proposes something wrong costs me a minute, where an agent that commits something wrong costs me a contract.

4. Verification as part of the action

The thing I got wrong early: I trusted that the agent had done what it said it did.

Now the social agent has to check its own work after every batch — re-query the scheduler, confirm its items are actually in draft state, and if anything ended up scheduled by mistake, revert it and tell me. The instruction to verify is as important as the instruction to act.

This is the AI-specific version of something I already believed from design systems work: a standard nobody checks is a preference. It was true of design tokens, and it is true of an agent’s own claims about what it did.

Graduated trust, not a switch

The autonomy level is not a property of an agent. It is a stage, and it moves.

Social engagement started fully automated. I watched the tone, decided I was not comfortable, and moved it back to draft-first — explicitly as a trial, with the condition written down: it goes back to full automation when I trust the tone, and not before.

The trading bot works the same way: it runs in paper mode, making real decisions against a simulated book, and live mode only turns on deliberately, once paper has proven itself.

Designing for this means the interface has to make the current stage legible. The human-in-the-loop queue is a plain file with four states — pending, approved, sent, skipped — which is almost embarrassingly simple and has never once confused me about where something stands. The agent sends only what is marked approved, then marks it sent.

I have built fancier review UIs. This one works better, because the cost of checking it is near zero and I actually check it.

The assistant with a floor and no ceiling

The hardest brief was the executive assistant, where the goal is genuinely fully hands-off — and the safety floor is never loosened regardless.

Those two things sound contradictory and are not, which took me a while to see. “Fully autonomous” and “constrained” are different axes. The agent can run without me indefinitely, as long as the things it must never do are specified as categories it cannot reason its way around: never invent facts, never promise refunds, pricing, timelines, or legal terms.

Autonomy is about how often a human is in the loop. The floor is about which decisions can ever be delegated. Conflating them is why so many agent products feel either useless or alarming.

What I would tell you in an interview

This is the work I would most want to be asked about, because almost nobody designing AI interfaces has had to live with their own gate decisions. I have. When I set a gate too loose, the consequence arrives in my inbox with my name on it.

The transferable claim is this: in an agent product, the permission model is the user experience. Not the chat surface, not the prompt, not the model choice. What the system may do alone, what it must ask about, how it shows you where it is, and how a person moves it from supervised to trusted — that is the product, and it is a design problem before it is an engineering one.