Propose-and-approve: designing agent autonomy you can trust
Full autonomy is reckless and full manual review defeats the point. Propose-and-approve is the middle path — and getting the boundary right is the whole design problem.
By Dmitrii SelikhovFounder
Key takeaways
- Agent autonomy is a spectrum with two bad endpoints: full autonomy is reckless because an agent will eventually do something irreversible and confidently wrong, while full manual review is so tedious that teams approve on autopilot and the control becomes theater.
- Propose-and-approve splits actions by reversibility, not importance — the agent reads and drafts and edits freely, but anything destructive (delete, bulk update, bulk archive) stops at a broker and emits a structured proposal showing exactly what would change before a human approves it.
- The design only works if the proposal is legible and the boundary is enforced in one place: the diff has to show the real impact in plain terms, the destructive flag comes from a single canonical tool registry rather than scattered checks, and even auto-approved actions land in the audit trail.
- Done well the pattern fades into the background — routine work flows because most of it is non-destructive, the rare consequential action gets the half-second of human judgment it deserves, and the team gets the speed of autonomy with the safety of review instead of choosing one.
Agent autonomy isn't a switch, it's a spectrum, and both ends of it are wrong. At one end is full autonomy: the agent does whatever it decides, and you find out afterward. At the other is full manual review: the agent can't lift a finger without a human signing off on every keystroke. The first is reckless and the second is pointless, and most teams ping-pong between them — turning the agent loose, getting burned, then clamping it down so hard it's useless. The interesting design space is the middle, and the pattern that lives there is propose-and-approve. Getting its boundary right is the entire problem.
Why both extremes fail
Full autonomy fails for a reason that's easy to underrate in a demo: an agent will eventually be confidently, irreversibly wrong. Most of the time it's right, which is exactly what makes it dangerous — you stop watching, and then one day it interprets 'clean up the backlog' as 'bulk-archive four hundred open issues' and executes instantly, because nothing stood between its decision and your data. The cost of an autonomous mistake isn't the mistake's average size, it's its worst case, and the worst case of an unsupervised delete is catastrophic.
Full manual review fails for the opposite reason. If the agent has to ask before reading a record, drafting a comment, or moving a card, the human becomes a bottleneck doing nothing but clicking approve, and approval fatigue sets in fast. A person asked to confirm forty harmless actions an hour stops reading them — they approve on autopilot, and the one genuinely destructive request slips through inside a stream of trivial ones. A control that's too noisy to actually read isn't a control; it's a checkbox that launders bad decisions into approved ones. The design has to earn the human's attention by spending it only where it matters.
Split by reversibility, not importance
The key design decision is where to draw the line, and the right axis is reversibility, not importance. Reading data, drafting a comment, editing a description, moving an issue between states — these are reversible. If the agent gets one wrong, you undo it in a click and nothing is lost. So the agent does them freely; gating them would just manufacture approval fatigue. Deleting, bulk-updating, bulk-archiving — these are destructive, hard or impossible to cleanly reverse, and a single confident mistake does real damage. So these stop at a broker. When the agent reaches for a destructive tool, instead of running it, it emits a structured proposal that describes exactly what would change, and a human approves or rejects before anything executes.
Splitting on reversibility rather than importance is what keeps the pattern usable. An importance line is subjective and ends up gating everything 'just in case,' which is full manual review wearing a disguise. A reversibility line is objective — either an action can be cleanly undone or it can't — and it concentrates human attention on precisely the actions where attention pays off. The agent stays fast on the ninety-five percent of its work that's safe, and a person spends judgment only on the five percent that's consequential.
The proposal has to be legible, and the boundary singular
A propose-and-approve loop is only as good as its proposal. If the broker shows a human an opaque blob — 'the agent wants to call bulkUpdate with these forty IDs' — the human can't actually judge it and is back to rubber-stamping. The proposal has to render the real impact in plain terms: these specific issues, this specific change, this is what your workspace looks like after. Legibility is the feature. A reviewer who can see the diff makes a real decision in a second; a reviewer who can't makes a fake decision and the safety is illusory.
Just as important, the boundary has to be enforced in one place. The 'is this destructive?' question can't be a judgment scattered across the codebase, because then it drifts — one path checks, another forgets, and the gap is where the accident happens. The destructive flag should come from a single canonical tool registry that's the one source of truth, so every call path — the agent runtime, an external client over MCP — consults the same definition and a session lacking destructive capability uniformly gets an approval-required result instead of acting. And even when an action is auto-approved by policy, it still records an audit row, so 'approved automatically' and 'happened invisibly' never become the same thing.
When it works, it disappears
The mark of a good propose-and-approve design is that you stop noticing it. The routine work — triaging inbound requests, drafting summaries, tidying descriptions, moving issues along — just flows, because most of it is reversible and never hits the broker. The rare consequential action surfaces a clear proposal, gets its half-second of human judgment, and proceeds. Nobody is drowning in approvals, and nobody is lying awake about what the agent might do unsupervised. You've bought the speed of autonomy and the safety of review at the same time, instead of trading one for the other.
That's the whole promise of the pattern, and it's why 'agents propose, humans approve' is more than a slogan. It's a concrete answer to the question every team eventually asks about AI: how do I get the benefit without betting the company on the model being right every single time? You don't make the model perfect — you can't. You design the system so the model's reversible work runs free and its irreversible work waits for a person who can see exactly what's about to happen. Trust isn't something you extend to an agent on faith. It's something you engineer into the boundary around it.