Anthropic
Blogcast

Alex: Welcome back to the Anthropic Blogcast, where Alex and Jordan turn Anthropic's latest writing into something you can listen to. Today we're digging into a piece from the developer blog, claude.dev, by Lance Martin and C J Avilla, called Building Effective Agent Automations.

Jordan: And this one is practical in a way a lot of agent discourse is not. The premise is simple. At Anthropic, engineers rely on little agent automations that run on a schedule, gather context in the background, and tell them what they need to know. The problem is that these automations are hard to build well. They silently lose access to a source, or they stop following your preferences, and nobody notices until something important slips through.

Alex: So the article walks through a reference implementation, a daily brief agent built on Claude Managed Agents, which is in beta. It reads Slack channels and GitHub pull requests on a schedule, tracks what changed since the last run, and posts what you need to know to Slack. They ship the whole thing as configuration files you can apply, plus a Claude Code command that configures it for you.

Jordan: The article organizes the agent into six components, and each one exists to fix a specific failure mode. Sources, destination, the agent itself, the schedule, memory, and guardrails. Let's walk through them.

Alex: Starting with sources. The agent reads two default sources, Slack channels and GitHub pull requests, with the exact channels and repos listed in a preferences file you own. Credentials live in vaults. The agent can reference them, but the real values stay in the vault, outside the sandbox where the code runs. GitHub reaches its credential through an M C P proxy outside the sandbox, and Slack reaches its token through a placeholder that the platform swaps for the real value as the request leaves the sandbox. The agent also keeps a bookmark per source, instead of reading a fixed window like the last twenty four hours. At the end of each run it writes the timestamp of the newest item it read to a bookmarks file, so the next run's window stretches or shrinks to cover everything since the last run.

Jordan: And the second rule of sources might be my favorite line in the article. Do not mistake a failed read for a quiet day. If an M C P server is down or a token expired, the run still starts, just without that source's tools, and the agent sees nothing and reports nothing new. Three rules in the agent's instructions fix this. When a source fails, the agent keeps that source's bookmark where it is, writes the brief from the other sources, and ends the brief with one line naming what it could not read. The reader is made aware instead of being misled.

Alex: Next, the destination. The template posts to one Slack channel, one dated post each time it runs. And posting is not the same as being posted, so there are three rules for that too. The agent checks the channel's recent messages for today's title and does not post if the edition is already there. The post counts as sent only if Slack returns ok true and a message timestamp. And the agent updates its ledger and bookmarks only after that confirmation.

Jordan: And the agent keeps a run record per date, marking the run posting before the post and posted with the message I D after.

Alex: The agent component is where Managed Agents shows its shape. An agent is a versioned configuration, a model, a system prompt, and tools, captured in a file called agent dot m d. The frontmatter sets the name, the model, here Claude Sonnet five point five, and the M C P servers. The body holds the run steps and the judgment rules.

Jordan: Two details worth calling out. Since M C P tools ask for approval by default and nobody is around on a scheduled run, the GitHub toolset is set to always allow, and the GitHub token is read only. And the instructions steer toward brevity hard. An item earns a line only if the reader would act on it today or it changes a decision they're about to make. A count like twelve open reviews is not an item. Open items carried across days get one marked line, like still waiting, day three.

Alex: There's also a verify step right before posting. The world moved while you read, so for every item the agent re-checks the live source just before posting. Resolved, drop it. Changed, fix the line. Cannot confirm, drop it. The article's phrasing is great, one stale still waiting on you costs more trust than ten missing items. And every link is copied from the source's own link field, never assembled by hand.

Jordan: Then the schedule. The agent is only a configuration file, a deployment runs it. The deployment is captured in deployment dot m d, naming the agent, the environment, the vault IDs, the memory stores, and the first message of each run. The schedule is a cron expression running weekday mornings in the America New York time zone. Each time it fires, the platform starts a fresh agent session on Anthropic's infrastructure, so nothing has to stay running on your machine.

Alex: They also flag a classic time zone bug. The agent can call this morning yesterday because it computes dates in the server's time zone, so the deployment tells the agent explicitly which zone to use for dates.

Jordan: Memory is the fifth component. Every run starts in a fresh sandbox with no memory of the last one, so without memory, feedback does not stick. The template keeps two memory stores mounted in the sandbox. Preferences, which is yours and read only to the agent, listing sources, exclusions, length caps, the destination. And state, the agent's own, holding bookmarks, the ledger of what it reported, run records, and notes on how each source behaves.

Alex: Three memory rules. Re-read your preferences at the start of every run, never bake a copy into the prompt, because baked copies keep applying rules you already changed. If the agent cannot read the preferences file, it stops and says so instead of running on defaults. And keep a ledger of everything reported, with a stable I D like a pull request number and its last known status, so the brief reports the change, not the repeat.

Jordan: Finally, guardrails. Because this runs on a schedule in the background, they limit what it can do and what it can spend. The GitHub token and the preferences store are read only, and the environment only reaches hosts on its allowlist. They call out prompt injection directly. The agent reads messages other people wrote, and that text can be interpreted as instructions, so the defense is limiting blast radius. A planted instruction might change what the brief says, but it cannot write to GitHub or edit your rules.

Alex: And the spending cap. Set it from real runs, starting at three to five times the cost of a normal run, then tighten as you see real numbers. The cap is a budget field in deployment dot m d, and every run gets the full amount. A run that reaches its cap pauses instead of failing, so a cap set too low looks like a brief that went quiet, and you investigate rather than get an error cascade.

Jordan: To get started, update Claude Code, then run the claude-api skill with a command pointing at the article. It proposes a setup, writes the files, and creates the resources, and then you customize for your sources and preferences.

Alex: So the six rules the whole thing comes down to. Read each source from a bookmark, not a fixed time window. Report a failed read as unreadable, never as a quiet day. Re-check every item right before posting. Count a post as sent only when Slack confirms it, then update bookmarks and ledger. Re-read your preferences every run, from a store the agent cannot edit. And give the agent read only access wherever it only reads, plus a cap on what each run can spend.

Jordan: What I like is that none of this is really about Claude. It is about the unglamorous failure modes of any scheduled agent, and the article treats reliability as a design discipline with specific mechanisms, not vibes. Bookmarks, ledgers, confirmations, read only scopes, budgets. Steal these even if you never touch Managed Agents.

Alex: That's the episode. Building Effective Agent Automations, by Lance Martin and C J Avilla, on claude.dev. The reference implementation is on GitHub if you want to poke at agent dot m d and deployment dot m d yourself. Thanks for listening, and we will catch you on the next one.