Claude Managed Agents includes scheduled deployments: a deployment bundles an agent, an environment, resources, vault credentials, and a set of initial events, and fires on a recurring cron schedule — each firing autonomously creates a fresh session. This article covers the documented mechanics and the operational discipline an unattended workload needs.
The scheduling model
Schedules use POSIX cron expressions with an IANA timezone, at minute-level granularity, with up to 10 seconds of jitter, and a limit of 1,000 deployments per organization. Two daylight-saving quirks are documented and worth designing for: schedules match wall-clock time, so times that don't exist on a spring-forward night are skipped, and times that occur twice on a fall-back night fire twice. If a double-fire would be harmful, that is your first idempotency requirement (more below) — or schedule in UTC.
Every trigger attempt writes a deployment run record. Successful runs carry the created session ID; failed runs carry a typed error such as environment_archived, agent_archived, vault_not_found, session_rate_limited, or service_unavailable. Treat that run history as your audit log: a scheduled agent that silently stopped firing is a classic unattended-workload failure, and the typed errors tell you exactly why.
Lifecycle controls: pausing a deployment suppresses scheduled triggers (manual runs still work), unpausing does not backfill missed triggers, and archiving is terminal. Archiving or deleting the agent auto-archives its deployment — remember this when cleaning up old agents. Before committing to a schedule, test with a manual run (POST /v1/deployments/{id}/run), which creates a session immediately and works even while paused. One subtlety: manual runs do not emit deployment-run webhook events, so don't rely on webhooks to observe your tests.
Idempotency across runs
Each firing creates a new session with a fresh container, so the agent itself starts stateless. Whether the work is idempotent is up to your design. Recommended practices:
Give runs durable memory deliberately. Attach a memory store — a workspace-scoped collection of text documents mounted into the container that persists across sessions — and have the agent record what it already processed ("last ticket ID handled", "reports published through June"). Every mutation is versioned with an actor record, so you can audit and repair the watermark if a run goes wrong.
Make external side effects deduplicable. If the agent posts to your systems through MCP tools or custom tools, key each action on something stable (run date, source record ID) so a double-fire or retried run updates rather than duplicates. This is architecture guidance, not a platform feature — the platform guarantees a run record per trigger, not exactly-once side effects.
Reconcile dependencies before the first scheduled run. The documented pitfall list applies doubly when nobody is watching: verify every action maps to a configured tool or MCP server, every MCP server has a vault credential, and every referenced file or host is mounted and reachable. Invalid vault credentials do not block session creation — the failure surfaces later as a session.error event mid-run.
Notification design
Unattended workloads should push, not make you poll. Managed Agents webhooks POST to a registered HTTPS endpoint when resources change state — session status transitions, outcome evaluations, deployment and deployment-run lifecycle, and vault credential events including vault_credential.refresh_failed (the one that quietly kills scheduled MCP-using agents when an OAuth refresh breaks). Payloads are thin — event type plus resource IDs — so your handler fetches the resource for current state.
The documented delivery behavior dictates handler design: deliveries are HMAC-signed (verify with the SDK's client.beta.webhooks.unwrap() against the raw body), ordering is not guaranteed, retries reuse the same event ID (dedupe on it), and an endpoint auto-disables after roughly 20 consecutive failures — so return 2xx fast and do the work asynchronously. Note the webhook event namespace differs from the SSE stream's (webhook session.status_idled vs. SSE session.status_idle); don't share parsing code blindly.
A sensible minimum notification policy: page on deployment_run failures and vault_credential.refresh_failed, post a summary channel message on session.status_terminated, and stay silent on healthy runs — with a daily "N runs succeeded" digest built from the run records so silence is distinguishable from breakage.
Where to go next
Pair this with the coding-agent pattern or the research-agent pattern for the session's actual work, and see Managed Agents webhooks and idempotency and retry design for deeper treatments.