Building effective agent automations

來源原標題

Building effective agent automations

機構

Anthropic

原始標籤

Best practices

原始連結

https://claude.dev/blog/building-effective-agent-automations/

摘要原文

As AI accelerates our work, it's getting harder to keep up. At Anthropic, simple agent automations are frequently used to help. They often run on a schedule, gather context in the background, and proactively tell us what we need to know. But it’s difficult to build effective agent automations: they can lose access to a source without anyone noticing or fail to follow our preferences. Using Claude Managed Agents (beta), we built a reference implementation that reads custom sources (e.g., Slack and GitHub repos) on a schedule, tracks what changed since the last run, and posts what you need to know (e.g., to Slack). In this article, we walk through each step, share a reference implementation, and provide a command to run in Claude Code that configures the agent for you. GET THE CODE The reference implementation is here . For an interactive walkthrough, run the command below in Claude Code. The claude-api skill can help set up the agent following the guidance in this article: PROMPT Copy /claude-api managed-agents-onboard https://claude.dev/blog/building-effective-agent-automations/ For this reference implementation, you need a Slack app ( create it from the manifest ) and a GitHub token . The provided files (shown below) are configuration for Claude API resources, including the agent, its environment, memory stores, vault, and deployment. CODE Text Copy daily-brief/ ├── agent.md model, tools, instructions ├── deployment.md schedule, time zone, budget, input message ├── environment.yaml network allowlist ├── memory_store_preferences.yaml user preferences ├── memory_store_state.yaml the agent's bookmarks, ledger, notes, and run records ├── vault.yaml the vault that holds the credentials ├── claude-lock.json resource IDs, written by ant apply └── slack/manifest.yaml one bot app ant apply , a command in the ant CLI, reads these files, creates the resources in your Claude API workspace (where the platform stores and runs them), and records the IDs in claude-lock.json . We'll use this command in the sections below. Once configured, the automation runs on a schedule on Anthropic's infrastructure, so nothing has to stay running on your machine. OVERVIEW The agent we’ll build has six components, covered in this order: Sources - A named list of places to read Destination - One place the agent may write Agent - The model, tools, and run steps in agent.md Schedule - A cron schedule Memory - Your preferences and the agent's own memory Guardrails - Read-only access wherever the agent only reads, and a spending cap per run SOURCES The agent reads two default sources: Slack channels and GitHub pull requests. The channels and repos are listed in your preferences file. The template can be extended to use other sources. Give the agent its own, scoped credentials With Managed Agents , credentials live in vaults . The agent can reference these credentials but the real values stay in the vault, outside the sandbox where Claude's code runs (see here and here ): MCP servers (GitHub). The agent calls MCP tools through a proxy that runs outside the sandbox. The proxy finds the vault credential whose URL matches the server’s. The shell (Slack). The agent calls the Slack API with curl using the bash tool inside the sandbox. The sandbox only holds an opaque placeholder, $SLACK_BOT_TOKEN . As the request leaves the sandbox, the platform swaps in the real token for hosts you allow. Create the vault using the ant CLI and the template file in the repo: CODE Shell Copy ant apply vault.yaml This creates the vault in your Claude API workspace, where the platform stores it, and records its ID in claude-lock.json . Then add each credential to the vault with the TypeScript SDK . Here is an example showing addition of the Slack credential: CODE TypeScript Copy const vaultId = process. env . VAULT_ID !; // the vault's ID, from claude-lock.json await client. beta . vaults . credentials . create (vaultId, { display_name : "SLACK_BOT_TOKEN" , auth : { type : "environment_variable" , secret_name : "SLACK_BOT_TOKEN" , secret_value : process. env . SLACK_BOT_TOKEN !, networking : { type : "limited" , allowed_hosts : [ "slack.com" ] }, injection_location : { header : true }, }, }); After creating the vault and adding each credential, attach the vault to the deployment. Copy the vault ID from claude-lock.json into vault_ids in the deployment file, deployment.md . Read from where you left off A common mistake is asking the agent to read a fixed window like " the last 24 hours ." A late run leaves a gap and an early run repeats items. Instead, give the agent a bookmark per source. At the end of each run, the agent writes the timestamp of the newest item it read from each source to one file, bookmarks.json , with an entry per source: "slack": "2026-09-14T13:02:11Z" . The next run starts from those bookmarks, so its window stretches or shrinks to cover everything since the last run. The bookmarks live in the memory store called state : a folder of text files that the platform mounts into every run's sandbox under /mnt/memory/ and keeps between runs. The agent reads and writes it with its ordinary file tools, and the instructions in agent.md tell it how. Don't mistake a failed read for a quiet day If an MCP server is down or its token has expired, the run still starts, just without that server's tools. The session logs an error, but the agent sees nothing from that source and reports "nothing new." Three rules in agent.md help fix this. When a source fails, the agent will: keep the source’s bookmark where it is, write the brief from the other sources, and end the brief with one line naming what it couldn't read ("pull requests unavailable this run"), so the reader is made aware. DESTINATION Our template posts to one Slack channel, with a dated post each time it runs. The agent posts to Slack using the bash tool in its sandbox, using the same bot token it reads with. Nothing has to approve the post. The agent sends it with a bash command, and the built-in bash tool runs without asking for approval by default. slack.com is also on the allowlist of the agent's environment , the sandbox it runs in. The post is one request: CODE Shell Copy curl -s https://slack.com/api/chat.postMessage \ -H "Authorization: Bearer $SLACK_BOT_TOKEN" \ -H "Content-Type: application/json; charset=utf-8" \ -d '{"channel": "C0123456789", "text": "Daily brief, Tue Sep 15 ..."}' Confirm the post landed before recording it Once a post is confirmed, the agent updates its ledger of reported items and its bookmarks. If those records don't match what was actually posted, two things can go wrong. If the agent records a post that never landed, the bookmarks move on and those items are never reported. If it posts again because it isn't sure the first post landed, readers get the same brief twice. Three rules in agent.md prevent this. First, the agent looks for today's title in the channel's recent messages and doesn't post if the edition is already there. Second, the post counts as sent only if Slack returns "ok": true and a message ts. Third, the agent updates the ledger and bookmarks only after that confirmation. If the result is unclear, it marks the run "maybe posted" and changes nothing else, so nothing is lost. The agent keeps a run record in its memory store ( runs/<date>.md ). It marks the run "posting" before the post, then "posted" with the message ID, or "maybe posted." AGENT In Claude Managed Agents, an agent is a versioned configuration: a model, a system prompt, and tools. Each run follows its run steps and stops. In our reference implementation, the agent configuration is agent.md : CODE Markdown Copy --- name: Daily brief model: claude-sonnet-5-5 mcp_servers: - type: url name: github url: https://api.githubcopilot.