Anthropic ties the renewed interest to model improvements. Newer versions show better judgment about user intent and about when to check in, while the cost of intelligence has dropped sharply. On one long-horizon coding benchmark, Opus 5.5 cost 78% less per solved task than Opus 5, compared with 40% less on typical workloads.
Product teams now face immediate demand for this capability. Some want to make existing agents more proactive, while others are building from scratch. Either way, the architecture differs fundamentally from a reactive chatbot, and Anthropic says it comes down to five primitives working together.
Five Primitives That Keep an Agent Awake
- Event inbox: All triggers flow through a durable queue instead of calling the agent directly. A handler writes each incoming event to a database table, and a worker polls the table to start runs. This prevents simultaneous events from spawning competing runs and stops crashes from losing messages. The inbox tracks status and deduplicates events using the unique identifiers the source provides.
- Timers: These cover two cases. Follow-ups are deadlines the agent sets for itself, such as checking on a pending user reply. Schedules are recurring tasks on a fixed cadence, like a daily newsletter. Both live in a separate durable store, and a background scheduler polls it at fixed intervals and adds due timers to the inbox as events.
- Memory: Persisted across runs in its own store, it holds user instructions, notes on preferences, summaries of past messages, and task progress files. Anthropic implements it as a directory of files mapped to durable storage, so it outlives any single worker process.
- Permissions: These define what an unattended agent can do. A credential proxy injects real credentials into outgoing requests without exposing them to the agent, auto-mode classifiers block dangerous actions, and deferred tool calls pause execution until the user approves.
- Outbox: Outgoing messages are batched and paced here, so constant low-value notifications do not overwhelm the user.
Where a Run Ends and a Session Carries On
A run is one stretch of work started by an event. The agent receives input, completes the task, saves what it learned to memory, and goes back to sleep. A session is the continuous transcript of messages and tool calls. New events resume an existing session when they continue earlier work and otherwise start a fresh one, which keeps long-running tasks coherent without stuffing every context window with irrelevant history.
When a run finishes, the agent can queue a message in the outbox, decide that nothing needs delivering, or use a deferred tool call to ask for clarification. The outbox dispatcher then decides what to send and when.
On cost, Anthropic recommends prompt caching, since the agent loads system prompts, tool definitions, and memory files at the start of every run. It also warns that long sessions force a tradeoff: compacting older messages and starting fresh sessions both lose detail, so anything critical has to be written to memory during the run itself.
Hashlytics Take
Notice how little of this list is about the model. Four of the five primitives are plain infrastructure: queues, timers, file storage, and a gatekeeper for outgoing messages. The only one that exists purely because agents are unsupervised is permissions, and the credential proxy is the telling detail, because it assumes an agent should never hold the keys it uses. That is a sensible default for software that acts while nobody is watching. The harder question the guidance leaves open is the outbox. Teams will find it easy to make an agent proactive and much harder to make it quiet, and the products that win this category will probably be the ones that send fewer messages, not more.
Follow Hashlytics on Bluesky, Facebook, LinkedIn , Telegram and X to Get Instant Updates
