# Local agents need interrupts, not bigger background loops A broader view of why desktop and local agents need upstream event filtering before they can become truly useful. Published: 2026-05-14 Updated: 2026-05-14 Canonical: https://watch.qordinate.ai/blog/make-openclaw-proactive-without-polling-everything Markdown: https://watch.qordinate.ai/blog/make-openclaw-proactive-without-polling-everything.md Image: https://watch.qordinate.ai/images/blog/make-openclaw-proactive-without-polling-everything.jpg Tags: - local agents - OpenClaw - proactive agents ## Short answer Local agents need upstream interrupt filtering. Give the local runtime matched, user-relevant interrupts instead of asking it to become the event bus for every connected app. ## Key takeaways - Local agents are powerful because they sit close to the user, but that makes event ingestion and permissions harder. - Polling every source app from the local runtime turns the agent into an event bus, scheduler, classifier, and reasoning engine at once. - Pull delivery is a better fit for local trust boundaries than inbound webhooks. - OpenClaw is one concrete example, but the pattern applies to any local or semi-local assistant. - The best local agents will think less often and wake with better context. ## Why this matters Local agents have a different superpower from hosted agents. They can live closer to the user’s machine, files, workflows, sessions, and preferences. They can feel personal in a way a stateless cloud endpoint rarely does. But local agents have a proactivity problem. They are often offline, asleep, behind NAT, or running inside a workspace that should keep public endpoints closed. So the obvious hosted pattern, "send a webhook to the agent," does not fit. Teams usually fall back to a background loop that checks everything. That works until it gets noisy, expensive, or unsafe. ## Do not turn the local agent into the event bus It is tempting to make the local agent poll every app the user cares about. Inbox, calendar, GitHub, Slack, Linear, CRM, files, browser tabs, maybe all of it. Then the agent can decide what matters. That gives the agent maximum context and minimum architectural discipline. The local runtime becomes an event bus, classifier, scheduler, delivery queue, auth manager, and reasoning engine. It burns tokens to discover nothing happened. It gets harder to pause safely. It becomes difficult to explain why the agent woke up, missed an event, or notified the user twice. Local agents should receive interrupts. Upstream infrastructure should manufacture those interrupts from raw app streams. ## Proactivity starts before the model turn The best local agent experience calls the model when there is a reason, not every minute by default. That requires upstream filtering. An event source produces raw activity. A match layer compares it against durable user intent. Only then does the local agent receive a compact event that is worth reasoning about. This matters even when the final action needs deep intelligence. The model should reason about a likely-relevant event, not act as the first sieve for every inbox message and calendar mutation. ## Pull delivery fits the local trust boundary For local runtimes, pull delivery is often the least surprising model. The local process calls out to fetch pending matched events. Nothing on the internet calls into the user’s machine. The agent can run a small poller with backoff. It can acknowledge deliveries once accepted. If the machine is offline, events wait. If the user disables the plugin, delivery stops without needing to revoke a public endpoint. The important distinction is that this polling loop is over matched deliveries, not raw source apps. It is a narrow interrupt stream, not a broad "check the world" loop. ## OpenClaw is one example of the pattern OpenClaw makes this concrete because it is a local agent runtime with plugin support and user-facing sessions. A plugin can expose tools for registering watches and run a puller for matched deliveries. OpenClaw makes the pattern visible, and the pattern reaches beyond OpenClaw. Any local or semi-local agent runtime needs the same separation: - Tools for creating and managing future conditions. - A delivery path for matched events. - A way to route events to the right local session. - A safe fallback when app auth expires. Once those pieces exist, local agents can be proactive without becoming a permanent full-context polling engine. ## The UX should stay user-shaped Users do not want to think in polling intervals, event schemas, webhook endpoints, or provider triggers. They want to say, "tell me when this kind of thing happens," and answer only the questions required to make that condition precise. If the system needs an email address, ask. If it needs a connected app, return a connect link. If the request is too vague to run, say so. The user experience should be conversational, but the resulting condition should be durable and operational. That combination is the key: natural setup, structured execution. ## Local agents become better when they think less often The goal is to reserve the local agent’s capability for moments that deserve it. A good interrupt layer lets the agent wake up with context, intent, and a reason. That makes the agent cheaper, calmer, and more trustworthy. It also makes the whole system easier to debug, because every wakeup has a trail: source event, match decision, delivery, acknowledgement. Local agents do not need bigger background loops. They need better interrupts. ## FAQ ### Why should local agents avoid polling every app directly? Because broad polling makes the local runtime responsible for ingestion, filtering, scheduling, delivery, auth, and reasoning. That increases cost, complexity, and the chance of noisy or unsafe behavior. ### What is an interrupt stream for a local agent? An interrupt stream is a reduced set of matched events that have already passed through user intent and source-event filtering. The local agent receives fewer events, but each one has a clearer reason to wake the model. ### Why is pull delivery better for local assistants? Pull delivery lets the local runtime make outbound requests for pending events. The user does not need to expose a webhook endpoint, run ngrok, or open inbound access to their machine. ### Is this only about OpenClaw? No. OpenClaw makes the problem concrete, but the same pattern applies to Hermes-style orchestrators, desktop coding agents, home-server assistants, and any runtime that lives close to the user. ## Further reading - https://www.reddit.com/r/openclaw/comments/1s7tkzr/every_ai_assistant_built_is_reactive_by_design_it/ - https://www.reddit.com/r/openclaw/comments/1sltjrt/what_actually_makes_ai_agents_reliable_on_long/ - https://www.reddit.com/r/hermesagent/comments/1t9chdk/the_ai_agent_setup_that_finally_clicked_for_me/