Platform / Autonomy

Autonomy: how much an agent may decide alone

Two questions, answered separately: which classes of action an agent may perform at all, and — for each specific action — whether it runs on its own, waits for a person, or is refused.

Admin

Policy

The two layers

Keeping these apart is what makes the model usable. The first layer is coarse and set once; the second is where the interesting decisions live.

1. Allowed action classes

Broad permission by class — read, write, admin. An action whose class is not allowed never reaches the gate layer at all; it is refused earlier and for a simpler reason.

2. Per-action gates

For each individual action, one of three gate modes. This is per action name, not per integration, so “may read Jira” and “may close a Jira ticket without asking” are different decisions.

The three gate modes

autonomous

Runs on its own

The agent performs the action without waiting. Still policy-evaluated, still recorded, still attributable, and still revocable afterwards — autonomous means unattended, not ungoverned.

human_approval

Waits for a person

Execution suspends and an approval request is raised. The workflow does not poll or spin; it resumes when someone approves, or stops when someone rejects. The approval chain is logged with it.

blocked

Refused

The action is not available to this agent in this context. The refusal carries a reason rather than surfacing as a generic failure.

Every decision returns the gate that applied and the reason for it. When an agent reports that it could not do something, that is answerable from the record rather than by re-running it and watching.

Choosing a mode

The useful question is not “how much do we trust the model” but what does this action cost to get wrong, and can it be undone.

If the action is…	Start at
A read, or a write that Rewind can reverse cleanly	autonomous
Visible outside the company, or expensive to reverse	human_approval
Irreversible at the provider, or outside this team's remit	blocked

Reversibility is a property of the action at the provider, not a setting — see the Rewind guide for which actions can actually be undone and where the barriers are.

Delegation

An agent can delegate to another agent, and delegation is bounded rather than implicit: it is enabled explicitly, the roles that may approve are named, and a maximum delegation depth caps how far a chain can run. Without a depth cap, one approval at the top can authorise work nobody reviewed further down.

Where a gate is decided

Gates are evaluated on the tool call, not handed out once at the start of a session. An initial tool list is not the authorization boundary: policy is applied each time the action is attempted, which is what makes revocation take effect on sessions that are already running rather than only on the next one.