Agent Cron Jobs: Ephemeral Runners
Scheduled agent workflows run unattended with credentials and no human in the loop. Here is the runner shape that keeps a bad cron minute contained.
RB
title: "Agent Cron Jobs: Ephemeral Runners" slug: "2026-11-01-agent-cron-jobs-ephemeral-runners" meta_title: "Agent Cron Jobs: Ephemeral Runners" meta_description: "Copilot Automations puts agents on schedules and events. Unattended runs need agent cron jobs with ephemeral runners, per-minute billing and scoped secrets." primary_keyword: agent cron jobs author: Rohit Bhadani date: 2026-11-01 schema: BlogPosting+FAQPage category: AI Code Sandboxing secondary_keywords: scheduled agent workflows, Copilot Automations, unattended agent runs, ephemeral CI runners, agent credential scoping excerpt: "Scheduled agent workflows run unattended with credentials and no human in the loop. Here is the runner shape that keeps a bad cron minute contained."
Agent Cron Jobs: Ephemeral Runners
GitHub closed out Universe 2026 by putting agents on the clock. Copilot Automations lets developers create AI workflows that run on a schedule, respond to events or trigger manually, per the Moneycontrol coverage of the 28 October announcements. A scheduled agent run is a new animal: an unattended session with credentials, a deadline and nobody watching. Moneycontrol's 28 October coverage lists three trigger types: schedule, event and manual. Treat it as agent cron jobs, and the runner contract changes.
The difference from interactive sessions is the human absence. An interactive agent misbehaves in front of someone who can hit stop. A cron-triggered agent misbehaves alone, at 3am, with whatever scope its token grants.
Why agent cron jobs change the runner contract
Interactive sessions tolerate a long-lived devbox because a human anchors the risk. Unattended runs have no anchor, so the runner itself becomes the containment: fresh environment per run, nothing carried over, nothing left behind.
Event-driven triggers sharpen this further. A webhook burst can fan out into dozens of parallel runs, and a runner pool that persists between runs turns one poisoned cache into a fleet-wide problem, the failure mode our CI isolation guide documents for build runners.
The runner shape for unattended agent work
Boot a fresh isolated environment per run from a golden snapshot. Identical starts make runs comparable and poisoning local, and restore-from-snapshot beats rebuild on both speed and determinism, as our throwaway computing analysis argues for ephemeral work generally.
Scope the run's credentials to the run. A scheduled agent needs exactly the tokens its task requires, issued at start and expired at stop, so a compromised run recovers minutes of scope rather than a standing key, the same rule our Copilot Projects fleet analysis applies to parallel fleets.
Bill per minute and power off at exit. Cron workloads are spiky by definition; per-minute metering with power-off means the quiet hours between runs cost nothing, and the run's own cost stays readable in the bill.
Cap concurrency and fail closed. A nightly job that runs 24 minutes a day costs 12 hours of compute a month, and per-minute billing prices exactly those 12 hours. A trigger storm should queue, not multiply, and a run that exceeds its time or token budget should stop with an alert rather than continue unwatched, mirroring the quota discipline in our spend-control writing.
Log to append-only storage outside the runner. An unattended run that can rewrite its own logs cannot be audited after the fact, and audit is the only witness you get, per the tamper-evident monitoring playbook.
What breaks if you reuse interactive infrastructure
A shared devbox runner accumulates state: cached tokens, half-finished branches, installed tools from earlier runs. Each accumulation is a channel between runs, and a scheduled agent inherits all of it silently, which is how one bad Tuesday commit becomes a standing backdoor in your 3am job.
We checked the Automations coverage on 31 October against our own runner docs, and the pattern matches what per-minute microVM fleets already do for CI: fresh machine per job, snapshot for speed, scoped token for prize.
Verdict
We recommend running agent cron jobs on ephemeral isolated runners with snapshot boots, per-run scoped credentials, per-minute billing with power-off, concurrency caps and external append-only logs. Schedules make agents reliable; ephemeral runners make them safe to trust.
Limitations
- Copilot Automations is new, and real-world run shapes will differ from the announcement demos; however, the unattended-risk logic holds for any scheduler.
- Snapshot-boot latency varies with image size, and we have not measured restore times for large toolchain images.
- Concurrency caps trade throughput for containment, and the right queue depth is workload-specific.
- Our runner contract assumes your scheduler can provision externally; in-platform schedulers may limit runner choice.
FAQ
How is a scheduled agent run different from a CI job?
It makes decisions mid-run with model judgment and broader credentials, so a compromised run can improvise beyond its script. Containment must cover behavior, not just code.
Can runs share a warm pool for speed?
Only with snapshot-restore warmth, not persistent machines. A warm pool of fresh restores keeps speed without carrying state between runs.
What credential scope does a nightly agent job need?
Tokens for its exact repos and services, issued at start with expiry at stop. Anything longer converts one bad run into a standing credential leak.
