After an incident, cut an AI agent's authority precisely and write down how it comes back. An autonomy reduction plan records which capabilities lose depth, how far, how the extra human workload is covered, which past actions are reviewed, and what evidence restores depth. Fill it in on the day of the incident.
Why write a plan rather than just switch the agent off?
Switching an agent off is sometimes right, but it is a blunt answer. It removes capabilities that had nothing to do with the incident and pushes all of the agent's work onto people overnight. A plan lets you cut back precisely, at the capability that failed, and keep the rest running under watch.
The plan also answers the question every reviewer will ask later: how did you decide it was safe to give the authority back? Without a written plan, depth tends to creep back when the pressure fades. With one, it returns only when named conditions are met. Treat it as one part of handling an AI agent incident, not the whole response.
What should be reduced, and how far?
Decide scope first. Three options, from narrow to wide:
- The capability. The default. Drop only the capability involved.
- The agent. If the cause is in the brief or a source the agent uses everywhere.
- Every agent sharing the cause. If the fault is in a shared source, connection or platform rule.
Then decide the level. A certification run that clears no depth drops an agent to depth 1 the same day. For an operational incident, the usual move is one step down to depth 2, so the agent keeps preparing work and a person releases it. That is supervised autonomy, and it keeps the agent producing evidence while you investigate. Your autonomy decision matrix is the reference for where each action should sit.
How do you fill in the plan?
- Incident and agent. Reference, date, agent name, brief version.
- Capabilities affected. Depth before and after, with the time of change.
- Scope rationale. Why you cut where you did, not wider or narrower.
- Look-back. How far back you review actions taken by the capability, and who does it.
- Remediation. Actions to undo or compensate, from the look-back.
- Workload cover. How many items a day now need a person, and who handles them. This is the field most plans miss.
- Cause. Current understanding, updated as it develops.
- Restoration conditions. The fix, the incident cases added to the certification set, a passing run, and a minimum period at reduced depth.
- Approvals and dates.
The autonomy reduction plan template
| Field | Entry |
|---|---|
| Incident reference and date | |
| Agent and brief version | |
| Capabilities reduced (from depth, to depth, time) | |
| Capabilities left unchanged and why | |
| Other agents affected | |
| Look-back period and reviewer | |
| Actions to undo or compensate | |
| Extra human workload per day and who covers it | |
| Cause (current understanding) | |
| Fix applied or planned | |
| Cases added to the certification set | |
| Restoration conditions | |
| Minimum period at reduced depth | |
| Plan owner | |
| Approvals | |
| Restoration decision and date |
A worked sample: collections payment plans
A hypothetical lender's collections agent agreed payment plans for customers who had told it they were in financial difficulty. A policy update had changed the limit for those customers, but the agent was still reading the earlier version.
| Field | Entry |
|---|---|
| Capabilities reduced | Agree payment plan: depth 3 to depth 2, same afternoon |
| Left unchanged | Answering balance queries; drafting reminder letters |
| Other agents affected | None; only this agent cited the old policy version |
| Look-back | Six weeks of plans agreed with customers in difficulty; reviewed by collections team leaders |
| Actions to remediate | 40 plans re-checked; 12 re-offered on corrected terms with an apology |
| Workload cover | Around 80 held plans a day; two collections staff reassigned for four weeks |
| Cause | Source not refreshed after policy change |
| Fix | Source freshness rule added: policy read at time of use |
| Cases added | 60 cases covering customers in difficulty under the new limit |
| Restoration conditions | Passing run on the enlarged set; four weeks of held plans with none rejected for limit errors |
The restoration request then went through the normal autonomy change request, with this plan attached as evidence. Depth came back by the same route it was first earned, which is the point of graduated autonomy. See the guide to regulated autonomy for the principle behind it.
Questions people ask
Who can reduce an agent's depth?
Anyone accountable for the agent or for the process it serves should be able to reduce depth at once, without waiting for a meeting. Raising it again needs the full approval route.
How long should depth stay reduced?
Until the restoration conditions are met, not for a fixed calendar period. Set a minimum period so the evidence covers normal weekly patterns, then let the evidence decide.
Should customers be told about the reduction?
Customers need to be told about any harm to them and how it is being put right. The change in the agent's depth is an internal control; whether to mention it depends on your communications policy and regulator expectations.