Pin the version
A recurring schedule should identify exactly what it will execute. If it merely points at “latest,” publishing a draft can change production behavior without a schedule review. Runovio pins each schedule to one immutable published agent version together with its JSON input.
Publishing a newer version does not move an existing schedule. An operator can inspect and update the schedule deliberately, while historical runs continue to reference the configuration that actually ran.
Make time explicit
Daily and weekly labels are convenient, but execution still needs a concrete cron expression and IANA timezone. Storing the timezone avoids relying on the server's local clock and preserves intent across daylight-saving transitions. Advanced schedules use bounded five-field cron and must meet the deployment's minimum interval.
The scheduler and worker run inside the same always-on Node.js process as the Next.js application. This design keeps one execution path, but it also means short-lived serverless runtimes are not compatible with scheduled execution.
Control overlaps and downtime
At-least-once trigger delivery must not create duplicate occurrences. Runovio uniquely identifies a schedule and scheduled time before publishing the normal agent-run job. Manual and scheduled runs then share provider validation, tool policy, retries, traces, and cost accounting.
If an earlier run for the same schedule remains queued or running, the next occurrence is skipped. That prevents a slow agent from building an unbounded backlog. After downtime, registration resumes at the next valid future time instead of enumerating every missed cron tick and creating a catch-up burst.
These choices trade automatic backfill for predictable load and visible attribution. Operators can inspect schedule run history, keep the intended version pinned, and investigate skipped overlaps without confusing them with failed inference.
Continue with the scheduled agents feature, the scheduled AI agents use case, and the runtime guide.