Anthropic's daily-brief agent treats a failed read as news

The most telling line in Anthropic's new daily-brief agent is one you hope never to read: "pull requests unavailable this run." In Anthropic's guide to building automations with Claude Managed Agents, the reference agent adds a line like that whenever a source fails, so a broken connection never passes for a quiet day.

At a glance

• Anthropic published a reference implementation of a daily brief that reads Slack channels and GitHub pull requests on a weekday cron schedule and posts one dated summary to a Slack channel.
• Credentials sit in a vault outside the sandbox, a bookmark per source replaces the fixed "last 24 hours" window, and the ledger updates only after Slack confirms the post landed.
• ClaudeDevs says Max and Team plans now include API credits for this kind of automation, but neither the guide nor the post says how large those credits are.

If you haven't been following: according to Claude Lab, Anthropic launched Claude Managed Agents into public beta on April 8, 2026. It is the hosted alternative to the Claude Agent SDK, where you run the infrastructure, the agent loop and the execution environment yourself. Anthropic's Claude site pitches the service as handling the secure infrastructure, state, permissions and scheduled execution that teams used to build on their own.

Setup is one Claude Code command plus ant apply

You start in Claude Code with /claude-api managed-agents-onboard, which uses the claude-api skill to configure the agent the way the guide describes. You also need a Slack app created from the provided manifest and a GitHub token.

The repo is a folder of config files: agent.md, deployment.md, environment.yaml with the network allowlist, two memory-store files, vault.yaml and slack/manifest.yaml. ant apply, a command in the ant CLI, creates each resource in your Claude API workspace and writes the IDs to claude-lock.json. After that the agent runs on Anthropic's infrastructure, so nothing has to stay running on your machine.

Each source keeps its own bookmark, and a failed source keeps it in place

By default the agent reads two sources: Slack channels and GitHub pull requests, both listed in the preferences file. The guide warns against a fixed window like "the last 24 hours," because a late run leaves a gap and an early run reports the same items twice.

Instead, each run writes the timestamp of the newest item it read from each source to bookmarks.json, for example "slack": "2026-09-14T13:02:11Z". The next run starts from there, so its window stretches or shrinks to cover everything since the last run.

When an MCP server is down or its token has expired, the run still starts without that server's tools and the session logs an error. Left alone, the agent would report "nothing new." agent.md tells it to leave that source's bookmark where it is, build the brief from the other sources, and end with one line naming what it couldn't read.

A post counts as sent only when Slack returns "ok": true

The brief goes to one Slack channel as a dated post. The agent sends it with curl to chat.postMessage through the bash tool, using the same bot token it reads with. No one approves the post: the built-in bash tool runs without asking by default, and slack.com is on the environment's allowlist.

Things break when the agent's records disagree with what actually happened. If it records a post that never landed, the bookmarks move on and those items are never reported. If it isn't sure the first post landed and posts again, readers get the same brief twice.

Three rules handle this. The agent checks recent channel messages for today's title and skips posting if the edition is already there. It counts the post as sent only when Slack returns "ok": true and a message ts, and only then updates the ledger and bookmarks. If the result is unclear, it writes "maybe posted" in runs/<date>.md and changes nothing else.

The deployment fires at 7:32 on weekdays, New York time

In Managed Agents, an agent is a versioned configuration and a deployment runs it. agent.md sets the model to claude-sonnet-5-5 and switches off web_search and web_fetch. MCP tools ask for approval by default and nobody is there to give it, so the GitHub toolset is set to always_allow and the token is read-only.

deployment.md holds the cron expression "32 7 * * 1-5" in America/New_York, plus the vault, memory stores, budget and the first message, and each firing starts a fresh session. That first message tells the agent to work out dates in that time zone. Otherwise it may compute dates in the server's zone and call this morning "yesterday." To test without waiting for the schedule, ant beta:deployments run --deployment-id <id> starts a run by hand.

A stale status costs more trust than ten missing items

Two of the eight run steps in agent.md shape what you actually read. Under Decide, an item gets a line only if the reader would act on it today or it changes a decision they are about to make. A count like "12 open reviews" is not an item, and an item that is still open is carried forward as "still waiting, day 3."

Under Verify, the agent re-checks every item against its live source just before posting. It drops anything resolved, fixes anything that changed, and drops anything it can't confirm. Links are copied from each source's own link field. The rule behind it reads:

One stale "still waiting on you" costs more trust than ten missing items, so never hedge an item's status: assert it or drop it.

The sandbox holds a placeholder token and two mounted memory folders

The real credential values stay in the vault, outside the sandbox where Claude's code runs. GitHub tools go through a proxy outside the sandbox, which picks the vault credential whose URL matches the server. For Slack, the sandbox only holds the placeholder $SLACK_BOT_TOKEN, and the platform swaps in the real token as the request leaves, but only for allowed hosts.

Think of a valet key: it starts the car, but only that car, and you never hand over the master. In the example, the Slack credential is created with the TypeScript SDK with allowed_hosts set to slack.com, and the vault ID then goes into vault_ids in deployment.md.

Memory lives in two stores mounted under /mnt/memory/. The preferences store is yours and read-only for the agent: channels, repos, what to leave out, the length cap and the destination. The state store is the agent's: bookmarks, the ledger, run records, proposed changes to your preferences, and notes like "returns only the newest 50 items."

The guide is candid about how scheduled agents fail but says little about cost. Its guardrails include a spending cap per run, yet the guide suggests no figure. Oddly, for a guide that specifies timestamps down to the second, neither it nor the ClaudeDevs post says how large the new Max and Team credits are. Because posts go out without approval, a wrong brief will likely reach the channel before anyone sees it, and the only protection is the Verify step.

What the Max credits actually cover

The open question is cost. Until Anthropic publishes the size of the API credits included with Max and Team, you can't tell how many weekday runs of this agent they would pay for, or whether you would also need a separate API budget. Managed Agents is still labeled beta, and the guide gives no date for a stable release.