Calendar
Date-addressed scheduling — put work on a moment in time and let an agent do it when that moment arrives.
Routines answer the question "every how often?". The Calendar answers a different one: "at this moment." It is the only place in Command Center where work is addressed by a date and time rather than a cadence — and when that moment arrives, a Calendar entry does not run a script. It dispatches an agent, or stands up the workspace you would have opened yourself.
That distinction is the whole point of the view. "Draft the quarterly summary every Monday" is a routine. "Work the migration mission on Thursday at 14:00, while I am out" is a Calendar entry.
You find it in the sidebar under Mission Control, between Missions Board and Email.
Calendar is a Pro surface — see Tiers: Pro & Ultra. It dispatches agents at up to full reach, which is why it sits with the rest of the platform core rather than in the shell baseline.
The layout
- The week grid is the main surface: day columns against a vertical hour axis, with entries drawn at their instant. Wider scales are available for looking further out.
- The header carries the two ways in — Sketches and New entry —
plus the scale control, the dispatch switch (
Armed · N running), and a health indicator that appears only when something needs attention. - The composer rail opens on the right with the Entry and Sketch. It is both the creation surface and the edit surface; there is no separate modal.
- The occurrence drawer opens when you click a scheduled firing, and shows its status, its run history, and a link to the report the run produced.
Marking time is always live. On empty grid, one pointer gesture gives two outcomes by distance: press and release creates an entry at that time; press and drag marks an area. Hold Ctrl (⌘ on a Mac) while dragging to add a second area rather than replace the first. Re-marking while a form is open re-times it without discarding what you have typed.
An entry's length is an annotation, not a run window. Every entry fires once, at its start. The Ends field describes how long the block is drawn for and nothing else, and an entry longer than a day leaves the hour grid for a bar across the top of the week rather than being painted as hours of activity that never happen.
The kinds of entry
The Type picker in the composer offers these chips:
| Type | What fires | Runs as |
|---|---|---|
| Note | An annotation at that moment. Give it a recipient and it is emailed to that address instead, with the title as the subject | Nothing at all, or the mail engine |
| Agent | A one-off job you describe in prose | An agent |
| Mission | An action against a mission — work on it, activate it, or launch its fleet | An agent, in a terminal workspace |
| Workspace | A pre-configured terminal workspace, stood up at the scheduled time | Your terminals — no agent dispatch |
| Routine | An existing routine, at a specific moment | The routine itself |
| A message you composed earlier, sent later | The mail engine |
Agent and Mission dispatch an agent. Routine and Email are mechanical — the daemon does the work directly, with no tokens spent and no session to watch. A Note with no recipient never executes at all; give it one and it becomes a scheduled message, which is why the two share a chip. (A recipient is the only thing that separates them, so the picker asks for the recipient rather than asking you to pick between two words for the same intent.)
Workspace is not an agent dispatch, and the difference matters. It stands up the terminals you configured — count, what each runs, model and effort, contexts, first message — with everything already set. There is no brief, no autonomy level, and no report contract: it is the workspace setup dialog on a timer. The occurrence is complete the moment the workspace opens, because launching is the job.
Every entry can be armed, paused, or archived, and every entry records who created it — you or an agent.
Repeats
An entry runs Once by default, or repeats Daily, on Weekdays, or Weekly. When it repeats, an Until date appears: set it and the series runs through that day inclusive; leave it empty and the series has no end — the board materialises about a month ahead and extends as you look further out. Until is the end of the series; Ends is how long one occurrence is drawn for.
How an agent-dispatched entry runs
Two execution modes, chosen per entry:
Background — the agent runs headless, through the same runner that executes routines. Nothing opens; the work happens and a report lands on disk. This is the right mode for work that needs no watching.
Terminal session — the entry opens a grounded terminal workspace named after it, with one pane running a full agent session. You can watch it, read it, and intervene. Because that workspace is a surface of the app, this mode needs Command Center to be open when the entry fires; if the app is closed, the firing is recorded as missed rather than hanging silently.
Either way the entry is handed a brief — a generated file that states the job, names the strategic files to read by path, resolves any attached mission, and reserves the path the run must write its report to. The brief is written per firing and stays on disk beside the report, so what a run was actually told is readable after the fact rather than inferred from its output.
A terminal-session run is considered finished when its report file appears, with a six-hour ceiling. There is no exit code to read — the pane outlives the agent's turn — so a run that does the work but writes no report is recorded as a timeout. The report is the completion signal, not a side effect.
Autonomy — a ladder of reach
An agent-dispatched entry carries an autonomy level, and the level is a statement about what the agent may do, not about how carefully it works:
| Level | The agent may |
|---|---|
| Report only | Read, investigate, and write its report. Nothing else changes. |
| Build | Also create and edit files in your workspace. |
| Full | Also act outward — send, publish, push. |
A level has to be able to do the thing it is named for: an entry set to full whose job is "send the summary" is asking for the summary to be sent. What that reach costs is account — a run at full states in its report exactly what went out. Reversibility still binds at every level: no deleting without a backup, no overwriting someone else's work.
Where you choose, and what you get if you do not. The level chooser appears on a background Agent task — the unattended case, and the one where the decision is genuinely yours to make. A terminal-session run does not show it and comes up at full, deliberately: that session is on screen, and you can read it and take over. A Workspace entry stores a level but never consults one, since nothing on that path reads a brief.
The stored default for every agent-dispatched kind is full. That is a decision rather than an oversight. A dispatch that changes nothing and sends nothing is not a safe dispatch, it is one that will not do its job — and an operator who must raise the level before every single unattended entry is being trained to click rather than to decide. Turning it down is one click, and an explicitly lower level is always honoured. Autonomy & controls states the whole model, including the switches that sit above it.
Plan a week with a sketch
Sometimes you know the shape of a week before you know its entries. A sketch is freeform intent written over one or more marked areas of the grid: "two deep-work blocks for the migration, and a review pass on Friday afternoon."
A sketch is inert by construction. It lives in its own store and the clock never reads it — whatever it contains, it cannot fire.
- Mark the areas. Drag across the grid for the first window; hold Ctrl (⌘ on a Mac) and drag again to add a second rather than replace the first.
- Write what you want to happen in the composer's Sketch tab. Prose, not fields — your constraints matter more than your phrasing.
- Send the draft somewhere. Three buttons, and they are three different
decisions:
- Save — keep it as a draft. Nothing is dispatched and nothing is scheduled. Saved sketches stay on the grid as dashed, titled blocks; click one to work on it, the same as any other object.
- To entry — turn it into a single scheduled entry yourself. Title, time and text carry over into the entry form, so you set the type and the autonomy level before saving. No agent runs.
- Configure via agent — hand it to an agent, which creates the entries.
- Read what it made. A configure run receives your text verbatim, each area in both your local time and UTC, and what is already scheduled in and around those areas, so it does not double-book you. Everything it creates is stamped as coming from that sketch.
- Undo in one action if it read you wrong. Undo this configuration deletes every entry the run produced and returns the sketch to a draft — and it covers everything actually stamped, not only what the agent said it made. That undo is what makes it reasonable to let the agent be bold.
Deleting a sketch is a different action from undoing it: entries a run already produced are real schedule, and deleting the sketch leaves them alone.
Your agents can leave sketches too. That makes a sketch a proposal inbox as well as a planning tool — an agent that thinks something belongs on Thursday can say so without putting anything on the clock.
When something is wrong
A health indicator appears in the header only when there is something to see, and distinguishes four states:
- Failed — the run started and did not succeed.
- Missed — the moment passed with nothing able to run it (the usual cause is a terminal-session or Workspace entry firing while the app was closed).
- Overdue — past its instant and still waiting on capacity.
- Misconfigured — armed but unable to ever succeed, such as mission work with no mission attached. This is the one worth acting on early: it is caught before the entry fails unattended.
Occurrences move through a visible lifecycle — scheduled, due, claimed, running, then one of succeeded, failed, timed out, missed, skipped or cancelled. You can re-run a firing that failed; the history appends rather than overwrites, so the earlier attempt stays readable.
The controls that govern it
Two switches and two records, because authoring and firing are different questions:
- Calendar dispatch — the master switch for whether anything fires at all.
It is the pill in the Calendar header (
Armed · N running, orDispatch pausedonce you click it). It is deliberately not on the Dashboard's day card: a live toggle for all scheduled firing, sitting on a glanceable card, would let one misclick silently disarm the machine. - Calendar control (Settings ▸ Terminals ▸ Agent control planes ▸ Calendar) — whether agents may author schedule. Turning it off refuses agent writes while agent reads keep answering, so an agent can still see what is scheduled and plan around it. It never gates you — your own edits are unaffected.
- Provenance — every entry records whether you or an agent created it, and that record stays with the entry rather than following whoever last edited it.
- An audit log — every agent write to the schedule is recorded, refusals included.
Three further settings have no control in the interface: how many scheduled runs may execute at once, how far ahead the board is materialised, and how long finished occurrences are kept. Each has a working default and each is overridable as a configuration key — see Configuration. The concurrency cap and the horizon are also readable in the dispatch pill's tooltip.
This shape is deliberate. Oversight that works means being able to see, interrupt and disable — not a consent prompt per action, which trains reflexive approval and supervises nothing.
Where to go next
- Autonomy & controls — the reach ladder and every switch above it, in one place
- Routines & automation — the cadence-addressed sibling, and how to choose between them
- Missions, operations & the fleet — what mission work entries act on
- Terminals — the workspace a Workspace or terminal-session entry opens
- calendar-mcp — the same surface for your own agents