Summary
Always-on agents are stateful and proactive: they manage context across sessions and take actions without direct supervision. Underneath, they run on the same core loop as other agents; the difference is the surrounding architecture, built from primitives that control when the agent wakes up, what carries over between runs, and how its work reaches the user.
The recent resurgence is largely due to model advancements that make these agents more practical to run. Latest models have better judgment — more reliable at understanding user intent and knowing when to check in — and intelligence is getting cheaper, with long-horizon tasks benefiting most. 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. Customers ask how to integrate this experience into their own products: some want to make existing agents more proactive, others to build from the ground up.
Key Points
- An always-on agent is not literally "always on"; that describes the user experience. In reality it spends most of its time asleep, waking periodically to work.
- Each stretch of work is a run: the agent receives an event, completes its task, then saves information about what happened.
- A run works inside a session, the transcript of messages and tool calls. When the run finishes, the agent goes back to sleep and the cycle repeats indefinitely.
- The architecture has five core primitives: an event inbox, timers, memory, permissions, and an outbox.
- Every run begins with an event (user message, webhook, or timer); the worker starts the run; the agent reads and updates memory within its permissions; results go to the outbox for delivery.
- The cycle is self-sustaining: a run can set a timer that wakes the agent later, and a user's reply comes back as an inbox event.
Concepts
Event inbox. Most agents run only when the user sends a message; always-on agents can be triggered by webhooks, scheduled tasks, and background jobs. Letting each event source call the agent directly fails in two ways: two simultaneous events start competing runs, and a crash can lose an event entirely. Instead, every source sends an event to an inbox where a worker picks it up. The simplest version has a durable list of events (usually a database table), a handler (usually an HTTP endpoint) that writes events to the list, and a worker (usually a background service) that reads from it.