Scheduled run
Tasks that the agent runs at a time or on a trigger.
The moment your agent runs without you watching, you have a production system. Scheduled runs look like a small feature: pick a time, the model does the thing. In practice they are the most consequential surface in an agentic product. They execute on behalf of a user who isn't present, using credentials that are, and leave behind a result that nobody is guaranteed to read.
A scheduled agent that doesn't tell you what it did is a script with worse manners. The pattern makes the next run legible, the last run auditable, and the pause absolutely unambiguous.
"Scheduled runs are promises. Make them keep receipts."
Next run, last run, and a pause.
Three surfaces. First, the next-run preview: the exact trigger, the exact input, the exact tools the agent will use. Second, the last-run receipt: what it did, what it cost, what it produced, linked to the artifact. Third, a pause that reads as a pause in the interface, not as a subtle state change buried in a menu.
A pause should change the visible state of the job row from something active-colored to something clearly parked. Users who glance at the dashboard should be able to tell which jobs are running, which are paused, and which are broken, in a single sweep of the eye.
- Inputs at next run
channels: #eng, #product · window: 24h
Last runtoday · 08:30 · 4 edits summarized
Absent users are the riskiest users.
When the user is present, they can correct the agent. When the agent runs at 3am on a Tuesday, the only correction available is the one the interface baked in beforehand. Scheduled runs need more structure than interactive ones, not less. The preview is the moment to negotiate; the receipt is the moment to verify; the pause is the moment to intervene.
The easy failure is a scheduler that works fine until it doesn't, and then quietly stops. The user discovers the silence weeks later. A surface that shows last-run status loudly prevents this.
The scheduler I'd ship.
- A next-run preview with the actual input. Not "summary of yesterday's emails" but the count, the sources, the tools. Previews are how a user catches a misconfigured job before it runs 30 times.
- Receipts that link to artifacts. A scheduled run that produces a document should leave a link back to the document on the row. "Done" is a lie; "done, here's the output" is a truth.
- Pause means paused. The visual state of a paused job should be unmistakable. If a user has to read the label to know, you've designed the affordance wrong.
Drift while you sleep.
The subtle danger of scheduled runs is drift. The upstream data format changes; the agent adapts without complaint; the output quietly becomes wrong. A good scheduler shows a confidence or similarity score on each receipt so drifting runs stand out against their historical baseline.
The pattern is not "automate and forget." It's "automate and keep the lights on."
What this pattern gets wrong when it gets wrong.
- Orphaned task
- A task that was started, never completed, and is no longer visible in the interface, even though compute may still be running.
- Silent cost bleed
- The product spends time, tokens, or money without surfacing the cost at the moment it is incurred.
- Throttle silence
- A rate limit, queue, or budget cap that silently slows or stops the product without telling the user why.
Three shipping variants worth copying.
- A per-task next-run preview with the exact inputs it will use
- A run-history list, newest first, with receipts you can click
- An unmistakable pause badge that persists across reloads