---
title: "When Should an Always-On Personal Agent Wake Up? · Comma Blog"
description: "Learn how an always-on personal agent can filter continuous events, wake only when a decision matters, and return consequential choices to you."
url: https://comma.surf/blog/when-should-an-always-on-personal-agent-wake-up
language: en
---

[Back to blog](https://comma.surf/blog)

Comma Team · October 29, 2026 · 8 min read

# When Should an Always-On Personal Agent Wake Up?

Learn how an always-on personal agent can filter continuous events, wake only when a decision matters, and return consequential choices to you.

[Get started](https://app.comma.surf/) [Read the docs](https://comma.surf/docs/salix/loops)

An always-on personal agent should not behave like a notification feed with better grammar. Its job is not to react visibly to every new email, issue, price change, document edit, or calendar update. Its job is to keep watch while you are elsewhere, recognize the small fraction of changes that alter what should happen next, and bring the right work back into focus at the right level.

That makes “when should the agent wake up?” a design question, not merely a performance question. Wake too often and the agent becomes another source of noise. Stay quiet too aggressively and it misses the reason you asked it to watch in the first place. Act without a clear boundary and a useful background system becomes an authority problem.

The right answer is a sequence of decisions. A new event may deserve no response, a later review, a turn from the main agent, or your direct judgment. Those are different outcomes, and a trustworthy agent should not collapse them into one.

## Always-on should describe continuity, not interruption

“Always-on” is valuable because the world does not organize itself into chat sessions. A pull request can fail after you close your laptop. A vendor can change a delivery date while you are in a meeting. A contract can be signed three days after you last discussed it. The agent needs continuity across those gaps if it is going to own an ongoing responsibility.

Continuity does not require constant reasoning. Most events are duplicates, routine confirmations, irrelevant changes, or information that will still be useful later. Waking a large model for every event wastes compute, but the larger cost is behavioral: if every wake becomes a message, the agent spends the user’s attention as though attention were free.

[Research on workplace notifications](https://www.microsoft.com/en-us/research/publication/notifications-and-awareness-a-field-study-of-alert-usage-and-preferences/) has long found the same tension. People value passive awareness, yet notifications disrupt the task already in focus. Research on [bounded deferral](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/bdef_studies.pdf) also shows why “now or never” is the wrong choice: an alert can be delayed within a known bound so that awareness is preserved without treating every arrival as urgent.

An always-on agent should therefore keep three clocks separate:

- the time an event arrives;
- the time the agent needs to reason about it;
- the time the user needs to know or decide.

Sometimes all three are immediate. Usually they are not.

## A wake is not a notification, and a notification is not permission

The most important boundary is easy to miss. Detecting an event, waking the main agent, notifying the user, and taking an external action are four separate steps.

Suppose Comma is following a pull request. A new review comment arrives. The watch process can first decide whether the comment changes anything relevant. If it does, the main agent can wake and inspect the pull request, the surrounding discussion, and the task it belongs to. The agent may be able to update a draft or prepare a fix without interrupting you. It may need to tell you that the merge window is at risk. Or it may reach a decision—such as accepting a security trade-off—that belongs to you.

None of those conclusions follows from the arrival of the comment alone.

This separation is how Comma’s architecture is intended to work. A lightweight Loop can keep watch and wake the main agent only when needed; the main agent then does the contextual work. The technical details, including how Loops filter events, deduplicate wakes, and operate under quotas, are covered in [Programmable event loops for our distributed agent harness](https://comma.surf/blog/agent-programmable-event-loops). The reader-facing principle is simpler: an event is evidence, not an instruction, and a wake is a request to investigate, not permission to act.

## The four tests for waking the main agent

A useful wake policy can be expressed as four tests. They are not a scorecard where a high total automatically wins. Each test removes a different kind of false alarm.

### 1. Did something materially change?

The first test is about state, not activity. A new message is activity. A deadline moving forward, a blocker appearing, an approval arriving, or a promised condition becoming true is a state change.

An agent should stay quiet when the new event repeats what it already knows, acknowledges a message without changing the plan, or falls outside the responsibility it was asked to monitor. Stable identifiers and deduplication help at the system level, but semantic repetition still needs judgment: two different messages can communicate the same non-change.

This test prevents motion from masquerading as progress.

### 2. Does the change affect an active goal or constraint?

Materiality is personal. A flight price dropping is not inherently important; it matters if it falls below the user’s stated budget for a trip they still intend to take. A failed build matters differently on an abandoned branch, an exploratory branch, and a release candidate.

The agent needs the goal, the current plan, the relevant constraints, and enough provenance to know where those facts came from. Without that context, “important” tends to mean generally dramatic rather than specifically useful.

This is also where scope protects trust. A Loop following one repository should not turn a passing reference to another project into a new assignment. Incoming content can inform the watched responsibility; it cannot silently expand it.

### 3. Is there an action window?

Some changes matter but do not require reasoning now. A report that will be reviewed on Friday can wait in a digest. A delayed shipment may become relevant only if it threatens a dependent event. By contrast, a meeting cancellation that frees a scarce booking window or a production regression spreading to more users may lose value with every minute of delay.

The question is not simply “Is this urgent?” It is: **Would reasoning now create a better option than reasoning later?**

If yes, wake the main agent. If the information will remain equally actionable, defer it to a natural checkpoint or bundle it with related updates. If no action is possible and no plan changes, record it and remain quiet.

### 4. Who owns the next decision?

After the main agent has gathered context, it should decide who has authority for the next step.

Routine, reversible work within the user’s instruction can often continue without an interruption. The agent might update its task notes, prepare a comparison, or draft a response. A consequential, ambiguous, or preference-sensitive decision should return to the user. In Comma, work that needs a human decision can wait in **Needs Review** rather than being guessed through or marked complete.

Good escalation is specific. It should say what changed, why that changes the plan, what the agent has already checked, what decision is needed, and when the decision stops being useful. “What do you want to do?” is not a handoff; it is unfinished analysis.

## Four legitimate outcomes—not just wake or sleep

Once the tests are applied, the agent has four useful responses.

**Stay quiet.** Nothing relevant changed, the event is a duplicate, or it falls outside the watch. Quiet should be a deliberate conclusion with enough internal trace to diagnose mistakes—not the absence of processing.

**Defer or bundle.** The change is relevant but its value survives a delay. Add it to the next task checkpoint, briefing, or compact digest. Deferral needs a boundary: “later” should mean a known time or condition, not an unowned backlog.

**Wake the main agent.** The event may change the plan, requires broader context, or is too uncertain for the lightweight filter. Waking is appropriate even when the final result is silence; the main agent may investigate and conclude that no user-facing message is necessary.

**Return control to the user.** The agent has reached a decision involving authority, risk, taste, or a trade-off only the user can make. It should preserve the work already done and surface the smallest decision that unlocks progress.

This four-way model makes uncertainty manageable. A watch process does not have to pretend confidence when evidence is weak. It can wake the main agent for a deeper check. The main agent, in turn, does not have to manufacture autonomy when a decision belongs to the user.

## Confidence should change the route, not hide the event

An always-on system will sometimes be wrong. The dangerous failure is not merely a false alarm; it is a confidently suppressed event the user never gets a chance to recover.

Comma’s default posture reflects that asymmetry. When Loops use Jev to screen a followed pull request, issue, or thread, “quiet” requires high confidence. Uncertainty and errors go to the main agent, which is instructed to verify the source before writing to the user. Jev can classify; it cannot send messages, change external state, or grant itself more access. The current behavior and limits are documented in [Meet Salix, Comma’s agent harness](https://comma.surf/agent) and the [Loops documentation](https://comma.surf/docs/salix/loops).

That design does not eliminate mistakes. A confidently wrong quiet decision can still hide an update. It does, however, put uncertainty on the safer route: deeper inspection rather than silent dismissal. Users should also be able to pause or delete a watch, narrow its scope, and take operational access back. An agent earns the right to be present in the background by making that presence inspectable and reversible.

## A good interruption arrives with work already done

The value of an always-on personal agent is not that it notices sooner than you. Monitoring tools already do that. The value is that it can connect the change to an active responsibility and reduce the amount of work required from you.

A useful interruption might read like this in substance:

> The reviewer requested a change to the authentication flow. It blocks the release criterion you set for Thursday. I checked the current branch and reproduced the concern. I prepared a patch and tests; approving the compatibility trade-off is the only decision I need from you before I apply it.

That message carries context, consequence, completed investigation, a proposed next step, and a clear decision boundary. It does not ask the user to reconstruct why the event matters. It also does not confuse a plausible next action with authorization to take it.

The same standard applies when the agent chooses not to interrupt. A deferred update should reappear at the promised checkpoint. A quiet decision should remain auditable. A task that needs judgment should wait visibly, not disappear inside an endless conversation.

## The goal is calm continuity

An always-on agent should create continuity without demanding continuous attention. The outer system watches cheaply and narrowly. The main agent wakes when a change may alter the plan. It investigates before it interrupts. It continues routine, reversible work when the user has already supplied the authority, and it returns consequential choices with the relevant work attached.

The resulting experience is not an agent that talks more. It is an agent that can remain responsible while staying quiet—and knows exactly when silence is no longer useful.

## Frequently asked questions

### What runs before the main agent wakes?

In Comma, a lightweight Loop watches the chosen inbox, repository, feed, API or webhook. Its program can apply deterministic rules and may ask Jev for a fast typed decision. The main agent and its larger context run only when the Loop sends a wake for deeper investigation or action.

### Should every agent wake become a user notification?

No. A wake lets the main agent inspect context and decide what the event changes. It can continue background work, defer an update, or conclude that the user does not need to be interrupted. User attention should be requested only when awareness or judgment is time-sensitive.

### What should happen when the agent is uncertain?

Uncertainty should move the event to a more capable decision-maker. A lightweight filter can wake the main agent; the main agent can verify the source, gather context, and either proceed within its authority or ask the user. Uncertainty should not be converted into a confident “quiet” decision or an unauthorized action.

### How can a user stop an always-on watch?

Comma lets users ask it to pause or delete a Loop. Access to connected computers can also be returned to read-only by disabling operations. An always-on responsibility should always have an understandable scope, a visible state, and a practical off switch.

## Turn a signal into a useful next step

Start with one event source and write down what would materially change your plan, how long the action window stays open, and which decision must remain yours. Explore [Comma's Agent](https://comma.surf/docs/agent) to see how proactive attention connects to Tasks and review, or read the [Loops documentation](https://comma.surf/docs/salix/loops) for the current monitoring model and limits.

Personal Agents

[Back to blog](https://comma.surf/blog)

Share

## Related posts

October 28, 2026

### [What's an Always-On AI Agent?](https://comma.surf/blog/what-is-an-always-on-ai-agent)

October 27, 2026

### [Personal Agent vs AI Assistant: What Is the Difference?](https://comma.surf/blog/personal-agent-vs-ai-assistant)

October 26, 2026

### [What's a Personal Agent? The AI That Keeps Working](https://comma.surf/blog/what-is-a-personal-agent)

## Try Comma, Now.

[Get started](https://app.comma.surf/)
