Routines

A routine is standing work on a schedule — the things an agent is responsible for every day without anyone asking. "Every weekday at 6pm, summarize what you did and email the team." "Every morning, reconcile yesterday's invoices against open orders."

What a routine is

A saved schedule plus a stored instruction. When it fires, it starts an ordinary task against the agent. That's the whole trick: routines don't add a second execution engine, they schedule the one that already exists.

Everything that makes tasks safe therefore applies unchanged — credential scoping, the task lifecycle, progress heartbeats, escalation parking, and the automatically materialized outcome.

What a routine carries

Working hours

A routine on an hourly cadence fires all night. When the work produces something a person has to act on — an exception report, a chase-the-vendor pass, a replenishment sweep — the 3am firings are pure cost: nobody is in the building, and by morning the work has to be redone against fresh state anyway.

Turning on only run during set hours confines a routine to a span of the local day (say 8am to 5pm) on the weekdays you choose. Outside that window it doesn't fire — it holds, and runs once the moment the window next opens. So the overnight work still happens, once, in the morning, against current state, in front of someone who can act on it. Twelve missed overnight slots produce one morning run, not twelve.

The window is local time and follows daylight saving, which is why it carries its own time zone. A cron expression is still written in UTC; the window is the part that tracks the clock on the wall.

Run now ignores the window — a person asking for a run right now is the whole point of the button.

The hard part isn't scheduling

Firing a job on a timer is easy. Making a write-capable, all-day, unattended agent safe is the actual problem, and the design leans on four ideas:

Idempotent reconcile. A routine should be written as "make the world match this state", not "do this action". A reconcile that runs twice is harmless; an action that runs twice buys the same thing twice. Instructions like "for every open order with no matching invoice, create a draft" survive a double firing. "Create drafts for yesterday's orders" does not.

Overlap control. A routine doesn't start a second run while the first is still going, so a slow morning doesn't produce two agents racing on the same work.

Knowing when there's nothing to do. A routine that finds no work should say so cheaply and stop. Runs record a verdict — including "nothing to do" as a distinct, successful result — so a quiet day reads as quiet rather than broken.

Escalating the risky tail. The routine handles the ninety percent that's clear-cut and escalates the rest instead of guessing. Because escalation parks the task rather than failing it, a routine that stops to ask at 6am is still sitting there, work intact, when someone answers at 9.

Budget and approval

Two ceilings worth setting deliberately:

• Spend cap bounds what one routine can cost per day. An agent working unattended has no natural stopping point; this is it.
• Approval threshold forces sign-off above a limit you choose, routed through the escalation inbox.

Together they're the answer to "what happens if it goes wrong at 3am": it stops and waits, rather than continuing at speed.

Reviewing runs

Every firing is recorded — whether it was scheduled or triggered by hand, what verdict it reached (success, failure, skipped, or nothing to do), the task it dispatched, any sub-tasks that task delegated to other agents, and the outcome the agent wrote.

An agent can read its own routines and run history too, which is what lets a weekly summary routine report on the daily ones.

A routine that fails repeatedly trips a circuit breaker and stops firing rather than failing on a schedule forever.

Managing routines from an MCP client

Everything on the Routines page can also be done over MCP: list, read, create, change, pause, and delete. A signed-in user manages the routines of any agent in their organizations, so asking Claude to "have the purchasing agent sweep replenishment every weekday morning" builds the routine.

Agents on the platform can read routines — every routine in their organization, with its history — but never change one, not even their own. A routine's instructions are standing orders from a person, and they stay that way.

The rules are the console's: the same validation, the same defaults, and the same revision history — every change to a routine's instructions or settings is kept and credited to the person who made it.

Writing good instructions

• Describe the desired end state, not a sequence of actions.
• Name the exceptions you want escalated, explicitly.
• Say what "nothing to do" looks like so a quiet run terminates cheaply.
• Ask for concrete reporting — numbers, names, and what was skipped. That text becomes the outcome a manager reads.
• Start it paused, run it by hand a few times, and watch the runs before letting it loose on a schedule.