A pilot starts by drafting customer follow-ups. It works. The team asks it to send them. Then someone adds CRM write access, more users, larger batches, and fewer approvals.
Each request sounds small. Together, they create a different system.
A successful pilot proves that one version of an agent can handle one bounded job under one set of conditions. It does not prove the agent should receive more data, permissions, volume, users, actions, or freedom to operate without review.
Make the agent earn one authority change at a time. Define the proposed change, measure the evidence, test the new failure surface, and keep a way back.
Authority is more than autonomous action
Teams usually talk about autonomy as if it has one setting. It does not. An agent's authority can expand along several dimensions.
It can read a new data source, write to another system, act on more record types, process higher-value transactions, serve another department, run at greater volume, keep more state, choose from more tools, communicate outside the company, or skip an approval that used to be mandatory.
Adding a read-only knowledge base is not the same decision as granting payment authority. Expanding from 50 routine tickets to 5,000 mixed tickets is not just a capacity change. The larger queue may introduce rare cases the pilot never saw and overwhelm the people handling exceptions.
Write the expansion as a before-and-after statement. For example: "The agent may currently prepare renewal reminders for one sales team. We propose allowing it to send reminders to approved contacts for renewals under $25,000 after a policy check." If the change cannot be described that clearly, it is too broad to approve.
Separate six kinds of expansion
| Expansion | What changes | Evidence to require |
|---|---|---|
| Data | New sources, fields, retained state, or sensitive records | Updated data map, access test, retention rule, and blocked-data cases |
| Action | New writes, messages, transactions, or external effects | Action limits, approval rule, duplicate protection, and rollback test |
| Scope | New department, customer group, geography, or use case | Representative test cases and a named business owner for the new scope |
| Volume | More concurrent work, larger batches, or tighter deadlines | Load test, queue limit, human review capacity, and cost ceiling |
| Tool choice | More connectors or freedom to choose the next step | Allowed-tool policy, stopping conditions, and adversarial test cases |
| Review | Fewer approvals or more actions allowed within policy | Override history, error severity, evidence quality, and monitoring coverage |
Do not bundle all six into a single "phase two" approval. If the agent gets more data, more actions, and less review at the same time, you will not know which change caused a failure. You will also make rollback harder.
Start with the outcome, not agent activity
High usage does not justify more authority. Neither does a high completion count.
Use the same accepted business outcome that justified the pilot. If the agent prepares service-ticket responses, measure responses accepted with no material correction, resolution time, reopened tickets, customer impact, review effort, and cost per accepted result. A busy agent that pushes cleanup work to another team has not earned a larger role.
The AI agent production scorecard should show stable performance across normal work, exceptions, and the edge cases most likely to cause harm. Set the minimum performance and maximum failure thresholds before reviewing the data. Moving the threshold after seeing the results is not governance. It is negotiation with your own evidence.
Require control evidence from the current scope
The current version should prove that its limits work before you widen them.
Review whether the agent stayed inside its approved data and action boundaries. Check denied requests, attempted out-of-scope actions, human overrides, approval decisions, failed writes, duplicate prevention, and incidents. Your agent audit trail should let another reviewer reconstruct representative transactions without help from the builder.
This is where many teams discover that their control is a prompt instruction such as "do not update sensitive records." That is guidance, not an enforceable permission boundary. If a system-level control is available, use it. Give the agent its own identity, restrict its tools and fields, and test requests that should be blocked.
If the existing boundary is hard to observe or easy to bypass, do not expand it.
Test the exact authority you want to add
A good result in the old scope does not prove performance in the new one. Build an expansion test set around the proposed change.
Include normal cases, incomplete inputs, conflicting records, stale data, duplicate events, unavailable tools, policy exceptions, malicious instructions, and actions near the financial or operational limit. Include cases that must stop or go to a person. Use holdout examples the implementation team has not tuned against repeatedly.
For a new action, verify authorization, idempotency, confirmation, downstream state, and reversal. For a new data source, verify field-level access, prohibited records, retention, and what reaches the model or vendor. For more volume, run a production load test that includes API limits, queue growth, latency, review capacity, and recovery.
The test must cover the full workflow. A model can produce a correct answer while the connector writes it to the wrong account.
Count the human work honestly
Reducing approval can improve cycle time, but only if the evidence shows the review is no longer doing useful risk work.
Inspect override reasons and correction patterns. If reviewers mostly approve clear, low-impact cases without changes, move those cases into a narrow policy boundary and keep exceptions in the queue. If reviewers catch material errors, the answer is not to remove them so the automation looks faster.
The human approval workflow should show the reviewer the source evidence, proposed action, policy applied, and expected effect. Measure review time, queue delay, escalation rate, and staffing demand after the expansion. Human capacity is part of system capacity.
Give the expansion an owner and an expiration date
Name the person who approves the authority change and the person who can suspend it. Record the business reason, affected systems, test results, approved limits, monitoring period, rollback steps, and review date.
Do not grant permanent access for a temporary pilot extension. Use expiring permissions where the platforms support them. Schedule a review after the agent has processed enough representative work to reveal whether the change performs as expected.
If a model, prompt, policy, connector, identity rule, or source system changes during that period, decide whether the expansion evidence is still valid. Use a release test instead of assuming the old approval follows the new configuration.
NIST supports measured deployment gates
The NIST Generative AI Profile recommends minimum performance or assurance thresholds as part of deployment go or no-go processes. It also says model capability claims should be evaluated with empirically validated methods and that pre-deployment test results should reach the people with release approval authority.
NIST does not prescribe one autonomy level for every workflow. Its AI Risk Management Framework says risk tolerance is specific to the organization and use case. That matters here. Sending a low-value internal reminder and changing privileged access should not face the same authority gate.
For this decision, write down the risk tolerance for the change, define the evidence needed to approve it, and keep the approval attached to the tested version and scope.
Use a one-change expansion gate
Before granting more authority, require a written yes to these questions:
- Is the proposed authority change specific and limited to one dimension?
- Did the current scope meet the business outcome, quality, reliability, control, and cost thresholds?
- Does the test set represent the new data, actions, volume, users, and failure cases?
- Are blocked actions, approval rules, monitoring, stop conditions, and rollback tested?
- Can the human review team handle the expected exceptions?
- Are the owner, expiration or review date, and tested configuration recorded?
If one answer is no, keep the current boundary. Fix the evidence gap. Then test again.
An agent should not get a promotion because everyone likes the demo. It should earn one defined expansion because the business result is real, the controls held, and the new authority survived a test designed to make it fail.