Event-Driven AI Agents: Webhooks, Queues and Safe Actions

Event-driven agents are a good fit for work that may take longer than a browser request should remain open. They are also where timing becomes part of the product. A webhook can arrive twice. A provider can acknowledge a request after your client has timed out. An agent can retry a write that already succeeded.

Receive the event, then get it out of the doorway

Verify the signature, timestamp, sender, and event shape before doing business work. Write the event to a durable queue and acknowledge it quickly. Do not run a long model call inside the webhook request and hope the sender will wait patiently. A slow request is often treated as a failed request and delivered again.

Make the second delivery harmless

Use the provider event ID and intended action to create an idempotency key. Store it with the workflow result, or use an outbox pattern when your database and the external provider need to stay coordinated. When the same event arrives again, return the existing outcome instead of creating a second ticket, message, or payment.

Give failures a sensible home

Retry a temporary network failure with backoff. Do not retry an invalid record or an authorization failure forever. Set a maximum attempt count and send exhausted jobs somewhere a person can inspect. When order matters, partition work by entity and reject an old version instead of applying it after a newer one.

Let people see the waiting

Show received, queued, working, waiting for approval, completed, and failed states with a correlation ID. Operators need pause and replay controls. Users need an honest explanation when their request is waiting or needs correction. The queue is not just plumbing; it is where the workflow remembers what happened and where a human can take over without guessing.