Choosing a model takes an afternoon. Answering "who is accountable when the agent does something wrong?" can stall a deployment for a quarter. That second question is what keeps AI agents stuck in pilots, and it has almost nothing to do with which foundation model you picked.
Everything changes the moment an agent can act rather than just generate text. A drafting assistant that suggests a reply is a productivity tool. An agent that sends the reply, posts the journal entry, or issues the refund is making a decision with consequences. So the governance question that actually matters is not "which model?" It is "where does the decision right live when the agent can execute?"
There are exactly three answers. Every action an agent can take should be assigned one of three decision rights: Autonomous, Approve-before, or Review-after. Route each action correctly and you bound your risk without smothering the return that justified building the agent in the first place.
Key takeaways
- AI agent governance comes down to one operational rule: assign every agent action a decision right — act alone, wait for approval, or act and get reviewed.
- The three patterns are Autonomous (the agent acts alone), Approve-before (a human authorizes first), and Review-after (the agent acts, a human or second agent reviews later).
- Route each action by four dimensions: reversibility, blast radius, regulatory exposure, and the agent's confidence.
- The same agent can hold different decision rights for different actions. Autonomy is a property of the action, not the agent.
- The demand is proven and the answer is missing. Deloitte reports only 21% of organizations have a mature governance model in place for agentic AI, even as deployment accelerates (Deloitte, 2026).
Why "which model?" is the wrong governance question
Most governance material on the market answers a question executives stopped asking months ago. It establishes that agentic AI raises risk and that oversight matters. Risk and Legal leaders already accept both. What they cannot get from a principles document is the one thing they actually need: an operational rule for which decisions an agent is allowed to make on its own.
The gap is well documented. Deloitte's research on agentic adoption found governance maturity lagging far behind deployment speed, with only a small minority of organizations confident in their readiness to oversee autonomous systems (Deloitte, 2026). KPMG describes the agentic era as a structural expansion of the risk surface, because an agent that perceives, plans, and acts compresses several human checkpoints into a single automated step (KPMG, 2025).
OpenAI's "Practices for Governing Agentic AI Systems" maps responsibilities across an agent's lifecycle and argues that accountability has to be assignable at the level of individual actions, not the system as a whole (OpenAI, 2023). That is the reframe this article runs with. Stop asking which model is safe enough. Start asking where the decision right lives for each thing the agent can do.
Two failure modes sit on either side of that question. Over-permissioning lets an agent execute a costly or irreversible action with no human anywhere in the loop. Over-gating forces a human sign-off on everything, which destroys the throughput that made the agent worth building. A decision-rights model is how you avoid both at once.
The three decision-right patterns
Think of decision rights as three control patterns you assign per action. Each one trades autonomy against oversight differently, and each is correct for a different class of action.
Autonomous — the agent acts alone
The agent perceives, decides, and executes with no human in the path. This is the pattern that delivers the speed and scale gains, so you want as many actions here as you can safely justify.
An action belongs in Autonomous when it is reversible, its blast radius is bounded, it carries low regulatory exposure, and the agent's confidence clears a set threshold. Internal data enrichment, document classification, tagging, and routine retrieval are good candidates. Three things have to be true first: a complete audit log of every autonomous action, a confidence floor below which the action escalates instead of executing, and a hard ceiling on scope so a single run cannot touch more than its mandate allows. The thing to watch is scope creep, where an action quietly grows in blast radius until "reversible and bounded" stops being true.
Approve-before — propose, authorize, execute
The agent does the work and produces a recommendation, then waits. A human authorizes the action before it executes. Nothing happens to the outside world until a person says yes.
Use Approve-before when the action is irreversible, high-value, regulated, or the agent's confidence is low. Sending an external customer commitment, posting a financial entry, moving money, or changing a production configuration all belong here. The design risk is approval theater, where the human reviewer cannot realistically say no because the queue is too deep or the context is too thin. Keep the pattern honest by giving the approver the agent's reasoning and evidence, by sizing the queue so review is genuine, and by tracking the rejection rate. An approval step with a near-100% yes rate is a rubber stamp, not a control.
Review-after — act now, review next
The agent acts immediately, and a human or a second agent reviews the action after the fact. You accept the action's effect in the moment in exchange for speed, and you catch errors on a sampled or full review pass behind it.
Reach for Review-after when the action is time-sensitive and reversible, the volume is too high to gate every instance, and a meaningful sample of reviews will surface systematic problems. Customer-support responses with sampled human QA are the canonical case. The trap is review theater, where the review loop exists on paper but no one acts on what it finds. Make it real by funding the reviewer capacity, by feeding findings back into the agent's guardrails, and by tightening the sampling rate after any incident.
| Pattern | Use when | Reversibility | Blast radius | Regulatory exposure | Confidence threshold | Example |
|---|---|---|---|---|---|---|
| Autonomous | Low-stakes, high-volume work | Reversible | Bounded, small | Low | High | Internal data enrichment and classification |
| Approve-before | High-stakes or regulated action | Irreversible | Large or external | High | Any, especially low | Posting a financial entry, external commitment |
| Review-after | Time-sensitive, reversible at scale | Reversible | Medium | Low to medium | Medium | Customer-support reply with sampled QA |
How to route an action — the decision tree
The patterns become operational when you turn them into a routing rule any team can apply. Walk each candidate action through four questions in order, and you land on a pattern by elimination.
- Is the action irreversible or high-value? If yes, route to Approve-before. Money movement, external legal or financial commitments, production changes, and anything you cannot cleanly undo stop here regardless of confidence.
- Is the action regulated or does it carry material compliance exposure? If yes, route to Approve-before or, where the regulation permits action-then-attestation, a tightly sampled Review-after with full logging. Let your Legal and Risk owners set which.
- Is the blast radius bounded and the action reversible? If no, escalate toward Approve-before. If yes, continue.
- Does the agent's confidence clear the threshold for this action type? If yes, route to Autonomous. If no, route to Review-after so the action still happens at speed but every low-confidence case gets a second look.
The order is the whole point. Reversibility and regulatory exposure are gates that override confidence, because a confident agent making an irreversible mistake is worse than a hesitant one. Confidence only earns an action full autonomy after the stakes questions have already cleared it. A flowchart of this logic is the single most useful artifact you can hand to your engineering and risk teams, so build one and put it in your governance runbook.
The three patterns in production
The model earns its keep when one agent carries different decision rights for different actions. Consider an illustrative customer-operations agent. The examples below are illustrative, not drawn from a named client.
The same agent enriching a customer record with public firmographic data acts Autonomously. The action is reversible, internal, low-exposure, and the agent is confident, so gating it would only add latency. When that agent drafts an external commitment to a customer — a refund above a threshold or a contractual promise — it switches to Approve-before. The action is irreversible and externally visible, so a human authorizes before anything is sent. KPMG's work on agentic workflows in financial reporting makes the same point for the finance domain: postings and disclosures need a human authorization gate because the downstream exposure is regulatory, not just operational (KPMG, 2025).
For first-line support replies, the same agent runs Review-after. It answers customers in real time, because making them wait for human sign-off on every message would defeat the purpose, and a sampled QA pass reviews a percentage of responses to catch drift and retrain the guardrails. Scale AI's framing of human-in-the-loop for enterprise agents describes exactly this layered approach, where humans move from doing the work to supervising it at the points that matter (Scale AI, 2025).
One agent, three decision rights, each matched to the action's actual stakes. That is the difference between a governance model and a governance slogan.
Common mistakes when assigning decision rights
The framework fails in predictable ways. Watch for these four.
Treating autonomy as all-or-nothing per agent. The most common error is deciding an agent is autonomous or not, instead of deciding it per action. Autonomy is a property of the action. The moment you grant it at the agent level, you over-permission the risky actions just to unlock the safe ones.
Approval theater. An Approve-before gate where the human cannot realistically refuse is not a control. If reviewers approve everything because the queue is overwhelming or the context is missing, you have added latency without adding safety. Measure the rejection rate and staff the queue so refusal is real.
Review-after with no teeth. A review loop that no one funds or acts on is review theater. If sampled findings never tighten the agent's guardrails and never trigger a re-tightening of scope after an incident, the pattern is decorative. An audit trail you never read is not an audit trail.
Static assignment. Decision rights are not set-and-forget. After an incident, after a model upgrade, or after an action's blast radius grows, the assignment has to be revisited. The right cadence is a standing review, not a one-time classification exercise.
Next steps
Map your top ten agent actions to the three patterns this week. For each action, ask the four routing questions and write down the pattern, the dimension that decided it, and the control you will put in place. You will likely find that most actions are safely Autonomous, a small number genuinely need Approve-before, and a middle band is best served by Review-after.
If you want help turning that map into an operational governance model, Book a Discovery Sprint . In one focused week we map your agent actions to decision rights, identify where you are over-permissioned and over-gated, and hand you a governance roadmap your Risk and Legal owners can sign. If you are not sure where you stand yet, start with an AI Readiness Snapshot , and if the constraint is capacity to run the review loops, a Fractional Agentic Team can operate them with you.
