The Propose-Approve Pattern: How to Trust AI Agents With Real Work

Every team deploying AI agents eventually faces the same fork in the road.

Down one path is full autonomy: the agent replies to customers, merges code, publishes content — no human in the loop. It's the demo that raises the funding round, and it's also how you end up apologizing to a customer for something you never saw. The failure mode isn't that full-auto agents make mistakes; everything makes mistakes. It's that they make mistakes silently, and you find out from the person the mistake happened to.

Down the other path is no autonomy: the agent suggests things in a sidebar, and a human retypes or copy-pastes anything that matters. Safe, and nearly pointless. If every action still costs a human the full effort of doing it, the agent has added a reading step, not removed a working step. Teams quietly stop looking at the sidebar within a month.

There's a third path, and it's not a compromise between the two — it's a different design. The agent does the complete work: reads the context, makes the decision, writes the artifact, stages the action. But the action doesn't take effect until a human approves it, and even after it does, it can be undone. Call it propose-approve.

The pattern, precisely

Propose-approve has a specific shape. Miss a piece and you get one of the two failure modes above wearing a disguise.

1. The agent produces finished work, not suggestions. A staged customer reply, ready to send. A branch with a passing test, ready to merge. The human's job is a decision — approve or reject — not a rewrite. This is what preserves the leverage: reviewing a good draft takes a tenth of the effort of writing one.

2. Every action lands in a reviewable log. Not a metrics dashboard ("the agent handled 34 items") but an inspectable ledger: this item, this proposed action, these inputs, one click to see exactly what it touched. If you can't audit an individual decision, you can't calibrate your trust in the system — you can only feel vaguely good or vaguely nervous about it.

3. Everything has a revert path. Approval isn't the last line of defense; reversibility is. A closed ticket can reopen to its previous status. A published draft can unpublish. A merged PR can revert. When revert paths exist, an approval mistake costs minutes. When they don't, every approval is load-bearing and review slows to the speed of fear.

4. Actions are idempotent. Boring, and essential. Agents run on crons and retries; the same trigger will eventually fire twice. Approving a proposal twice must not email the customer twice. Reverting a revert must not corrupt state. Key every proposed action to the thing it acts on, and make apply/revert safe to repeat.

5. Review is batched, not interruptive. If every proposal pings you, you've built a distraction machine and you'll start approving on autopilot — which is full-auto with extra steps. The proposals should pool in a queue you visit on your schedule: with morning coffee, after standup, end of day. Ten decisions in five minutes.

One pattern, three domains

What makes this a pattern rather than a product feature is that the same five ingredients show up wherever agents meet consequences.

Support replies. An agent reads an incoming ticket, searches the knowledge base, and drafts a grounded answer — but stores it as pending instead of sending. The queue shows the ticket, the draft, and the sources; approve sends it to the customer, reject discards it. This is the design Helmdesk's agents use, and the telling detail is the spectrum within one product: drafting a reply is propose-only (an email to a customer is hard to unsend, so a human gates it), while auto-closing a stale ticket executes immediately but logs a one-click reopen (perfectly reversible, so review can happen after the fact). The cheaper the undo, the further downstream the human can stand.

Code changes. Software teams converged on propose-approve years before anyone called it that — the pull request is exactly this shape. Which is why the guardrail for coding agents writes itself: the agent gets a branch and a PR, never a merge. The finished work is the diff plus a passing test; the reviewable log is the PR itself; the revert path is git revert; CI makes a second, tireless reviewer. Any coding-agent setup that auto-merges has thrown away the pattern precisely where the blast radius is largest.

Content. A drafting agent writes the changelog entry, the release notes, the KB article — into a drafts folder, never straight to the site. Publishing is the approval; unpublishing is the revert. The queue is your CMS's review view. Same five ingredients, different nouns.

"Doesn't the human become the bottleneck?"

Only if you've built the wrong half of the pattern. The bottleneck objection assumes review costs what doing costs — but a well-built approval step is a judgment check, not a quality check. The agent already did the quality work; you're checking direction: right customer, right tone, right call. That's seconds per item when the queue shows you the right context.

And the ratio isn't fixed. Propose-approve is how autonomy is earned, not a permanent ceiling. After a few hundred reviews you have real data: which action types get approved untouched 98% of the time, and which get edited or rejected. Graduate the first group to auto-with-revert — execute immediately, log it, keep the undo button. Keep the second group gated. The review queue isn't just a safety mechanism; it's the instrument that tells you where the safety is still needed.

Building it: a starting checklist

If you're adding agent actions to your own product or internal tools, the minimum viable version is smaller than it looks:

• A review_state on every agent action: pending, approved, reverted — plus null for purely informational output that needs no gate.
• A details payload rich enough to render what this action touches without a join-hunt: the ticket and the drafted reply, the article ID, the previous status you'd restore on revert.
• An apply function and a revert function per action type, both idempotent.
• One queue UI: list of pending items, context inline, approve and revert as single clicks.
• A rule for classifying new action types: irreversible-and-external → propose-only; reversible → auto-execute with a logged undo; informational → just log it.

That last rule is the whole philosophy in one line. The question is never "is the AI good enough to act alone?" — accuracy drifts, edge cases lurk, and you'll misjudge it in both directions. The durable question is "what does it cost to undo this?" Design the undo first, and trust stops being a leap of faith. It becomes a dial you turn as the evidence comes in.

See propose-approve running a real support queue

Helmdesk's agents draft replies, close stale tickets, and write missing docs — then queue everything for one-click approve or revert. Free to start.

Start freeHow the agents work