Agent Is Online 24/7, but the Model Sleeps Most of the Time

William Hu from Anthropic's Applied AI team published building always-on agents on the Claude website, included in Claude Platform best practices. The original tweet is in meng shao's share, and the long-form article also provides a Chinese breakdown. The article answers one question: how do you build always-on Agents in a product.

The whole article defines this type of Agent as stateful and proactive: it must manage context across multiple sessions and can act on its own when no one is watching. The underlying core loop has not changed; what changes is the surrounding architecture—who decides when it wakes up, which state persists across runs, and how results are delivered to users.

It suggests clearing up one misunderstanding first. Always-on describes the user experience. The Agent is asleep most of the time, is woken up by events at intervals to do work, and consumes no tokens while asleep. Each piece of work is called a run, and a run happens inside a session; a session is the record of messages and tool calls. After it finishes, it goes back to sleep, and the loop continues. One online commenter said they had previously been afraid that stopping would make it impossible to reconnect, so they left it running without shutting it down, and their quota dropped very quickly—this passage fits exactly.

Anthropic attributes why this is worth doing now to model progress: better judgment, a clearer sense of when to stop and confirm; cheaper intelligence, which benefits long-horizon tasks. The article provides a self-reported figure: on a subset of the long-horizon coding benchmark SWE-bench Pro, Opus 5.5 costs 78% less per completed task than Opus 5, and 40% less on typical workloads. The article also notes that the two model generations solve roughly the same proportion of problems, and subset results cannot be directly compared with public leaderboards.

The architecture is broken into five parts.

• Inbox: All sources first enter a queue, then wake the Agent. Webhooks, scheduled tasks, and background jobs do not call the Agent directly; they first write to a persistent event list, usually a database table. One HTTP endpoint handles writes, and a worker pulls events from the table. The inbox records status and deduplicates using a unique source identifier. The article suggests first creating one inbox per user, with only one active worker per inbox at a time. If a user sends several messages in a row, the worker merges them into one run and replies only once. Reply-type events return to the original session; other events open a new session. The inbox is the single source of truth; if a worker dies midway, a new worker can retry the same event.

• Timers: Let the Agent proactively follow up. Follow-up timers are deadlines the Agent sets for itself; schedule timers repeat at a fixed cadence. Timers are persisted separately. A scheduler periodically polls for due items, marks follow-up timers as complete, moves schedule timers to the next occurrence, then adds an event to the inbox and wakes the worker.

• Memory: Store only things that cannot be looked up next time. If something can be linked to an external system, store the link. Content to save falls into four categories: user instructions about the Agent's behavior, loaded at the start of every run; notes about the user, including role, preferences, and places where the Agent was corrected; content already told to the user, to avoid repetition; and progress on in-progress tasks, with one file per task stating what is done and what remains. The directory can live in a database or object storage. The article also mentions dreaming: reviewing past sessions, cleaning up outdated entries, and finding patterns across runs. Initial context has a cost every time, so it should be lean and use prompt caching; if a session gets too long, it can be compacted or a new one opened, and anything that must be preserved should first be written to memory. One online commenter built their own version and got stuck on memory: re-selecting history every turn blew up both tokens and latency; later they kept only the last three rounds of conversation plus a progress file, and it became more stable.

• Permissions: Risk is highest when no one is supervising. Credentials live outside the Agent's runtime environment; a proxy injects them into requests, and requests issued by the Agent itself do not carry real credentials. In auto mode, a classifier reviews high-risk operations, blocks dangerous parts, and makes the model take a safer path; key decisions still require human review. For deferred tool calls, a hook sets a call aside and ends the current run, leaving the session paused mid-call and saved; the user's answer returns to the inbox as a new event, and another run is started to resume the session, while the worker continues handling other events during the wait.

• Outbox: Deliver results, not the entire process. A run has three possible outcomes: send a message to the outbox; decide no message is needed; or use a deferred call to request permission or additional information. The outbox is a table of pending messages, and a dispatcher process reads it and decides which to send. Sending frequency should be tuned separately; the article suggests first making the Agent speak less, then gradually earning more attention. One online commenter working in BD cares about very concrete boundaries: when to remind me, when to wait for my confirmation, and when it may send something externally.

Put together, the five parts form a loop. An event starts in the inbox; a worker claims it, wakes the Agent, which reads memory, acts within permissions, writes back to memory, and writes a message to the outbox. A run can set a timer to wake itself up after a while; a user reply becomes a new event again. Each run is short, and the loop can keep turning indefinitely.

None of these components is new on its own; people have long assembled queues plus scheduled tasks. The article's value lies in the division of responsibilities and in separating the always-on experience from an always-running process. Teams building Agents should implement the inbox first; webhook retries and concurrent events will first pile up here. Permissions should be designed as defaults from the start; credential proxying, auto mode, and deferred calls are not decorations to add before launch. The outbox is a product-design concern, and many teams push very frequently as soon as they launch—exactly the opposite of what they should do.

If you only need small tasks such as reminding yourself, building the inbox and timers first can get a minimal loop running, with memory, permissions, and the outbox added afterward. Once an unattended Agent speaks externally on your behalf, the boundaries of permissions and the outbox must be thought through first. This architecture looks like scheduling shifts for an Agent: it sleeps most of the time, gets woken up to work, and when done puts the results in the outbox.