Autonomy change request template

An autonomy change request asks to change how far an AI agent may act for one capability, from its current depth to a requested one. It names the capability, the evidence behind the request, the limits that will apply, how actions at the new depth can be undone, what will be watched afterwards, and who approves.

What is an autonomy change request for?

Autonomy should move in small, recorded steps, one capability at a time. The request is the record of each step. It stops depth being raised because a team is confident or a queue is long, and makes sure the case for it is written down where an auditor can find it.

Two principles shape the form. First, depth is earned, not configured: the request asks for a review of evidence; it cannot grant more than the certification supports. Second, the request is per capability. An agent that drafts letters well has not proven it should send payments. That is the core of graduated autonomy: authority grows in increments, each backed by evidence. For the wider reasoning, see the guide to regulated autonomy.

When should someone raise one?

Raise a request when a capability has run at its current depth long enough to produce evidence, when held items are being approved without edits, and when the business case for less human handling is clear. Do not raise one to clear a backlog during a busy week.

Requests to reduce depth are simpler. Anyone accountable for the agent can lower depth immediately without one, and should record it afterwards. After an incident, use the autonomy reduction plan template instead.

How do you complete each field?

• Capability. Use the wording from the brief. One capability per request.
• Current and requested depth. Normally one step at a time.
• Evidence. Attach the latest certification run and the gate results. Add operational evidence: how many held items were approved unchanged, edited or rejected over the period.
• Bounds at the new depth. The limits that will still apply. Bounded autonomy means the new depth comes with its amount, count and segment limits stated.
• Reversibility. Class of the actions involved and how each is undone.
• Monitoring and rollback trigger. What you will watch for the first weeks, and the specific event that sends depth back down.

Check the request against your autonomy decision matrix, which should already say what depth each kind of action may reach.

The autonomy change request template

1. Request reference, requester, date raised
2. Agent name and brief version
3. Capability (exact wording from the brief)
4. Current depth and requested depth
5. Role ceiling for this agent
6. Reason for the change, in operational terms
7. Certification evidence: run reference, set size, result per gate
8. Operational evidence: held items over the period, approved unchanged, edited, rejected
9. Actions affected and their reversibility class
10. Limits that will apply at the new depth
11. What the decision matrix allows for these actions
12. Monitoring plan for the first 30 days
13. Rollback trigger and who acts on it
14. Approvals: agent owner, risk, business owner
15. Decision and effective date

A filled sample: outpatient records agent

A hypothetical outpatient clinic group wants its records agent to update patient contact details without a person confirming each change.

The limits field carries the most weight here. Contact details are reversible and low harm. Clinical entries are neither, which is why the request stops well short of them; whether an AI agent can change a patient record explains where that line sits.