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.
overlane autonomy show
overlane autonomy set supervised --class release_promotion=manual
overlane autonomy set autonomous --project my-app=supervisedThe 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.
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.
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:
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.