A 24/7 AI assistant that spends most of its time asleep

On November 13, Anthropic published “Building always-on agents” by William Hu. The article is about the kind of always-on Agent that watches email, waits for replies, and gives reminders when the time comes. The tweet contains a counterintuitive line: it spends most of its time asleep, does not call the model, and does not spend money.

The article's skeleton can be broken down into a five-part set. First, the big picture: each wake-up is a run, which runs inside a session, writes state back when finished, and then goes back to sleep. Being always on is a user experience, not the model running all the time.

The event inbox is the main entry point. Webhooks, scheduled tasks, and background tasks all write into the inbox first, and then a worker picks them up. Do not let every event source call the Agent directly: two events arriving at the same time will fight, and a crash may lose events. The handler should acknowledge quickly; the inbox is the source of truth; one inbox should have only one active worker at a time; and consecutive messages should preferably be merged into a single run.

Timers handle proactivity. There are two types: a follow-up is a deadline the Agent sets for itself, and a schedule is a periodically repeating task. Timers do not start a run directly; the scheduler polls until the time is due and then writes an event into the inbox. Timers are stored separately and should not be mixed into the inbox.

Memory is continuity across runs. The principle is strict: store only what cannot be looked up again. User instructions, user notes, things said in the past, task progress. If it can point to an issue tracker, store a pointer. Every time it wakes up, it first reads the system prompt, tool definitions, and memory files; this context cost must be paid on every run, so memory should be short, and prompt caching should be used to reduce cost. If a session gets too long, compress it or start a new one, but compression loses details, so anything that must be kept should be written into memory.

A Twitter user added that caches generally last only a few minutes to an hour, so if it sleeps too long, it still has to read from the beginning when it wakes. This limitation means memory cannot be written as a long diary.

Permissions carry the highest risk. An always-on Agent holds the user's account and is unattended. Credentials should not enter the Agent's environment; put them in an external proxy and inject them when a request is sent. High-risk actions can be blocked by a classifier, and the most important decisions still have to wait for a human. A deferred tool call can suspend the call, save the session, put the user's reply into the inbox as a new event, and then resume the session. While waiting, the worker can still handle other things. Anthropic itself lists permissions as the highest-risk layer.

The outbox controls when it speaks. At the end of a run, it can send a message, send nothing, or suspend to request approval. In most cases, a single send tool is enough; add a formal outbox when you need to control pacing or provide fault tolerance. The dispatcher reads pending messages and then delivers them. More critical is tuning the volume: too many messages become noise, too few miss things. The article suggests staying quiet first and gradually earning the user's attention. Someone in the comments said the outbox is the most easily underestimated part: trust built by doing ten things right can be wiped out by one random comment in the middle of the night.

Put together: timers and the inbox start a run; the run works inside a session using memory and permissions; the outbox delivers results to the user; and the user's reply becomes an inbox event again. A run can set a timer so its future self wakes up again. The cycle keeps going, and only then does it appear to be always on.

Why it can run now: the article gives cost figures. On a long-horizon coding benchmark, Opus 5.5 is 78% cheaper per solved task than Opus 5, while ordinary tasks are only 40% cheaper. The longer the task, the bigger the drop, and always-on Agents are well positioned to benefit from this. Someone in the comments also reminded that computer sleep can stop scheduled tasks; the machine slept for 3 hours and 22 minutes, and that data cannot be recovered. Engineering details like this matter more than slogans.

Structurally, the experience of an always-on Agent does not first depend on how smart it is; it depends on three things: how often it wakes up, what it remembers when it wakes up, and when it shuts up. Permissions and the outbox should be designed together. A Twitter user suggested first tightening permissions, then constraining the inbox and timers within those permissions, and finally using the outbox to filter timing. This order is closer to implementation than tuning prompts first.