Autonomy and controls

Delegation is only worth something if you know its edges. This page states them: how far a dispatched agent may reach, where that reach is chosen for you, which switches stop each outward action, and what is written down afterward.

The posture behind all of it is worth saying first, because it is not the one most products advertise: autonomy is the default, and the switches are where you turn it down. A system that asks permission for every action does not produce oversight — it produces a habit of clicking through prompts, which is oversight in appearance only. What you get instead is a small set of switches that genuinely stop things, a record of what happened, and a reach you set per dispatch.

Reach, not care

Every agent-dispatched Calendar entry carries an autonomy level. The level is a statement about what the agent may do — not about how carefully it works. The care is constant.

Full is a working level, not a failure state. A mode has to be able to do the thing it is named for: an entry whose job is "send the summary" and whose level forbids sending is not a cautious entry, it is one that cannot finish. What full owes in exchange is an account — a run at full is required to state in its report exactly what went out, to whom, where it was published, and what was pushed to which branch. An unattended outward action you cannot reconstruct afterward is the real failure at that level.

Two rules bind at every rung. Reversibility: no deleting data without a backup, no overwriting work that is not the agent's — those stop and come back to you even at full. And honest reporting: a run that reports blocked with a clear reason is worth more than one that reports done having quietly done something adjacent.

It is worth knowing how a level reaches the agent. When an entry fires, the platform writes that run a dispatch brief, and the level becomes the brief's guardrail section — report only and build share one rail ("nothing leaves the machine at this level"), full replaces it with permission plus the accounting obligation. So the level is how you shape a run. What stops a run is the control planes below, which are enforced in code rather than in words.

Where you choose it, where you inherit it, where it does nothing

The chooser is not on every entry, and the starting point is not the cautious one. Stated plainly:

• The three chips render for a background agent task only.
• A new entry of any agent kind — agent task, mission work, workspace launch — is stored at full unless you lower it. The mechanical kinds (a note, a reminder, a routine run, a scheduled message) sit at report only and never stand up an agent at all.
• An agent task you send into a terminal session comes up at full and hides the chips deliberately: that run is on your screen, you can read it as it works and take the keyboard at any point.
• On a Workspace entry the value is inert. That kind opens a configured workspace and writes no brief, so there are no rails to carry.

Turning a level down is one click on a background task, and an explicit report only is always honored — including one an agent authored, because a stored level is never quietly raised by an edit elsewhere in the entry.

Outbound is governed by switches, not by a universal draft queue

Per-message approval is the platform's default posture for mail addressed to another person. It is not a law of the product, and there is no single queue that every outbound message must pass through. There are paths with different behavior, and one master stop across all of them.

The standing authorization deserves precision, because it is the one switch that turns per-message approval off. email.auto_approve_drafts is narrow: it lets a reply-disposition draft that passed the agent's own confidence gate send immediately. Everything else — a reply that needs more information, anything classified human-only or personal, forwards, and mail from senders you have flagged — takes the per-message path regardless. It ships off, on purpose: a decision to let an agent answer a customer unattended is a switch you set, not a default you inherit. A single email routine can carry its own setting, and Email ▸ Agent shows in one readout whether anything is currently authorized to send.

The master stop, and the thing it also stops

Settings ▸ Terminals ▸ Agent control planes ▸ Email sending answers one question: right now, may mail leave this machine? Turn it off and send, reply, and forward are refused. Reading, searching, and saving drafts keep working, so a message an agent composes waits as a draft instead of vanishing.

It stops your own composer too, and that is deliberate. Your composer does not go through the agent tool surface — but it does go through the same mail client underneath, and the stop lives inside that client. While Email sending is off, nothing leaves this machine by mail, agent or human. A stop with an exception is a stop that gets routed around, and that argument won over threading an exemption through for the composer.

This is the manual's most commonly misread failure mode: if your own Send button stops working while drafts still save and reads are fine, check this switch first.

The control planes

Settings ▸ Terminals ▸ Agent control planes holds one switch per plane. Four of them answer a single question about what agents may do unattended. The fifth, Email sending, is broader by design — it stops outbound mail from this machine, yours included.

Three properties they share:

• Hot. A flip applies to the next call. Nothing restarts, and no run in flight is left in a strange state.
• Fail-open. If the configuration file is missing or unreadable, a plane reads as on. This is deliberate: a switch that failed closed would look exactly like a broken feature, and you would spend an afternoon debugging it instead of noticing that something had been switched off. A stop should be something you turn on and see the effect of, not something that arrives by accident.
• They govern agents, not you — with the one email exception above. The rule is not "a plane never affects the operator"; it is that a plane gates whatever shares its enforcement point. Your Cortex edits reach the graph through a different service than the agent tool does, so knowledge-graph writes really do leave your own curation alone. Mail's two paths converge on one client, so it does not.

The terminal plane has a second, faster control that needs no configuration change: a pause in the Terminals view halts all agent terminal activity at once. A paused plane refuses mutating calls while reads keep answering, so you can still see what a fleet was doing when you stopped it.

Autonomy is not authority

A level governs what that run may do. It does not govern what an agent may author.

The clearest case is the schedule itself. An agent can create and adjust Calendar entries — including at a higher level than the run it is currently executing — at any rung, because that surface answers to Calendar control and to the calendar's dispatch switch, both of which are yours, and every such write is recorded. Report only therefore means something narrower than it first reads: such a run cannot send your mail, and it can propose and schedule work. When a task needs a reach the current run does not have, scheduling it is a legitimate move rather than a loophole — and the run is expected to say in its report what it scheduled and at what level.

Coordination bookkeeping is likewise free at every level. A fleet worker transitions its own operation, releases its claim, and files its notes whatever its rung says, because those are the fleet's books rather than a change to your project. Declaring a whole mission complete is not bookkeeping — that is a judgment about whether the mandate was met, and below full an agent proposes it in its report instead of doing it.

The calendar's two switches ask different questions and are set independently:

What is recorded

Provenance travels with the record. Every Calendar entry and every sketch stores who created it — you or an agent — and that field is the record's origin, so it never changes when someone edits the entry later. Because provenance is immutable, a change an agent makes to an entry's autonomy is recorded separately, naming the level before and after. An entry that reads "created by you, running at full" can no longer hide the fact that you did not choose the level.

Audit logs, by path. Each is a plain append-only text file in your workspace, readable with anything:

Mail is the exception, in the other direction. Agent sends do not get a dedicated log file — what they leave instead is the message itself: filed to your Sent folder, carrying a header that marks it as machine-sent, and, when the agent labeled it, the AI-disclosure line in the body. Drafts you send yourself carry neither. Email ▸ Email Reports groups what each run handled, by day.

The rest is visible rather than logged, which is usually better: fleet agents work in ordinary terminal panes you can watch and take over, and every run at full owes a report that states what went out. The report file is where you read it the next morning.

Not the same thing as your subscription

Control planes fail open — in doubt, they let the work happen. Subscription enforcement is the opposite: it fails closed, and refuses capability rather than granting it. So if a tool or a view answers "subscription required", nothing on this page is the cause. That behavior is described under Tiers.

Where to go next

• The operator model — the working model these controls serve
• Calendar — where a level is set, and the entry kinds that carry one
• Email — the mail cockpit, its drafts, and what to check when Send stops working
• Settings — where every plane lives
• Configuration reference — the keys behind each switch