Email

Email is where the platform's inbound work becomes tractable: a full mail cockpit for your own accounts, a triage queue that survives between sessions, and an agent that reads the queue, researches answers, and drafts replies.

The agent's replies default to a draft you approve — but not unconditionally. A standing authorization exists, it covers a narrow class of messages, and it is set both globally and per routine, so what is actually authorized is a combination rather than a single switch. The Agent tab carries one readout whose whole job is to state that answer; read it before you enable an email agent for the first time. The reasoning behind the design is on Autonomy & controls — this page is about the switches themselves and where they live.

The view sits in the sidebar under Mission Control, below Calendar. Both carry scheduled and queued outbound work.

Accounts

Command Center speaks plain IMAP and SMTP, so it works with any provider that does — there is no integration to buy and no mailbox to migrate. You can configure several accounts and pick a default.

Account setup lives at Settings ▸ Email, which is the single place accounts are created and edited; this view only reads them.

A password resolves in a fixed order: the OS keychain first — the recommended store, and the only one that keeps nothing in plaintext on disk — then a password field written directly into your configuration file (possible, and discouraged), then the environment variable the account names. An account whose password resolves nowhere is treated as disabled rather than failing mid-send, so a half-configured account is inert instead of noisy.

The tabs

Mail — the working cockpit: folder list, message list, reading pane, with compose, reply, forward and the usual message actions (move, delete, mark read or unread). Attachments work in both directions: download from a message, and attach outgoing files up to 25 MB per message. Attach from the file picker or by pasting — dragging a file onto the window does not attach it. The composer also carries recipient pills with autocomplete from your contacts, a Cc/Bcc reveal, optional Markdown formatting (sent as HTML when you turn it on), and a five-second undo window after you press Send. Two alternatives to sending now sit beside it: Send later, which hands the message to the Calendar as a scheduled entry, and handing the message to the email agent, which polishes it and then follows the same approval rules as any other outbound message.

Agent — the dispatch surface for the email agent, in three cards:

• Drafts awaiting approval — each draft the agent produced opens in the composer, addressed and pre-filled, for you to edit, send or discard; settling a draft also settles the queue entry behind it. The global Auto-approve default and the auto-send readout sit here too (see What the agent may send on its own).
• The routines card — the non-removable base email-agent plus every variant you create, each an email-agent-<name> routine with its own Run now, schedule, Auto-send switch, report, log, editor and dry run. A variant's standing defaults — its operator instructions, the identity files it writes from, and the accounts it is scoped to — are edited on its own row. The base row additionally hosts Autorun and the account scope every variant inherits when it names none.
• Scheduled sends — the messages you composed here to go out later, visible and cancellable before they leave.

Queue — the shared triage queue. The inbox watcher and the email agent both write rows here; you triage them by status, classification and notes. Classification is deliberately free text rather than a fixed list, and the filter offers whatever classifications actually exist in your queue instead of a guessed set.

Contacts — the address book behind the composer's recipient autocomplete. Add contacts by hand or import a set, group them by category, and search them. It is global rather than per-account.

Email Reports — the run reports, grouped by day, with outcome chips (drafts, errors, empty runs), search across both filenames and report bodies, and a per-run drill-down that joins the drafts that run produced.

The watcher and Autorun

Two switches decide how much happens while you are elsewhere, and both are on by default:

• The inbound watcher is the power control at the top right of the tab bar. It polls your mailboxes and files new mail into the queue, so triage work accumulates instead of restarting from an inbox scan each session. Clicking the control reveals status — running or not, the poll interval, the last error. It runs no model and costs nothing to leave on.
• Autorun lives on the base agent's row in the Agent tab. When a poll pass queues new mail, it dispatches the email agent — debounced, so a burst of arrivals is one run rather than one run per message. That run spends model usage on your own account.

Both are inert until you connect a mailbox: on a fresh install no account has a resolvable password, so the watcher waits quietly rather than reporting a failure, and nothing is dispatched. The consequence is worth stating plainly: connecting a mailbox and enabling the email agent is what starts unattended agent runs. There is no further opt-in after those two steps. The base email-agent routine ships disabled, and that is what holds Autorun back until you decide.

What the agent may send on its own

Per-message approval is the default. The agent writes a draft, the draft appears in Drafts awaiting approval, and you open it in the composer to send, edit or discard.

A standing authorization sits beside it, and it is deliberately narrow. Where it applies, a draft sends immediately and unattended. It applies to two things and nothing else:

• a reply to a message already in your queue that cleared the agent's own confidence gate, and
• a message you composed yourself and handed to the agent to finish.

Everything else always takes the per-message path, whatever the switches say: a reply that needs more information from you, anything the agent judges personal or human-only, forwards, mail from senders you have flagged, and a fresh message to a recipient you have not addressed.

Two controls decide whether it applies, and the more specific one wins:

• the global Auto-approve default in the Agent tab, which ships off; and
• each email routine's own Auto-send switch, which overrides that default for that routine in either direction.

The second of those is the one that surprises people: the global switch being off is not by itself proof that nothing will send, because a routine carries its own setting.

This is not hypothetical, and it applies to the routine you are most likely to turn on first. The email agent that ships with the product has auto-send enabled in its own configuration. It is inert only because the routine itself ships disabled — so enabling it authorizes it to send replies in the class described above, whether or not the global default is on. That is a deliberate design (the routine's own switch is the more specific one, and it wins), but it means enabling the email agent and authorizing it to send are one action, not two.

That is why the Agent tab has a readout whose only job is to answer is anything auto-sending right now — it names every email routine whose effective setting is on, or states plainly that none is, and it links straight to the master stop below. Check it before you enable an email agent, and again after you create a variant. If you want an agent that drafts but never sends, turn that routine's own Auto-send off; the global default will not do it for you.

If Send stops working

If a Send button stops working — in your own composer, in the agent's drafts, or in the newsletter dialog, which disables Send and states the reason — check Settings ▸ Terminals ▸ Agent control planes ▸ Email sending first.

That switch answers one question: right now, may mail leave this machine? While it is off, nothing does. It is worth being precise about the scope, because the switch is easy to read as agent-only:

• It stops your own composer too, not only agents. Your composer does not go through the agent tooling, but both paths converge on the same mail client underneath, and the stop lives inside that client. That placement is deliberate, and the in-app description of the switch has not caught up with it — what this page describes is what the product does.
• Reading, searching, triage and saving drafts keep working, so a message an agent composes waits as a draft instead of vanishing.
• It fails open: if the configuration file is missing or unreadable, sending stays available. A switch that failed closed on a parse error would look exactly like a broken feature.

It is a capability switch, not a policy: it sits above every routine's Auto-send setting and overrides all of them. See Autonomy & controls for how it relates to the other control planes.

What an agent-sent message carries

Mail the agent sends is marked as machine-sent, which is buyer-relevant whether or not you ever look at a header:

• An AI disclosure line is appended to the body when the agent labels the message as AI-authored, in the language the message is written in. This is the EU AI Act transparency posture applied per message rather than promised in prose.
• An automated-mail header is set on every send, reply and forward the agent makes, regardless of that label. This is the loop breaker: an automated reply arriving at another watched mailbox is detected as automated and is not answered back, so two of your own mailboxes cannot end up writing to each other forever.
• A copy is filed to Sent, best effort — the send itself is never reported as failed because the filing did not land.

Drafts deliberately carry neither the disclosure line nor the header. A draft is sent later by you, from the composer, and that is not an automatic process.

Where to go next

• Autonomy & controls — the model behind the switches on this page
• email server — the same mailbox surface as agent tools
• Calendar — scheduling a message to send later
• Company Identity — the files the email agent writes from
• Routines & automation — running the agent on a cadence