Building Effective Agent Automations with Claude Managed Agents

Anthropic‘s article explains why simple agent automations are useful internally but hard to build well: they can silently lose access to a source or fail to follow preferences. Using Claude Managed Agents (beta), the team built a reference implementation that reads custom sources such as Slack channels and GitHub pull requests on a schedule, tracks what changed since the last run, and posts a daily brief to Slack. The code is shared in a repo, and Claude Code can walk through the setup via the claude-api skill.

The implementation is expressed as configuration files: agent.md, deployment.md, environment.yaml, memory_store_preferences.yaml, memory_store_state.yaml, vault.yaml, claude-lock.json, and a Slack manifest. The ant CLI command ant apply reads these files, creates the resources in the Claude API workspace, and records their IDs in claude-lock.json. After setup, the automation runs on Anthropic‘s infrastructure, so nothing has to stay running on the user’s machine.

Credentials are kept in vaults outside the sandbox. The GitHub MCP server is reached through a proxy that matches the vault credential to the server URL; for Slack, the sandbox holds an opaque $SLACK_BOT_TOKEN placeholder that the platform swaps with the real token for allowlisted hosts. The agent reads from bookmarks per source, not fixed time windows. At the end of each run it writes the newest timestamp it read to bookmarks.json in a state memory store mounted under /mnt/memory/, so the next run’s window expands or shrinks to cover everything since the last run. If a source fails, the agent keeps its bookmark, writes the brief from the other sources, and names the unreadable source rather than reporting nothing new.

Posts go to one Slack channel by default. Three rules prevent lost or duplicate briefs: the agent checks for today’s title in recent channel messages before posting; it counts a post as sent only when Slack returns "ok": true and a message ts; and it updates the ledger and bookmarks only after that confirmation. If the result is unclear, it marks the run maybe posted and changes nothing else.

agent.md defines the model, MCP servers, tools, and eight run steps. MCP tools normally ask for approval, so the GitHub toolset is set to always_allow and the GitHub token is read-only. The instructions push for brevity: an item earns a line only when the reader would act on it today, a count is not an item, open items are carried as marked lines, and retired topics are not resurrected. Just before posting, the agent re-checks each item’s live status, drops resolved or unconfirmable items, fixes changed lines, and never hedges status. Links are copied from the source’s own link field rather than assembled by hand.

deployment.md holds the schedule, time zone, vault, memory stores, budget, and the first message. Each schedule fire starts a fresh session. The timezone field controls when the run fires, and the message instructs the agent to compute every date in the reader’s time zone to avoid off-by-one-day mistakes. Two memory stores are used: preferences (read-only to the agent, re-read at the start of every run) and state (read-write, containing bookmarks, a ledger of reported items, run records, notes, and proposed preference changes). If preferences cannot be read, the agent stops and says so instead of running on defaults. The ledger records each reported item with a stable ID and its last known status so the brief does not repeat itself.

Guardrails limit what the background run can do: the GitHub token and preferences store are read-only, and the environment only reaches hosts on its allowlist. Slack is the exception because the same token reads and posts, so the bot should only be invited where it needs to read or post. The spending cap in deployment.md starts at three to five times a normal run’s cost and should be tightened with real numbers; a run that hits the cap pauses with budget_reached rather than failing.

The article closes with six rules: read each source from a bookmark, report a failed read as unreadable, re-check items before posting, count a post only when confirmed, re-read preferences every run, and give the agent read-only access plus a per-run spending cap. The claude-api skill can read the post, propose a setup, write files into an agents/ folder, and create the resources with ant apply; the result is meant as a starting point for custom sources, destinations, or memory preferences.

Building effective agent automations

View Original