Always-On Agents Aren't Always On: Anthropic's Five Primitives for Agents That Wake, Work, and Sleep

Always-on agents are having a moment. Anthropic's William Hu broke down the architecture behind them this week, and the most useful part isn't a new model or a new framework — it's a short list of five boring-sounding primitives that turn a chatbot into something that works while you're away. The timing makes sense. Two things changed at once: models got better at judging when to act and when to ask, and intelligence got cheaper. On one long-horizon coding benchmark, Opus 5.5 cost 78% less per solved task than Opus 5 — 40% less on typical workloads. When every wake-up costs a fraction of what it used to, an agent that wakes up on its own stops being a luxury and starts being a design pattern. But the first thing to get straight is the name. An always-on agent is not actually always on. Asleep most of the time The agent spends most of its time asleep, waking up periodically to do work. Each stretch of work is called a run: the agent receives an event, completes its task, and saves what happened. A run works inside a session, the transcript of messages and tool calls. When the run is done, the agent goes back to sleep, and the cycle repeats. "Always on" is a description of the user experience, not the implementation. Underneath, the agent runs on the same core loop as any other agent. What makes it different is the surrounding architecture — five primitives that control when the agent wakes up, what carries over between runs, and how its work reaches the user. 1. The event inbox Most agents only run when the user sends a message. An always-on agent can be triggered by webhooks, scheduled tasks, and background jobs. The tempting approach is to let each event source call the agent directly. That breaks in predictable ways: two events arriving at the same time can start competing runs, and a crash can lose an event entirely. The fix is an event inbox. Every source sends its event to the inbox, and a worker picks it up. The simplest version has three parts: A durable list of events, usually a database table A handler, usually an HTTP endpoint, that writes events to the list A worker, usually a background service, that reads from the list A few rules make it work: the handler should acknowledge events quickly (webhook providers treat slow responses as failures, so deep checks like prompt-injection screening belong in the run, not the handler); the inbox is the source of truth, so a worker that dies mid-run can be retried by a fresh one; only one worker should be active per inbox at a time; and the worker should batch pending events — if a user sends several messages in a row, merge them into one run so the agent only replies once. Start with one inbox per user, and split further only if you need more parallelism. 2. Timers Timers are what make the agent proactive rather than merely reactive. They come in two kinds: follow-ups, deadlines the agent sets for itself ("check whether that reply came in"), and schedules, recurring tasks on a known cadence (a daily briefing). Timers live in their own durable store, separate from the inbox — the inbox should only hold events that are ready to be worked on. A timer doesn't start a run by itself. A scheduler polls the store at a fixed interval, marks follow-ups done, rolls schedules forward to their next occurrence, drops an event into the inbox, and wakes the worker. You can build the scheduler yourself or use a durable execution engine. 3. Memory An always-on agent works across many disjointed runs, so memory is what keeps it continuous. Like the inbox and timers, memory gets its own store. In Anthropic's products it's a directory of files — Claude Code's auto memory and the Messages API memory tool work this way — and for always-on agents those directories map to durable storage, usually a database or object store, so memories outlive the worker. The rule of thumb: memory should only hold what the agent can't look up again. If something already lives in another system, like an issue tracker, save a pointer instead. What to store: User instructions — saved in their own file, loaded at the start of every run, because the user won't always be around to steer the agent User notes — what the agent has learned about the user: role, preferences, corrections. Start with one file; as notes grow, load only an index at run start and pull individual files in when needed Past messages — what the agent already told the user, so nothing gets repeated Task progress — a per-task file of what's done and what's left, so any new run picks up where the last one stopped There's also "dreaming": reviewing past sessions to curate memory, replacing outdated entries and finding patterns that only show up across many runs. One cost to watch: before doing any work, the agent loads the system prompt, tool definitions, and memory files. That initial context overhead is included in every run, so keep it lean and use prompt caching. If a session gets too long, compact the older messages or start a new one — both lose detail, which is exactly why anything worth keeping should be written to memory along the way. 4. Permissions Permissions are where always-on agents carry the most risk. A run holds the user's access and, by design, operates unattended. For every tool call, the agent has to decide: proceed, block, or wait for approval. Three components handle this: A credential store — agents often need passwords or access tokens. The recommended pattern is a proxy outside the agent's environment that adds credentials to outgoing requests. The agent sends requests without credentials; the proxy injects the real ones before forwarding. Auto mode — the agent needs to work without constant input. Claude Code's auto mode uses classifiers to review higher-risk actions and block the dangerous ones so the model can find a safer approach. But the most important decisions still need user review. Deferred tool calls — a hook can defer a tool call and wait for the user's input. The run ends, the session is saved mid-call, the request is shown to the user (for example, through an interactive card), and the answer comes back as an event in the inbox, starting a new run that resumes the saved session. While the deferred call waits, the worker can pick up other events, so the agent isn't blocked. 5. The outbox Most agents stream their reply as it's generated. Always-on agents do most of their work in the background, so the user gets the outcome and a few details, not the full step-by-step trace. A run can end in one of three ways: the agent sends a message to the outbox, decides nothing needs to be sent, or uses a deferred tool call to request permission or more input. A plain "send" tool is enough for most agents. You only need a formal outbox — a separate table of outgoing messages plus a dispatcher that decides what to deliver — when you want to pace the agent's messages or let it recover from errors. Pacing matters more than it looks. An agent that sends too many messages becomes noisy; one that sends too few misses things the user needs to know. Anthropic's advice: build evals to find the balance, and in practice start quiet, then earn more of the user's attention over time. How it fits together Every run starts with an event from the inbox — a user message, a webhook, or a timer. The worker picks it up and wakes the agent in a new or existing session. The agent reads its memory for a baseline, works within its permissions, updates its memory with what it learned, and pushes a row to the outbox. The dispatcher delivers the message. A run can set a timer that wakes the agent again later; a user's reply comes back as an event. Each run is short, but the loop never stops — and that's why the agent feels always on. What this means if you're building one Three things stand out for anyone turning a demo agent into a product: The hard parts are infrastructure, not model calls. The inbox, the scheduler, the memory store, the outbox — these are database tables and background services. The agent loop is the easy part. Start boring. One inbox per user, one worker, a send tool instead of a formal outbox, and a quiet agent. Add parallelism and pacing once you have real traffic. Permissions are the product decision. Everything else is plumbing; the question of what the agent may do unsupervised — and how it asks when it isn't sure — is what users will actually judge you on. The full post is worth reading for the diagrams alone: Building always-on agents, by William Hu at Anthropic.