Scheduled Autonomous Runs

Creating a run

Open Scheduled Runs under the Workspace group. Admins can create one from a template — a morning work plan, a weekly report, a client digest — under 'Start from a template'.

The easier path is often to ask. 'Every weekday at 8am, email me what I should work on' creates the schedule, and it resolves the time in your profile timezone rather than making you convert to UTC.

Schedules are managed, edited and paused from Settings → AI Agent.

Note that arming or re-arming a recurring run is itself a governed action in the AI-spend category — each fire is a full billed model loop, so creating one is treated as spending rather than as configuration. Cancelling is not gated, because stopping spend needs no permission.

Reading the output

Each run's output appears under its schedule once it fires. Expand the schedule to read what past runs produced.

When the output is surprising — too thin, wrong, or oddly generic — open the full run transcript in the agent chat. The transcript shows what the run actually did: what it looked at, what tools it called, what it found.

This is the diagnostic that answers almost every question about a disappointing run, and it is worth doing the first time each new schedule fires rather than waiting until you are annoyed.

Failure mode one: the toolless run

The most common way a schedule disappoints is that the run had nothing to work with.

A run executes with a toolset determined by the same governance as everything else — the workspace ceiling, the persona's scopes, what is connected. A schedule created to summarize the week's mail, running as a persona with no email scope, produces a plausible-sounding summary of nothing.

The symptom is output that is generically correct and specifically empty. The check is the transcript: if the run made no tool calls, or made calls that returned nothing, the problem is capability rather than prompt.

So when you create a schedule, verify the first fire. Read the transcript once. It takes a minute and it catches this immediately.

Failure mode two: nobody reads it

The other failure is quieter. The run works, produces a good output, and nobody opens it.

This costs credits every fire, forever, and nothing surfaces it — a schedule that nobody reads looks exactly like a schedule that everybody reads.

Two defences. Deliver where the audience already is: an emailed run is read, a run whose output sits in the app is usually not. And review your schedules quarterly, asking one question per schedule — what did the last one say? If nobody can answer, pause it.

Pausing is free and reversible. A schedule you were unsure about is better paused than kept out of politeness.

What to schedule

The runs that reliably earn their cost share a shape: they produce something a person acts on, at a moment they can act.

A morning work plan, delivered before the day starts. A Friday project summary, delivered before the weekly review. A client digest, delivered before the client call.

The ones that do not earn their cost are the ones that report on a thing nobody was going to change — a weekly metrics dump with no decision attached, a status summary of a project already discussed daily.

The test before creating one: what will someone do differently because this arrived? If there is no answer, do not schedule it.