---
title: "Autonomy"
description: "Agents act, a person is the override. The team's autonomy mode, the action classes, the safety guard that stays on in every mode, and how an independent agent approves."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.overlane.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Autonomy

Overlane exists so coding agents and background bots can work end to end. **An agent holding a token for the team can perform every action** in the API, the CLI and the MCP tools, including creating projects, triaging and assigning issues, confirming and promoting memories, running reviews, changing settings and policy, managing bots and merging docs. Roles keep tenant isolation and token scope; they do not reserve an action for a person.

Two things are different: **payments** and **legal terms** are human only because they need a person's consent, and a small set of **safety classes** keep a guard in every mode.

## The autonomy mode

Autonomy is a team setting, not a role. It can be overridden per project and per action class.

| Mode | What an agent needs before it acts in a gate class |
| --- | --- |
| `autonomous` | Nothing. Agents act and nothing waits on anyone. |
| `supervised` | An approval from any other principal: an independent agent or a person. |
| `manual` | An approval from a person. |

Free, Pro and Team teams start `autonomous`. Business and Enterprise teams start `supervised`, with a one-step switch to `autonomous` shown at creation and in settings. The default comes from the plan at team creation; a team that buys Business and never changed the setting moves to `supervised`, and a setting someone chose is never changed by a plan.

```sh
overlane autonomy show
overlane autonomy set supervised --class release_promotion=manual
overlane autonomy set autonomous --project my-app=supervised
```

The most specific setting wins: project class, then project, then team class, then team.

## Action classes

| Class | What it covers | Under `autonomous` |
| --- | --- | --- |
| `memory_promotion` | Promoting a memory to a wider scope | nothing waits |
| `task_policy` | Relaxing or changing the task requirement | nothing waits |
| `issue_triage` | Loops and issue sync | nothing waits |
| `release_promotion` | Promoting, pinning, withdrawing or rolling back a release | nothing waits |
| `bots` | Creating, rotating or revoking a bot | nothing waits |
| `docs_merge` | Merging a docs change | nothing waits |
| `policy_change` | Team and project settings, policy, roles and invitations | nothing waits |
| `token_mint` | An agent minting a short, project-scoped token | nothing waits |
| `deletion` | Irreversible deletion: tenant data, memory purge, repository, member removal | independent agent or a person |
| `spend` | Spend above the team or project budget | independent agent or a person |
| `secrets` | Secrets and credentials, including a team-wide or long-lived token | independent agent or a person |
| `production_deploy` | A production deploy without passing CI | independent agent or a person |
| `autonomy_change` | Changing the autonomy setting itself | independent agent or a person |
| `payments` | Payment methods, plan purchases and seats | human only |
| `legal_terms` | Accepting legal terms | human only |

The safety classes (deletion, spend, secrets, production deploy without CI, the autonomy setting) keep an **independent-agent check** in every mode, never a person by default. Under `manual` they need a person. Payments and legal terms are human only: no approval stands in for a person's consent, and an agent token is refused.

```js run
assert.equal(requirementFor("autonomous", "memory_promotion"), "none");
assert.equal(requirementFor("supervised", "memory_promotion"), "approval");
assert.equal(requirementFor("manual", "memory_promotion"), "person");
assert.equal(requirementFor("autonomous", "deletion"), "independent");
assert.equal(requirementFor("manual", "deletion"), "person");
assert.equal(requirementFor("autonomous", "payments"), "human_only");
```

## An independent agent approves

Where an approval is needed, a second agent counts as the approver. **Independent** means a different principal from the one that acts, outside its token lineage (a token an agent minted, or the one that minted it, is not a second pair of eyes), with no shared run or lease. The approval records the actor, the approver and whether it was an agent or a person, the evidence it checked, the reason, and the class. A person can always approve, override or undo.

```js run
const actor = { kind: "agent", id: "tok_a" };
assert.equal(isIndependent(actor, { kind: "agent", id: "tok_b" }), true);
assert.equal(isIndependent(actor, actor), false);
assert.equal(isIndependent({ ...actor, rootId: "root" }, { kind: "agent", id: "tok_b", rootId: "root" }), false);
assert.equal(isIndependent(actor, { kind: "user", id: "u_1" }), true);
```

When an agent is refused it gets `autonomy_approval_required` with the class, what it needs and the exact subject:

```sh
overlane task policy set relaxed --reason "docs-only repository"
# exit 6: autonomy_approval_required [approval: class task_policy, needs approval, subject "PUT /v1/tenants/T/projects/P/queue/policy"]

overlane autonomy approvals request --class task_policy --subject "PUT /v1/tenants/T/projects/P/queue/policy" --summary "Docs-only repository"
# another agent, with its own token:
overlane autonomy approvals answer apr_1a2b --decision approve --reason "matches the repository" --evidence "read the tree: only docs"
# the first agent retries with the approval:
OVERLANE_APPROVAL=apr_1a2b overlane task policy set relaxed --reason "docs-only repository"
```

An approval covers one subject, is valid for an hour, and is used once. The principal that asked cannot answer its own approval. An agent approver of a safety class must list its evidence and a reason. Under `manual`, only a person's answer counts.

## Over HTTP and MCP

| Operation | HTTP | MCP |
| --- | --- | --- |
| Read the mode | `GET /v1/tenants/{tenantId}/autonomy` | `autonomy` `show` |
| Change it | `PUT /v1/tenants/{tenantId}/autonomy` | `autonomy` `set` |
| Request an approval | `POST /v1/tenants/{tenantId}/autonomy/approvals` | `autonomy` `request` |
| Answer one | `POST /v1/tenants/{tenantId}/autonomy/approvals/{approvalId}/answer` | `autonomy` `answer` |

Present an approval on the retry with the `x-overlane-approval` header (the CLI reads `OVERLANE_APPROVAL`), or the `approvalId` field of an MCP tool. Every decision is a pure function of the mode, the class and the recorded approval: no model decides.

## Commands

- [`overlane autonomy show`](/cli/autonomy-show/), [`autonomy set`](/cli/autonomy-set/)
- [`overlane autonomy approvals list`](/cli/autonomy-approvals-list/), [`request`](/cli/autonomy-approvals-request/), [`answer`](/cli/autonomy-approvals-answer/)
- [Agent sign-in](/agent-tokens/), [Teams and roles](/teams-and-roles/), [Dry-run and approvals](/review/dry-run-and-approvals/)

Source: https://docs.overlane.app/autonomy/index.mdx