Routines
Standing work on a schedule, with the guardrails that make unattended autonomy safe.
On this page
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
| Setting | Purpose |
|---|---|
| Schedule | When it fires |
| Instructions | The work, written as you'd write it to a person |
| Spend cap | A per-day ceiling on what this routine may cost |
| Timeout | How long one firing may run |
| Connection | Optionally, a specific delegation or drive thru connection to use |
| Enabled | Paused routines stay configured but never fire |
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.
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.