What changed
Two new capabilities added to Claude Managed Agents (public beta, managed-agents-2026-04-01 header), both missed in yesterday's digest: (1) Scheduled deployments — a new POST /v1/deployments resource lets you attach a cron schedule to an agent; each time the schedule fires, a new session starts and runs to completion with no scheduler infrastructure to manage. Up to 1,000 scheduled deployments per org. Deployments can be paused/unpaused/archived, and triggered manually outside the schedule via POST /v1/deployments/{id}/run. The schedule.upcoming_runs_at field confirms upcoming fire times at creation. (2) Vault environment variable credentials — a new auth.type: "environment_variable" credential type added to the vaults API, keyed by secret_name and secret_value, with a networking.allowed_hosts domain allowlist. The secret is stored as an opaque placeholder in the sandbox; the real value is substituted at egress on outbound requests to allowed domains only. The agent never sees the actual secret value. Previously only MCP OAuth and static bearer tokens were supported in vaults.
TL;DR
Claude Managed Agents adds cron-scheduled sessions via POST /v1/deployments (POSIX cron, IANA timezone, up to 1,000/org) and vault env var credentials (auth.type: "environment_variable", secrets substituted at egress only) — both now in public beta.
Developer signal
(1) Scheduled deployments: Create a deployment with schedule.type: "cron", schedule.expression (standard POSIX cron, minute-level granularity), and schedule.timezone (IANA identifier). The response includes schedule.upcoming_runs_at to verify your expression. Track successes and failures via GET /v1/deployment_runs?deployment_id=. Error types returned on failed runs: environment_archived_error, agent_archived_error, session_rate_limited_error. DST note: wall-clock matching applies, so schedule outside the 1–3 AM local window for anything where duplicate or missed runs are unacceptable, or use UTC. (2) Vault env var credentials: Register with POST /v1/vaults/{id}/credentials using auth.type: "environment_variable", auth.secret_name (the env var name the agent sandbox will see), auth.secret_value, and auth.networking.allowed_hosts. Important limitation: substitution happens at egress, not inside the sandbox — clients that compute request signatures from the secret (e.g., AWS SigV4) or validate credentials at startup will not work with this mechanism; use it for services that send the API key verbatim in a request header (most CLIs, SDKs with simple bearer/API-key auth). Max 20 credentials per vault. Not supported with self-hosted sandboxes. (3) Both features require the existing managed-agents-2026-04-01 beta header — no new beta header needed. SDK support available for TypeScript, Python, Go, Java, C#, PHP, and Ruby.