--- title: "What's an Always-On AI Agent? · Comma Blog" description: "Learn what makes an AI agent truly always on: durable state, event-driven attention, recoverable execution, and user control. See how Comma works." url: https://comma.surf/en-gb/blog/what-is-an-always-on-ai-agent language: en-GB --- [Back to blog](https://comma.surf/en-gb/blog) Comma Team · 28 October 2026 · 11 min read # What's an Always-On AI Agent? Learn what makes an AI agent truly always on: durable state, event-driven attention, recoverable execution, and user control. See how Comma works. [Get started](https://app.comma.surf/) [Read the docs](https://comma.surf/en-gb/docs/agent) An always-on AI agent is an agent that can remain responsible for work when no conversation is open. It can preserve the state of an assignment, wait for time or the outside world to change, resume in an appropriate environment, and return control when the next decision belongs to a person. “Always on” does **not** mean a large language model thinks continuously. It does not mean a computer has to burn resources at full power around the clock. And it should not mean that an agent constantly sends messages or acts without permission. The useful promise is continuity: the responsibility remains alive even while most of the system is asleep. Scheduling a prompt or keeping chat history does not settle the practical questions: what survives a restart, what wakes the agent, where does it continue working, and how can a user stop it? Answers to those questions turn “24/7” from a slogan into a system property. ## Always-on is about continuity, not uptime Uptime describes whether a process is running. Continuity describes whether the work still has an owner and a valid next step. Imagine asking an agent to watch for a signed contract, update a launch checklist when it arrives, and prepare the next decision for you. The contract may come back tomorrow or next week. During that wait, useful reasoning is not happening. The agent does not need an open chat, a hot model session, or a browser refreshing the inbox every minute. It needs a durable record of the responsibility and a reliable way for the relevant event to bring that responsibility back into motion. The distinction becomes obvious during failure. A process can run continuously and still lose the assignment after a crash. Another system can scale to zero for hours, then reconstruct its state and resume correctly when an event arrives. The second system is more meaningfully always on. This is why durable-agent infrastructure separates waiting from computing. Microsoft’s current [Durable Extension for Agent Framework](https://learn.microsoft.com/en-us/agent-framework/hosting/durable-extension), for example, describes agents that persist state across worker executions, pause without consuming compute or model tokens, and resume from external events. Google’s guide to [long-running agents with event-driven resumption](https://developers.googleblog.com/build-long-running-ai-agents-that-pause-resume-and-never-lose-context-with-adk/) demonstrates the same principle with persistent checkpoints and webhooks. The implementation details differ, but the architectural lesson is stable: an always-on responsibility does not require an always-running model. ## The six conditions behind a credible always-on agent There is no single feature that makes an agent always on. The property emerges when six conditions work together. ### A continuing identity owns the responsibility The system needs a stable identity to which messages, events, permissions, tasks, and user expectations can be attached. If every conversation creates an unrelated agent with no shared operating context, there is nobody for later events to wake and nobody accountable for continuing the work. Continuing identity does not require unlimited memory. It means the user can return to the same agent and the system knows which responsibilities belong to it. Personal facts, conversation history, and task state can still have different lifetimes and controls. ### Working state survives idle time An assignment must retain more than its opening prompt. The state needed to resume may include the intended outcome, completed actions, working artifacts, constraints, the current blocker, and the next valid step. That state should be durable enough to survive ordinary interruptions: a closed browser, a sleeping computer, a deployed update, a worker restart, or the passage of several days. A transcript can help reconstruct what happened, but reconstruction is not the same as recovery. A credible system knows which state is authoritative instead of asking a model to infer the truth from a long conversation every time it wakes. The deeper protocol for carrying one assignment across dependencies is a separate question from the category definition. At this level, the test is simpler: can the system preserve enough valid state to continue without a new briefing? ### Time and events can re-enter the system Work in the outside world does not advance only when a user sends a message. Deadlines arrive. Files change. Replies land. A device comes back online. An approval is recorded in another application. An always-on agent therefore needs more than an interactive input box. It needs a path for a timer or external event to reach the responsibility it affects. That path might be a webhook, a message queue, a schedule, a connector, or a narrowly scoped watch process. The important part is that the event can be associated with the right agent and the right state. This does not imply that every event deserves a full reasoning run. Event-driven operation is valuable precisely because most of the system can remain quiet until there is work to evaluate. Deciding whether a particular event should wake the main agent—and whether that wake should interrupt a person—is a separate policy problem from defining the always-on system itself. ### An execution environment is available when work resumes Remembering the next step is not enough if the agent has nowhere to perform it. Some work can happen through an API. Other work needs a browser, a cloud computer, a local machine, or a specialist agent runtime. The environment must be available when the responsibility becomes active again, with the files, tools, and permissions the next step requires. “Available” does not mean permanently running. A cloud computer can sleep while its storage persists and wake when needed. A local machine can remain disconnected until a task requires it. What matters is that the agent can identify the required environment and handle its absence honestly. Environment boundaries are also part of correctness. Comma’s [device documentation](https://comma.surf/en-gb/docs/salix/devices) says that Salix does not silently move work from an offline device to another computer. The request can fail and be retried when that device returns. That is less magical than pretending every computer is interchangeable, but it preserves the location, access, and execution conditions on which the work depends. ### Recovery is part of normal operation An always-on system will eventually encounter a restart, duplicate event, unavailable service, expired credential, or broken connection. Reliability therefore cannot depend on one process remaining perfect forever. The system needs a recovery path: persistent state, checkpoints or an equivalent source of truth; bounded retries; a way to avoid repeating an external action; and a visible failure state when automatic recovery is no longer safe. A restart that quietly forgets what was acknowledged is not recovery. Neither is an infinite retry loop that consumes resources without changing the outcome. Comma’s [Loops documentation](https://comma.surf/en-gb/docs/salix/loops) provides one concrete example. A Loop can save a checkpoint and receive it when it starts again. After a fault, Salix restarts it from that checkpoint within a bounded retry policy; repeated failure stops the Loop and tells the agent. The full implementation—including durable events, deduplication, placement, and capability limits—is explained in [Programmable event loops for our distributed agent harness](https://comma.surf/en-gb/blog/agent-programmable-event-loops). When evaluating a product, check whether interruption and recovery are planned states rather than surprises. ### The user can see and constrain the continuity Persistence increases the importance of control. A one-off chat ends naturally. A background responsibility needs an understandable scope, a visible status, and an effective off switch. Users should be able to tell what the agent is responsible for, which sources it watches, which environment it can use, and what authority it has there. They should be able to pause or end the responsibility, revoke access, and recover work already produced. The system should surface failures and consequential decisions instead of treating silence as evidence that everything is fine. This is also why always-on and autonomous are not synonyms. Persistence says the system can remain available. Autonomy describes which decisions or actions it may take without asking. An agent can be highly persistent and deliberately conservative: it can prepare, verify, organise, and wait while returning external commitments or irreversible choices to the user. ## Four operating modes—not one endless run The phrase “always on” suggests a single continuous activity. In practice, a useful agent moves among distinct modes. It may be **working**, with a model and tools actively progressing an assignment. It may be **waiting**, because a time, event, environment, or human decision has not arrived. A lightweight watcher may be **monitoring** a narrow condition without waking the main agent. Or the responsibility may be **stopped**, because the user ended it or a failure exceeded the safe recovery policy. These modes matter for cost and attention as much as reliability. Model inference, cloud compute, event ingestion, storage, and third-party APIs can all have different billing behaviour. A product should not collapse them into an unqualified claim that “the agent runs 24/7.” A quiet background responsibility may use storage and monitoring resources while using no large-model tokens; an active task can consume both model and compute resources; a stopped responsibility should consume neither beyond retained state. Comma reflects this separation in its own runtime. [Salix](https://comma.surf/en-gb/docs/salix) runs the agent outside a permanently hot sandbox. When computer work is needed, it can wake a cloud virtual machine whose storage persists between uses. For ongoing attention, small Loops can watch events without keeping the main agent loop active. Only when a Loop determines that the agent is needed does the main loop run. That architecture is Comma’s implementation, not the universal definition. Another product may use durable workflows, queues, serverless functions, or long-running workers. The test is whether the whole system preserves responsibility through idle periods—not whether it uses a particular runtime. ## Always-on, scheduled, and long-running are different promises A scheduled automation runs an instruction at a known time. It can be extremely useful without maintaining a continuing agent identity or responding to unscheduled changes. If a daily job generates a report from fixed inputs, a schedule may be all the system needs. A long-running workflow can preserve state across several steps and wait for a signal. It becomes agentic when models participate in interpreting information, choosing tools, or adapting the plan. It becomes meaningfully always on when that durable workflow belongs to a continuing agent that can receive new relevant events and act within user-governed boundaries. A chatbot can also remember past conversations and offer reminders. Those features improve continuity for the user, but they do not by themselves prove that work persists outside the chat. The decisive question is not whether the system remembers something about you. It is whether an active responsibility can wait, resume, recover, and reach an authorised environment without being recreated manually. This distinction prevents overbuilding, too. Not every request needs an always-on agent. A one-time explanation, rewrite, calculation, or brainstorming session is often better served by an interactive model. Always-on operation earns its complexity when the outcome depends on time, external change, several work environments, or a responsibility that remains open after the current conversation ends. ## A practical continuity test To evaluate an “always-on” product, give it one realistic responsibility that contains a gap. Ask it to monitor a defined condition, prepare the next step, and stop before a consequential action. Then examine what the product can show you. Where is the assignment stored after you close the interface? What exact condition brings it back into motion? Does it know which environment holds the working material? Can it resume after a restart without repeating completed actions? What happens when the event is duplicated or the required device is offline? Can you pause the watch, revoke access, or end the assignment without deleting all of your history? Finally, look at what reaches you. A system that forwards every event has built a notification pipeline, not necessarily an agent. A system that acts on every event has confused availability with authority. A useful always-on agent connects a change to an existing responsibility, performs the work already permitted, and asks for attention only when attention changes the outcome. ## How Comma stays available without staying noisy [Comma](https://comma.surf/en-gb/) is a free, open-source personal agent designed around one continuing agent across conversations and devices. Quick questions can remain in chat, while larger responsibilities become Tasks. Comma can work in connected apps and files, on an attached Mac or Linux device, or on a cloud computer that wakes when needed. Its always-on layer is Salix. A Comma agent can create a Loop to watch a bounded source such as an inbox, repository, feed, API, or webhook. The Loop runs separately from the main reasoning loop, can maintain a small checkpoint, and can notify the agent when work requires it. Because the main agent does not need to inspect every quiet interval, “always available” does not become “always spending model tokens.” A Loop may still call a fast decision model or another service, so background work is not automatically free; costs depend on what the Loop actually does. The same continuity remains subject to user control. Attached computers begin read-only until the user allows operations, and device access can be revoked. Loops have capability and wake limits. A larger Task can return to **Needs Review** when a decision belongs to the person. Comma can also be [self-hosted](https://comma.surf/en-gb/self-host), though the operator then owns the availability, upgrades, backups, model configuration, and other infrastructure required to keep that instance running. Comma’s approach is one answer to the category’s central problem: let the responsibility persist while allowing expensive compute, models, and user attention to remain idle until they are actually needed. ## Frequently asked questions ### Does an always-on AI agent run a model 24/7? No. A well-designed system can persist state and listen for timers or events while the main model is inactive. The model runs when the system needs reasoning or generation. Lightweight monitoring, storage, and external services may still consume resources while the agent waits. ### Is an always-on agent the same as an autonomous agent? No. Always-on describes continuity and availability across time. Autonomy describes what the agent may decide or do without human approval. An always-on agent can operate with narrow authority and return consequential decisions to the user. ### Is a scheduled AI task an always-on agent? Not necessarily. A schedule can launch a stateless prompt at a fixed time. An always-on agent additionally preserves the responsibility and relevant state, can respond to appropriate external events, recovers from interruptions, and continues within persistent user controls. ### Does the agent’s computer need to stay running? It depends on the required environment. Cloud or server-side work can continue while a personal laptop is closed. Work that depends on files or applications available only on a specific local device must wait for that device. Some cloud environments can sleep between actions while keeping their storage. ### What happens when an always-on agent fails? The system should recover from a known checkpoint or durable state, avoid repeating completed external actions, and use bounded retries. If it cannot recover safely, it should stop visibly and tell the agent or user what failed instead of retrying forever or silently abandoning the responsibility. ### Can I turn an always-on agent off? You should be able to pause or end a background responsibility and revoke the access it uses. “Always on” should mean available when authorised, not impossible to stop. In Comma, [Loops can be paused or deleted](https://comma.surf/en-gb/agent), and access to connected devices can be revoked. ## The agent can sleep; the responsibility cannot disappear An always-on AI agent is not defined by continuous model activity. It is defined by a continuous chain of responsibility: a stable owner, durable state, a path for time and events to matter, an available execution environment, recoverable operation, and controls that remain with the user. When those pieces exist, most of the system can be quiet most of the time. The model can stop. The cloud computer can sleep. The user can close the app. Work resumes because the responsibility is still intact—not because someone remembered to type “continue.” [See how Comma runs one continuing personal agent across Tasks, devices, and background Loops](https://comma.surf/en-gb/docs/agent). Personal Agents [Back to blog](https://comma.surf/en-gb/blog) Share ## Related posts 27 October 2026 ### [Personal Agent vs AI Assistant: What Is the Difference?](https://comma.surf/en-gb/blog/personal-agent-vs-ai-assistant) 26 October 2026 ### [What's a Personal Agent? The AI That Keeps Working](https://comma.surf/en-gb/blog/what-is-a-personal-agent) 28 October 2026 ### [Keep your iPhone photos local, and let Comma find them](https://comma.surf/en-gb/blog/local-iphone-photo-search) ## Try Comma, Now. [Get started](https://app.comma.surf/)