Building always-on agents · William Hu, Anthropic · Claude blog, November 13, 2026
Anthropic lays out the five parts of an agent that runs unattended
The guide says an always-on agent spends most of its time asleep: it wakes on an event, does one run, saves what it learned and stops. Around that loop it names five parts: an event inbox, timers, memory, permissions and an outbox. Event sources should write to a durable table rather than call the agent directly, because two events arriving together can start competing runs and a crash can lose an event. And "An inbox should only have one active worker at a time," so that two runs cannot duplicate work or overwrite each other.
On memory, the guide says to keep only what the agent can't look up again, save pointers for the rest, and keep a progress file per task so the next run picks up where the last one stopped. For permissions it recommends a proxy outside the agent's environment that injects credentials, Claude Code's auto mode for higher-risk actions, and deferred tool calls that end the run and resume it when the user's answer arrives as a new inbox event. It gives one first-party cost figure: on a long-horizon coding benchmark, Opus 5.5 cost 78% less per solved task than Opus 5, against 40% less on typical workloads. The rest is design guidance, not a measured result.
Why it matters: Agents on a schedule fail in the ways this guide plans for: two runs firing at once and overwriting shared state, or a crash that loses the event that started a run. A single worker per inbox, a durable event table and per-task progress files give a team running coding agents unattended a concrete list to check its own harness against.