Grant autonomy to a bounded action using evidence about the work and its consequences. Approval rates alone cannot establish safety; assess limits, exceptions, detection and recovery, with a way to restore review.
What you'll learn
- Why average accuracy does not determine the consequences of errors
- How to screen recovery, impact and the limits of the job
- What to test before changing an action’s approval requirement
- How to authorise, monitor and communicate a bounded permission change
Decide autonomy for a specific action, not for the agent as a whole. Use performance evidence alongside consequences, access limits, exception handling and recovery, and record who may authorise the change.
Suppose a lead-qualification agent has been making useful suggestions, and a colleague asks to remove approval for introduction emails. Good suggestions are relevant evidence, but the proposed change adds a different action: sending in the business’s name. Decide what that action may do, how mistakes would be found and what the team could recover before removing its review.
Accuracy and consequences belong in the same decision. A high average score does not tell you whether the wrong recipient could receive private information, whether a duplicate payment could be stopped or who would handle an unfamiliar request.
Why is accuracy alone insufficient for autonomous action?
Accuracy describes results on the work evaluated; it does not describe the consequences of every possible mistake. Review the errors by type and importance, including what people corrected before approval. An approval history without those corrections can make a workflow look more independent than it is. Microsoft’s March 2026 readiness guidance explicitly ties score thresholds to risk and usage context.[3]
To illustrate the effect of a chosen accuracy rate, take the 95% upper end of Microsoft’s example factual-accuracy range for a medium-risk customer-facing agent.[3] That is an illustrative starting threshold, not an observed performance rate or permission to remove review.
If independent actions hypothetically each had that 95% chance of being correct, the complementary error probability would be 5%. Its reciprocal gives 20 actions; the expected error count is 20 × 0.05 = 1 under this model.[4] Expected count does not guarantee exactly one mistake in every group or predict a day’s workload. Use measured error types and actual consequences for your decision.
Now compare possible consequences. An incorrectly applied label might be easy to repair, or might trigger an urgent-work queue incorrectly. A message to the wrong recipient might disclose information that deleting the local copy cannot recover. Assess the downstream effect rather than assigning a fixed repair time or relationship cost to every error.
Anthropic's agent-building guide recommends testing away from live work, appropriate controls and stopping conditions, and describes checkpoints for human feedback.[1] Use those mechanisms to test the intended permission change. The decision still needs the process owner’s judgement about acceptable consequences and the actual workflow.
Which questions should you ask before allowing autonomous action?
Ask how an error could be recovered, how far its effects could spread and how clearly the allowed job is bounded. These are useful screening questions, not a complete safety test or a guarantee. Data access, recipient rights, legal duties, detection and response capacity may change the decision too.
Approval history shows what people accepted after review. Before removing that review, check which corrections, refusals and missing facts the reviewer was supplying. Those contributions do not disappear just because the button does.
Can the action be recovered? Identify what undoing it actually means, who can do it and what has already happened meanwhile. Removing a tag does not reverse every process it triggered. A backup helps only if restoration is available, tested and suitable for the affected data.
How far can an error spread? Follow the destination and dependent workflows. An internal record can influence billing, staff allocation or customer communication. A limited access grant, recipient list or action limit should restrict the actual operation; the word “internal” does not contain the consequences by itself.
Is the allowed job clear? Define eligible inputs, permitted results and cases that must reach a person. A narrow task is easier to test than “handle all customer follow-up”, but can still receive unfamiliar requests. Keep a route for those requests and test it before expanding the job.
For example, widening a task from drafting replies for one sales stage to handling follow-up across every stage changes the decision rules and possible recipients. Review that expansion separately from a wording improvement. A previously accepted draft does not authorise a newly introduced action.
The table proposes starting questions for common actions. It is a decision aid, not a blanket permission list or a statement that every action of a type has the same consequences.
| Action type | Recovery question | Potential impact | Scope question | Starting approach |
|---|---|---|---|---|
| Tag or classify a contact | Can the label and its effects be corrected? | Dependent routing or reporting | Are categories and uncertain cases defined? | Test a bounded subset before allowing it |
| Create a draft reply | Can it be discarded without disclosure? | Draft access and later sending | Are sources and recipients constrained? | Separate draft permission from sending |
| Log a meeting note | Can incorrect data be corrected throughout? | People relying on the note | Are attribution and destinations clear? | Check privacy, facts and correction route |
| Send an outbound message | What remains after a wrong send? | Recipient disclosure and commitments | Is this exact message type authorised? | Begin with review of consequential sends |
| Update a deal stage | Can dependent actions be reversed? | Forecasting, commissions or outreach | Are transition rules complete? | Review consequential transitions |
| Update an invoice or payment record | Can a payment or recipient error be recovered? | Financial and customer consequences | What limits and approvals apply? | Keep consequential actions under authorised review |
| Assign an internal queue | Can missed urgency be corrected in time? | Service delays and team workload | Are urgent and uncertain cases recognised? | Test limits and an exception route |
| Contract or compliance communication | Can a commitment or disclosure be recovered? | Legal or contractual consequences | Who may authorise the content and action? | Obtain the relevant authorised decision |
Which actions deserve particular care before autonomy?
Start conservatively with actions that disclose information, move money, change consequential records or create commitments. Decide the review requirement for the actual operation and applicable obligations. These categories are prompts for closer scrutiny, not a universal legal rule that every external message always needs a fresh human click.
Outbound communication. Review recipient, source facts, tone, timing and whether the message makes a commitment. A fixed acknowledgement and a negotiated commercial reply are different jobs. If any limited message type is authorised without prior review, define its content, eligible recipients and stop conditions explicitly.
Financial actions. Identify the value, destination, duplicate controls and authorisation required. A low apparent amount does not settle the question if the workflow can repeat the action or reach the wrong account. Keep the review appropriate to the actual financial authority.
Consequential CRM updates. Follow what depends on a stage, close date or account-health flag. A record change may start another workflow or affect a person’s commission. Test the linked effects and the route for correcting earlier changes.
Legal or contractual implications. Obtain the appropriate business and specialist review of authority, content and consequences before changing autonomy. Do not treat a high approval rate as permission to make new commitments. Separately agree which routine administrative actions, if any, are permitted within an already authorised process.
Which actions might suit limited automatic handling?
Consider a bounded operation only after its access, consequences, exceptions and recovery are understood and tested. Drafting, tagging, formatting and routing can be useful candidates, but their names do not make them harmless. Keep the allowed subset specific enough that the operator can recognise an out-of-scope request.
Ask what happens when the action is wrong, not only how often it is right.
Classification and tagging. Test ordinary categories, ambiguous inputs and consequential destinations. Check whether a label starts another action. Refer uncertain or excluded cases rather than guessing merely to improve the completion rate.
Draft creation. Separate permission to prepare a draft from permission to send or publish it. Check which information the drafting service receives and who can read the result. A person’s later review does not undo an earlier disclosure to the wrong destination.
Formatting and enrichment. Preserve the source and distinguish an observed fact from a guess. Test missing, conflicting and outdated values. Automatically filling an empty field can affect later decisions even if the field is technically editable.
Routing and assignment. Test priority, absence and unreachable queues. Name who handles a referral that nobody accepts. The ability to change the assignee later does not recover a missed deadline automatically.
AEPD guidance recommends adjusting autonomy to the impact and risk of personal-data processing, with human intervention for more consequential operations.[2] Apply the same attention to the specific action in your operating decision; do not substitute a category label for the assessment.
How do you decide whether to remove an approval gate?
Combine representative approval history with tests of exceptions, enforced limits and a practical recovery plan. Ask what changes when the reviewer is absent, then authorise only the subset the evidence supports. There is no universal count of decisions or number of stable weeks that makes a gate unnecessary.
Record approvals without edits, factual corrections, changed recipients, refusals and requests for missing information. Separate serious mistakes from optional style changes. Check that the examples cover the request types and conditions the automatic action would encounter, including rare consequential cases.
Test requests that must be refused or referred, interrupted connections, duplicate triggers and attempts outside the permitted scope. Keep action limits, monitoring and the person who can stop the operation clear. A clean approval history on ordinary requests does not test every one of these conditions.
| Observed pattern | What to investigate | Decision to consider |
|---|---|---|
| Stable outcomes on representative work | Reviewer corrections, excluded cases, limits and recovery | Consider a limited authorised trial if consequences are acceptable |
| Frequent minor edits | Whether edits are optional or needed for correctness | Keep review where the changes matter; improve the specific rule |
| Significant factual or recipient corrections | Which source, matching or decision rule fails | Keep the gate on affected work and repair the cause |
| Repeated refusals | Unsupported requests, wrong triggers or unclear scope | Narrow the eligible job and retest |
| Results vary between periods | Request mix, business changes, tool changes and review standards | Investigate before expanding autonomy |
Start any change with an explicit owner, limited scope and a way to restore prior review. Monitor the changed action and hold or restrict it if the agreed limits are crossed. Earlier good results do not make a permission change permanent.
This sits within approval-workflow design and the broader governance framework. Record who authorised the change and what evidence was considered, not just that a setting was switched.
How do you communicate autonomy changes to the team?
Before enabling a permission change, tell the affected team which action will run automatically, which requests remain excluded, who watches it and how to stop or report a problem. Update the operating instructions and backup arrangements. Check that the absence of a queued item will not be mistaken for missing work.
A practical message names the action, start date, limits, owner and escalation route. Ask the former reviewer to confirm they understand what the system now does without them. Keep responsibility visible when a task moves out of their queue.
If an automatic action needs to be paused or returned to review, apply the necessary restriction promptly and tell the team how to handle incoming and already affected work. Restore the manual route and explain why items are appearing for approval again. Communication supports the restriction; it should not delay an urgent stop.
Frequently asked questions
When is it safe to let an AI agent act without human approval?
Decide for the exact action, data and recipients using test results, possible consequences, enforced limits, detection and recovery. Reversibility, impact and a bounded job are useful screening questions, not a guarantee. Retain authorised review where the consequences or applicable obligations require it.
Why is accuracy the wrong measure for deciding on autonomous AI agent actions?
Accuracy matters, but a percentage does not describe the cost or recoverability of each mistake. Examine serious errors separately, include human corrections and inspect the downstream outcome. Do not read an average as a guarantee of how errors will be distributed.
Which AI agent actions should always require human approval?
Start with authorised review for consequential sends, financial actions, significant record changes and commitments. Determine requirements for the specific action and applicable obligations. Routine administrative actions need their own explicit limits; a high approval rate does not authorise new commitments.
How do you build evidence that it is safe to remove an approval gate?
Combine representative approval history with tests of excluded cases, missing facts, permission limits, duplicates and recovery. Record the corrections the reviewer supplies. Authorise only a bounded subset, name an owner and keep a way to restore review; no fixed sample count establishes safety.
What actions are safe to automate fully without any approval gate?
Drafting, tagging, formatting and routing may be candidates when their actual access, downstream effects, exceptions and recovery are understood and tested. Internal or editable does not mean harmless. Separate draft preparation from sending and define what must still reach a person.
Notes
Sources accessed 15 October 2026. Opening and error-count calculation use explicit hypothetical assumptions. Tables and autonomy-screening questions are recommendations, not population benchmarks or proof of safe operation. AEPD guidance concerns personal-data processing.
- Building effective agents. Anthropic; 19 December 2024; living page subsequently revised.
- Agentic artificial intelligence. AEPD; v1.1 February 2026.
- Interpret evaluation scores and assess readiness. Microsoft Learn; updated 31 March 2026; accessed 15 October 2026.
- Binomial Distribution. NIST/SEMATECH e-Handbook; living statistical reference; accessed 15 October 2026.
