The Five Building Blocks of an Always-On Agent, and What It Needs to Handle After It Falls Asleep

On November 13, Anthropic published Building always-on agents, by William Hu. In a tweet, Jiuyuanke said this is actually the most basic design pattern for a Personal Agent, and that he had seen a similar design before on raft build.

Always-on agents are not truly always on. They spend most of their time asleep, waking only when an event arrives. Each awakening is called a run; a run executes within a session, writes its state back when finished, and then goes back to sleep.

Anthropic breaks this architecture into five building blocks: an event inbox, timers, memory, permissions, and an outbox.

The event inbox solves the triggering problem. Webhooks, scheduled tasks, and background jobs do not call the agent directly; instead, they first write events into the inbox. The inbox is usually a database table: a handler writes to it, and a worker reads from it and starts a run. There are several implementation details: the handler should acknowledge quickly; the inbox is the source of truth; an inbox should have only one active worker at a time; and pending events can be merged to avoid the same task being executed repeatedly.

Timers let the agent take initiative. They fall into two categories: follow-ups the agent sets for itself, and schedules set by the user. Timers do not start runs directly; a scheduler polls for due items, writes events into the inbox, and then wakes the worker.

Memory is responsible for carrying context across runs. Anthropic's approach is to make memory a file directory mapped to a database or object storage. Instructions are loaded on every run; user notes and task progress can load only an index, with specific files read when needed. For things that already exist in other systems, storing a pointer is enough. The system prompt, tool definitions, and memory files at the beginning of the context are fixed overhead, so their size must be controlled and prompt caching used to reduce cost. If a session gets too long, you can compress old messages or start a new one, but details will be lost; anything that needs to persist must be written into memory in advance.

Permissions are the riskiest part. An always-on agent holds user permissions, yet by design no one is watching it. Credentials are best placed in a proxy outside the agent's environment; when the agent sends a request, it does not carry the key, and the proxy injects it when forwarding. High-risk actions are intercepted by the auto mode classifier, and the most important decisions still require user confirmation. When clarification or approval is needed, use a deferred tool call to show the request to the user; the run ends and the session is saved; the user's reply returns to the inbox as a new event, and the next run resumes.

The outbox handles output. A run can send a message, send nothing, or use a deferred tool call to request input. The outbox is a table of messages awaiting delivery, and a dispatcher handles delivery. Message frequency must be tuned: too many messages are noisy, too few cause misses. Anthropic recommends using evals to find the balance: first keep the agent quiet, then gradually earn the user's attention.

The five building blocks form a loop: a timer or the inbox triggers a run; the run reads memory, acts within its permissions, writes back to memory; the result goes to the outbox; and the user's reply becomes a new event in the inbox.

Several judgments in the comments are more grounded than the title. One commenter said that being always online sounds more exhausting than being an ordinary worker. Someone said that keeping it running all the time is not the hardest part; the hard part is knowing when it should call you. Someone sees the phone as the most personal event inbox. Others warned that where to resume after a disconnect, how to deduplicate repeated executions, and the bill for burning tokens while idling are the problems you face every day once something is always on.

Anthropic provides the building blocks; in practice you still have to add state recovery, deduplication, and cost control yourself. The experience gap between always-on agents may well lie in these inconspicuous places.