Key facts
| Triggers | Cron, queue workers or workflow schedulers |
| Idempotency | One run key per schedule slot so retries do not duplicate work |
| Timezones | Store schedules in UTC and render them in the tenant timezone |
| Catch-up | Define whether missed runs execute late, skip or coalesce |
| Concurrency | Cap parallel runs to protect downstream systems |
| Budgets | Per-run token, time and spend caps |
| Review queue | Route exceptions to humans rather than failing silently |
| Status | Function calling and agents are live; batch endpoints are coming soon |
TL;DR
- Unattended runs fail differently: nobody notices, so alerting is the product.
- Give every scheduled run an idempotency key tied to its time slot.
- Define UTC schedules and explicit catch-up and skip behaviour.
- Cap concurrency and per-run budgets to protect downstream systems and spend.
- Send exceptions to a human review queue with the full trace attached.
How it works, step by step
- Describe the recurring job and its output, and confirm it benefits from a model at all.
- Choose a trigger: cron for fixed times, queue workers for event or backlog-driven runs.
- Assign each schedule slot a run key so retries cannot duplicate actions.
- Define timezone handling and what happens to missed or overlapping runs.
- Cap concurrency, set per-run token, time and spend budgets, and add a global kill switch.
- Route failures and low-confidence results to a review queue with the trace attached.
- Monitor run success rate, duration and cost trend, and tune the schedule accordingly.
Try it yourself
Open the agent workflow designer →
Unattended changes the failure model
A conversational agent has a human watching. A scheduled agent does not, which means every weakness compounds quietly: a bad prompt produces wrong reports every morning, a failing tool retries all night, and duplicated runs send the same customer email twice. Reliability engineering matters more here than prompt cleverness.
The first question is whether the job needs a model at all. Scheduled classification, extraction, summarisation and anomaly detection are good fits. Jobs with deterministic logic should stay deterministic, with the agent handling only the judgement steps.
Designing the schedule and the run
- Trigger: cron for fixed cadence, queues for backlog-driven work; both should feed the same run handler.
- Run key: a deterministic ID per slot, used as the idempotency key for side effects.
- Overlap policy: skip, queue or cancel the previous run when schedules collide.
- Catch-up: decide explicitly whether late runs execute, coalesce into one or are skipped.
- Budgets: turn, token, wall-clock and spend caps per run, with a kill switch.
- Output contract: write results to a known location and mark confidence so review is targeted.
Operations: alerting, review and cost
Treat each scheduled agent as a production service with an owner, an SLO and an on-call path. Alert on consecutive failures, unusual duration, spend anomalies and output drift. Silence is the enemy: a run that fails without an alert is indistinguishable from a run that produced nothing to report.
Human review should be targeted, not universal. Route low-confidence items, policy exceptions and anything above a value threshold to a queue. On Plugsky, function calling, streaming and audit logging are live, so unattended runs can be traced end to end; 30+ models on one OpenAI-compatible key let you keep routine runs on small models and escalate only when needed. Batch endpoints, useful for bulk scheduled work, are coming soon. Plans are on the live pricing page.
Honest comparison
| Trigger type | Good for | Watch out for | Idempotency |
|---|---|---|---|
| Cron schedule | Daily reports, syncs, digests | Overlap and drift | Key per time slot |
| Queue worker | Backlogs and event bursts | Poison messages | Key per message ID |
| Event webhook | Reactive workflows | Duplicate deliveries | Key per event ID |
| Manual trigger | Sensitive one-off runs | Operator error | Key per request |
| Chained runs | Multi-stage pipelines | Partial completion | Key per stage and run |
Frequently asked questions
Should every recurring task use an agent?
No. Use deterministic code where the logic is fixed, and involve the model only for judgement, extraction or summarisation that genuinely varies.
How do I prevent duplicate actions?
Give each schedule slot or event a deterministic run key and use it as the idempotency key on every side effect, so retries and catch-up runs cannot double-apply.
What happens if a run is missed?
Decide per job: run late, coalesce missed slots into one, or skip. Document the choice, because silent skipping is a common source of stale data.
How do I protect downstream systems?
Cap concurrency, set timeouts and rate limits per tool, and use backpressure so a backlog does not turn into a flood.
How do I keep unattended costs under control?
Set per-run budgets, alert on cost trends, and route routine steps to smaller models. Flat monthly self-serve plans on Plugsky avoid per-token surprises — see the live pricing page.
Who reviews the output?
A named owner with a targeted queue for exceptions, low-confidence results and anything above a value threshold. Review the queue metrics to spot systemic issues.
Can scheduled agents run on-prem?
Yes. Plugsky supports VPC, on-prem and air-gapped deployment, so inference and the surrounding automation can stay inside your network.