# What wakes the agent? The most important question for proactive agents is not what model they use. It is which event is allowed to interrupt them. Published: 2026-05-22 Updated: 2026-05-22 Canonical: https://watch.qordinate.ai/blog/what-wakes-the-agent Markdown: https://watch.qordinate.ai/blog/what-wakes-the-agent.md Author: Harpinder Singh Author URL: https://www.linkedin.com/in/singhcoder/ Image: https://watch.qordinate.ai/images/blog/what-wakes-the-agent.jpg Tags: - proactive agents - agent infrastructure - event layer - interrupts ## Short answer A proactive agent is only as good as its wakeup primitive. Cron can start a loop, webhooks can report change, and a queue can preserve delivery, but the agent still needs an interrupt layer that decides whether a future event matches a durable user intent. Without that layer, "proactive" becomes expensive polling with nicer copy. ## Key takeaways - The wakeup decision is product behavior, not background plumbing. - Cron, webhooks, queues, and heartbeats solve different parts of the problem. - Durable user intent needs to live outside the model turn so future events can be evaluated cheaply. - The best wakeup is usually a filtered delivery with evidence, not a raw app event. - Agent UX improves when users can understand why the agent woke up. ## The hidden design question Most agent demos start with an action: draft the reply, fix the test, summarize the meeting, open the issue. Real proactive systems start earlier. Something changed, and the system decided the agent should spend attention. That first decision shapes everything downstream. It determines cost, latency, user trust, permission scope, and whether the agent feels helpful or noisy. It also determines whether the user can debug the system when it wakes at the wrong time. The same pain shows up across the agent category. OpenAI's Codex automations describe scheduled and heartbeat-style ways to continue work over time: https://developers.openai.com/codex/app/automations. OpenClaw users discuss background assistant runs, local delivery, and "when should it wake?" as a practical operating question: https://github.com/openclaw/openclaw/issues/2081. Research benchmarks such as ProAgentBench and KnowU-Bench evaluate proactive assistance in temporally rich settings where the agent must decide when to intervene, not only what answer to produce: https://arxiv.org/abs/2602.04482 and https://arxiv.org/abs/2604.08455. That is the category shift. The model is no longer just responding. The system is deciding when response is deserved. ## Four wakeup primitives Cron is the blunt primitive. It says "run every N minutes." This is easy to reason about, easy to deploy, and useful for maintenance jobs. It is also ignorant. A cron job does not know whether the user got a relevant email, whether a calendar invite changed, or whether a customer escalation crossed a threshold. It only knows time passed. Webhooks are the change primitive. They say "the source system observed an event." GitHub, Stripe, Slack, Google Workspace, and many other platforms expose this pattern. A webhook is better than polling for broad state because it carries freshness, but raw webhooks are still not agent intent. "A message arrived" is not the same as "wake the agent." Queues are the durability primitive. They preserve work, retries, ordering, and acknowledgements. This matters when agents are local, offline, rate-limited, or busy. Delivery needs to survive the weird edges of real systems. Heartbeats are the liveness primitive. They say "check in, continue, or reconcile." They are useful for long-running work and local runtimes, especially when inbound networking is awkward. But a heartbeat should not become a disguised full-world scan. The missing piece is the matcher between these primitives and user intent. ## Intent has to outlive the chat When a user says, "Tell me when a customer is blocked by a webhook delivery issue," the useful part is not the sentence. It is the future condition. The agent needs to remember the condition, know which sources can satisfy it, evaluate new events, and preserve why a match was found. That condition should not live only in a chat transcript. It should become an operational object: - the user's natural-language intent; - the source streams that can satisfy it; - the fields and evidence that matter; - the confidence threshold for wakeup; - the delivery target; - the allowed actions after wakeup. This is why an event layer belongs beside agent frameworks, MCP servers, and tool routers. MCP helps the agent connect to capabilities. The wakeup layer decides when those capabilities should enter the conversation. ## The agent should wake with evidence A raw event says something happened. A useful wakeup says why it matters. For an inbox watcher, that evidence might include sender, recipients, subject, thread history, and matching phrases. For a calendar watcher, it might include organizer, attendees, location, meeting type, and what changed. For a code workflow, it might include the failing check, branch, owner, and related issue. The agent should not begin with "something changed." It should begin with "this event appears to match this durable condition, for these reasons, with this confidence." That makes the next model turn cheaper and easier to review. It also lets the user correct the watch instead of blaming the whole assistant. ## Why this is a UX problem too Users do not experience wakeups as infrastructure. They experience them as interruptions. A good wakeup feels like someone remembered what mattered and brought the right thing forward. A bad wakeup feels like another notification stream wearing an assistant costume. The difference is not only model quality. It is whether the system filtered before it spoke. This also affects permissions. An agent woken by a direct user command can carry one authority envelope. An agent woken by a third-party webhook should carry a narrower one. An agent woken by a local heartbeat may need to reconcile state before it acts. Source, intent, and evidence should shape what the agent is allowed to do. ## FAQ ### Is cron always bad for agents? No. Cron is fine for fixed maintenance, batch checks, and predictable reconciliation. It becomes weak when the user actually wants event-level awareness: "when this kind of thing happens, wake the right assistant with context." ### Are webhooks enough to make an agent proactive? No. Webhooks say that a source changed. A proactive agent still needs filtering, durable intent, routing, acknowledgements, and permission boundaries before the event becomes a useful wakeup. ### Why not let the model decide every few minutes? Because most minutes are boring. Sending broad context to a model on every tick burns tokens, increases latency, and creates false positives. Cheap event filtering should happen before expensive reasoning. ## Further reading - https://developers.openai.com/codex/app/automations - https://github.com/openclaw/openclaw/issues/2081 - https://arxiv.org/abs/2602.04482 - https://arxiv.org/abs/2604.08455 - https://svix.com/resources/faq/webhooks-vs-api-polling