01
Start hereWhat actually shipped (and what the headline overstates)
On June 9, 2026, Anthropic's release notes added two things to Claude Managed Agents that, together, retire most of the plumbing builders hand-roll to run an agent on a timer. First: "Claude Managed Agents now supports scheduled deployments — run sessions on a cron schedule without managing your own scheduler." Second: secrets are injected into the agent's sandbox at execution time, so the model never sees the actual API key. The video's "Anthropic killed your scheduler" line is rhetorical — nobody deprecated launchd or cron. The accurate version is narrower and still a big deal: you no longer NEED to self-host a scheduler for a Managed Agent, and you no longer need to leave a provider key in plain text for it to read.
Read this once, out loud: this is the developer / API product — Claude Managed Agents — NOT the consumer "Routines" feature inside the Claude app. They sound similar and people are already conflating them. Routines is a consumer scheduling feature in the app; Managed Agents is the thing developers deploy and call. Everything below is about the developer product.
02
Stay honest about the boundaryWhat's CONFIRMED vs. what's your own glue
The two confirmed capabilities are the cron-scheduled deployment and the sandbox-injected secret. Don't overstate past that. Here is the clean split so you build on facts, not on a framing.
| Claim | Status |
|---|---|
| Managed Agents can run sessions on a cron schedule, no self-hosted scheduler | CONFIRMED — June 9 2026 release notes, verbatim capability |
| Secrets are injected into the agent's sandbox at execution time | CONFIRMED — Anthropic's own wording for the mechanism |
| The model never sees the actual API key | CONFIRMED — the verified-true consequence of sandbox injection |
| It's the developer Managed Agents product, not consumer Routines | CONFIRMED — distinct products; do not conflate |
| Anthropic deprecated launchd / cron / your existing tooling | FALSE — nothing was deprecated; you simply no longer NEED to self-host the scheduler |
| Secrets are injected 'at the network boundary' | AVOID — that's third-party phrasing; Anthropic's wording is 'into the sandbox at execution time' |
If a claim isn't in the CONFIRMED rows, treat it as your own architecture decision and label it as such — the way I label the checklist steps below that go beyond the raw release notes.
03
The order to wire itThe setup checklist — a server-less scheduled agent
Read this first: pin the exact Managed Agents API/SDK version you build against and validate every field name and route in your own dashboard / API reference before you ship — scheduled deployments and the secret store are a fresh surface and the literals can still move. With that set, here's the order. Steps 1–4 map to confirmed capabilities; steps 5–6 are the operational glue you own, flagged as such.
- Define the agent as a Managed Agent. Build the session/agent you want to run unattended — the same Managed Agent you'd call interactively, just destined for a schedule rather than a live request.
- Store the provider secret in Anthropic's secret store, not in your code. Put the API key (or other secret the agent needs) into the Managed Agents secret/vault configuration so it lives with the platform. This is what lets it be injected into the sandbox at run time instead of sitting in your environment.
- Reference the secret by name in the agent config — never inline the value. The agent declares which secret it needs; at execution time Anthropic injects it into the sandbox. The model itself never receives the literal key. Confirm the exact reference syntax against your dashboard.
- Attach a cron schedule to the deployment. Use the scheduled-deployments feature to set the cron expression (e.g. nightly, hourly). This is the piece that replaces your launchd plist / cron line / babysat worker — Anthropic runs the sessions on that schedule. (Confirm the schedule format your account expects.)
- [Your glue] Decide what each run reads and writes. A scheduled agent is only useful if its output lands somewhere — a database, a webhook, a file, a notification. The release gives you the scheduled run + the secret; wiring the run's I/O to your systems is your job, exactly as it was before.
- [Your glue] Add observability + a kill switch. Log each run's start/finish/result, alert on failure, and keep a way to pause the schedule. Anthropic runs the cron, but you still own knowing it ran and being able to stop it.
The mental model: Anthropic now owns the timer and the secret; you own the agent's logic and where its work goes. That's the whole shift — two infrastructure jobs moved off your plate, the product logic stayed on it.
04
The security win, stated preciselyWhy the sandbox-injected secret is the half that matters most
A scheduler alone wouldn't be that interesting. The reason this is worth changing your setup over is the secret handling. Before, a scheduled script needed the provider key reachable in plain text — in an env var, a config file, a CI secret your process reads. Any leak of that surface leaked the key.
- The key lives in Anthropic's secret store, not your runtime. You stop keeping a copy in the environment your scheduler runs in.
- It's injected into the sandbox at execution time. The key materializes only inside the agent's sandbox for the duration of the run — Anthropic's wording, and the important precision: it's the SANDBOX, not 'the network boundary' (a phrase some third-party writeups used that isn't Anthropic's).
- The model never sees the actual API key. This is the verified-true claim you can repeat with confidence: the agent does the work the key authorizes, but the literal secret isn't exposed to the model.
- You shrink the blast radius. Fewer places hold the plaintext key means fewer places to leak it. Treat the secret store's access controls as your new trust boundary.
This is the part most people skim past on the way to 'cool, free cron.' The cron saves you a server; the sandbox vault is what saves you from the 2am incident where a leaked key gets your provider account drained.
05
Don't migrate for the sake of itWhen this is worth it (and when your own cron is still fine)
Managed Agents on a schedule is genuinely useful, but it's not the right move for every job. Here's the honest line.
- Use it when the scheduled work IS a Claude agent. If the thing running on the timer is a Managed Agent session anyway, getting the schedule + secret handling for free is a clean win.
- Use it when key hygiene matters. Anything where a leaked provider key is a real risk benefits from the secret never sitting in your runtime.
- Stick with your own cron for non-agent jobs. If the scheduled task is a plain script that happens to call an API, your existing launchd / cron / serverless function is simpler — don't wrap it in a Managed Agent just to use the feature.
- Validate the contract before you cut over a production schedule. It's a new surface; pin the version, test the schedule fires, confirm the secret injects, and keep your old path until the managed one has run clean for a few cycles.
The point: two infrastructure chores — the scheduler and the secret — moved to the platform for Managed Agents. Take the win where the job is already an agent; keep your own plumbing where it isn't.
Get the next drop
New AI build guides + the occasional bonus template. No spam, unsubscribe anytime.
By submitting you agree to our Privacy Policy & Terms. Unsubscribe anytime.
You're in — check your inbox to confirm.
Frequently asked questions
What exactly did Anthropic ship on June 9, 2026?
Per the release notes, Claude Managed Agents now support scheduled deployments — you can run sessions on a cron schedule without managing your own scheduler — and secrets are injected into the agent's sandbox at execution time so the model never sees the actual API key. Those two capabilities are what this checklist is built on.
Is this the same as the Routines feature in the Claude app?
No — and this is the distinction to get right. This is the developer / API product, Claude Managed Agents, which developers deploy and call. The consumer Routines feature inside the Claude app is a separate thing. People are already conflating them; everything in this guide is about the developer Managed Agents product.
Did Anthropic deprecate launchd / cron / my existing scheduler?
No. Nothing was deprecated. The 'killed your scheduler' framing is rhetorical. The accurate statement is that you no longer NEED to self-host a scheduler to run a Managed Agent on a timer — Anthropic runs the cron for you. Your existing tooling still works for everything else.
How are the secrets handled — does the model see my API key?
The secret is injected into the agent's sandbox at execution time (Anthropic's wording). The verified-true consequence is that the model never sees the actual API key — the agent does the work the key authorizes without the literal secret being exposed to the model. Avoid the third-party phrasing 'injected at the network boundary'; that's not how Anthropic describes it.
Are the exact API routes, field names, and cron syntax documented here?
No — and read this before you write integration code. This guide gives you the confirmed capabilities and the order to wire them, not invented route strings or field literals. Because scheduled deployments and the secret store are a fresh surface, the authoritative names live in your own dashboard / API reference. Pin the version you test against and validate before you ship.
What do I still own after moving to a scheduled Managed Agent?
The agent's logic and its I/O — where each run reads from and writes to — plus observability and a kill switch. Anthropic now owns the timer (the cron) and the secret handling (the sandbox vault); you own the agent's purpose, its outputs, and knowing it ran. Two infrastructure jobs moved off your plate; the product logic stayed on it.
When should I NOT use this?
If the scheduled job isn't actually a Claude agent — say a plain script that calls an API on a timer — your own cron, launchd, or serverless function is simpler. Don't wrap a non-agent task in a Managed Agent just to use the feature. Reach for it when the scheduled work is a Managed Agent session anyway, or when keeping the provider key out of your runtime genuinely matters.