Hosted services can receive webhooks directly. Local agents usually should not. A practical local assistant needs pull delivery: a durable upstream service stores matched wakeups, the local runtime checks for pending work, accepts only what it can handle, and acknowledges delivery after the handoff succeeds.

Short answer

Key takeaways

Local agents live behind laptops, home networks, VPNs, sleep states, and changing IPs.
Raw inbound webhooks are a poor default for personal machines.
Pull delivery lets the agent receive relevant work without exposing a public endpoint.
Durable acknowledgements matter because agent sessions fail, restart, and move across machines.
This pattern works best after an upstream layer has already filtered source events against user intent.

The hosted assumption breaks locally

Webhooks are the native language of modern SaaS integrations. A provider sends an HTTP request to a public endpoint, the receiver validates it, stores it, and processes it. For hosted systems, that is a great default.

Local agents are different. They might run on a laptop that sleeps, a developer workstation behind NAT, a home server with no public hostname, or a private network connected through Tailscale. Asking every user to expose a public webhook receiver is a support burden and a security footgun.

OpenClaw's architecture and remote-access docs reflect this local-first tension: https://docs.openclaw.ai/concepts/architecture and https://docs.openclaw.ai/gateway/remote. Claude Desktop's local MCP model has a similar shape: the user gets powerful local tool access, but local networking and trust boundaries are different from cloud services: https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop.

The delivery layer has to respect that reality.

Push the event upstream, pull the wakeup locally

The pattern is simple:

Source systems push or sync raw events upstream.
An event layer filters those events against durable user watches.
Matched wakeups become pending deliveries.
The local agent pulls pending deliveries when it is online.
The local agent acknowledges what it accepted.

This keeps raw source noise away from the local runtime. It also avoids exposing the local machine to the public internet.

The upstream service can still use webhooks internally. GitHub, Google Calendar, Stripe, Slack, and many others can push change to a hosted endpoint. But the local agent receives a smaller, safer object: "this watch matched, here is the evidence, here is the destination, here is what you may do."

Acknowledgements are product behavior

Delivery is not complete when the local runtime sees an item. It is complete when the right session accepts it and the system records what happened.

Without acknowledgements, users get weird failures:

the same wakeup appears twice;
an agent misses a delivery while the laptop sleeps;
a task starts on one machine and resumes on another with no context;
a source event matches, but nobody knows whether the assistant handled it;
retries create duplicate actions.

Webhook infrastructure has mature retry and idempotency patterns for these reasons. Svix's webhook resources cover retry behavior and the difference between webhooks and polling: https://svix.com/resources/webhook-best-practices/retries and https://svix.com/resources/faq/webhooks-vs-api-polling. Message brokers such as RabbitMQ also make acknowledgement semantics central: https://www.rabbitmq.com/docs/confirms.

Agent delivery should borrow that seriousness. A wakeup is not just a notification. It is a handoff into a system that may act.

Pull cadence is not the same as polling everything

Someone might ask: is pull delivery just polling with better branding?

Not if the upstream event layer is doing its job.

Polling everything means the local agent repeatedly checks broad source state: inbox, calendar, GitHub, Slack, docs, and more. Pull delivery means the agent checks a narrow pending-work queue that already contains matched evidence. The difference is enormous for cost and attention.

The local runtime can use a heartbeat or short poll to ask, "do I have matched work?" It should not use that heartbeat to reread the world.

Security gets easier to explain

Pull delivery also gives users a clearer permission model.

The local agent can authenticate outbound to the delivery service. The service can restrict deliveries by device, workspace, watch, and user. The agent can accept, reject, or defer an item. The delivery can carry an explicit permission envelope: summarize only, draft but do not send, open a coding task, ask for approval before file edits.

That is easier to audit than an open inbound endpoint waiting for third-party traffic.

FAQ

Does pull delivery add latency?

It can, depending on heartbeat cadence. In practice, the tradeoff is usually worth it for local agents because it avoids public inbound networking and lets the system deliver only matched work.

Can local agents still use webhooks?

Yes, especially through tunnels or private networks. But webhooks should be an advanced deployment option, not the default expectation for every user laptop.

What should be in a pending delivery?

Include the watch, source event reference, matching evidence, delivery target, permission envelope, expiry, retry metadata, and an idempotency key.

Local agents need pull delivery