Event-Driven AI Agents: Webhook Architecture for UK Firms

<p class="lead">Most AI agents run on a schedule — polling for changes every few minutes, checking whether a new lead has appeared, whether an invoice is overdue, whether a client has responded. Polling works. It also means your agent is almost always wrong about timing: firing when nothing has happened, and missing time-sensitive events by minutes or hours. Event-driven AI agents solve this. Instead of your agent asking "is anything different?" on a loop, the source system tells your agent the moment something changes. The architecture is not complicated. But most UK service businesses are not using it — and the gap shows in response times, missed follow-ups, and agents processing yesterday's data.</p> <figure> <img src="https://images.unsplash.com/photo-1461749280684-dccba630e2f6?w=1200&q=80" alt="Event-driven AI agent webhook architecture — connecting CRM, payment, and calendar tools to AI agents via real-time webhooks for UK service businesses" width="1200" height="630" loading="lazy" /> </figure> <h2>Why Scheduled Polling Is Costing You Deals</h2> <figure> <img src="https://images.unsplash.com/photo-1526628953301-3e589a6a8b74?w=1200&q=80" alt="Polling vs webhook comparison for AI agents — scheduled polling fires every few minutes regardless of activity while webhook-driven agents respond within seconds of a real event" width="1200" height="800" loading="lazy" /> </figure> <p>Polling is the default because it is easy to reason about. You set a schedule — every five minutes, every hour, every morning at 8am — and your agent runs that schedule regardless of what has actually happened. For workflows where timing does not matter — a weekly digest, a monthly report, a nightly data sync — polling is fine. The problem starts when you use polling for time-sensitive work.</p> <p>Consider a lead qualification agent that runs every 15 minutes. A prospect submits your contact form at 14:02. Your agent runs at 14:15. By that point, the prospect has already checked two competitor websites. Research consistently shows that responding within the first five minutes increases conversion rates by up to 900% compared to a 30-minute response. A 15-minute polling interval eliminates that window entirely.</p> <p>The same problem applies to every trigger that is inherently event-based: a new contract signature, a payment received, a support ticket escalated to urgent, a client project milestone marked complete. Each of these has a natural response window. Polling almost always misses it.</p> <blockquote><p>Polling is not wrong — it is misused. An agent that checks for new invoices every morning is using polling correctly. An agent that checks whether a prospect just enquired is using polling to do a job that webhooks do 200 times better.</p></blockquote> <p>There is also a cost dimension. Every scheduled polling run consumes tokens, compute, and API calls regardless of whether there is work to do. For an agent checking a CRM every five minutes across an eight-hour day, that is 96 runs per day — most of them finding nothing. Event-driven agents run exactly when triggered. The same volume of real work costs a fraction of the token spend, which connects directly to the <a href="/blog/ai-agent-cost-optimisation-uk">cost optimisation framework</a> covered in this series.</p> <h2>The Webhook-First Architecture for AI Agents</h2> <figure> <img src="https://images.unsplash.com/photo-1544197150-b99a580bb7a8?w=1200&q=80" alt="Webhook-first AI agent architecture — four components: webhook receiver, event router, idempotency store, and dead letter queue for reliable event-driven automation" width="1200" height="800" loading="lazy" /> </figure> <p>The core pattern has four components. Understanding each one before building prevents the most common production failures.</p> <h3>The Webhook Receiver</h3> <p>A webhook receiver is an HTTP endpoint your agent stack exposes, waiting for inbound POST requests from source systems. When a contact form is submitted, your CRM sends a POST to your n8n webhook URL. Your receiver accepts the payload, validates it, returns a 202 Accepted status immediately, and queues the work for processing.</p> <p>The most important principle: acknowledge fast, process asynchronously. Your receiver should never block on heavy processing. If it does, source systems that enforce short timeout windows will retry, sending duplicate events. Return 2xx immediately, then do the work in the agent workflow downstream.</p> <h3>The Event Router</h3> <p>Not every webhook event should trigger the same agent. An event router classifies incoming payloads and routes them to the right workflow. A Stripe webhook, for example, might deliver events for payment succeeded, payment failed, subscription cancelled, and invoice created — each requiring a different agent response. The router reads the event type from the payload and branches accordingly.</p> <p>In n8n, this is a Switch node placed immediately after the Webhook trigger. In a more complex stack, it is a separate routing layer with its own event schema. The principle is the same: one webhook URL per integration, one router that fans out to many agent workflows. This also makes the <a href="/blog/ai-agent-observability">observability layer</a> significantly cleaner — you can log and monitor at the router, seeing exactly which event types are arriving, at what volume, with what failure rate.</p> <h3>The Idempotency Store</h3> <p>Webhooks are delivered at-least-once. This is not a bug — it is a deliberate design choice because guaranteeing exactly-once delivery is much harder. The consequence is that your agent may receive the same event twice. Without an idempotency store, it will process it twice: sending two follow-up emails, creating two CRM records, booking two calendar appointments.</p> <p>The fix is an idempotency key — typically the event ID from the source system's payload — written to a Redis cache or database before processing. On arrival, the router checks: have we seen this event ID before? If yes, return 200 and discard. If no, store the ID and proceed. This single addition makes your event-driven agents safe to operate at scale. Without it, they are fragile in proportion to the reliability of the source system.</p> <h3>The Dead Letter Queue</h3> <p>Some events will fail — the agent times out, the CRM is temporarily unavailable, a payload arrives malformed. Without a dead letter queue, failed events are silently lost. With one, failed events are held for inspection and retry. In n8n, this is an Error Workflow connected to your main flow. In a self-hosted stack, it is a separate queue where failed events land with their error context attached for diagnosis. The <a href="/blog/ai-agent-fault-tolerance-patterns">fault tolerance patterns</a> post covers this layer in full — event-driven agents need every one of those patterns applied at the webhook boundary.</p> <h2>Building Your First Event-Driven Agent in n8n</h2> <figure> <img src="https://images.unsplash.com/photo-1515879218367-8466d910aaa4?w=1200&q=80" alt="n8n workflow for event-driven AI agent — Webhook trigger, Switch router, idempotency check, AI Agent node with Claude, and branching output actions for lead qualification" width="1200" height="800" loading="lazy" /> </figure> <p>Here is the practical implementation for a lead qualification agent triggered by a HubSpot form submission — one of the most common first event-driven agents UK service businesses build.</p> <h3>Step 1: Create the Webhook Trigger Node</h3> <p>In n8n, add a Webhook trigger node and copy the generated URL. In HubSpot, navigate to Notifications → Webhooks, create a new webhook subscription for <code>contact.creation</code>, and paste the n8n URL. Set the method to POST and save. Send a test submission — your n8n workflow will catch the payload and display the event structure, showing you exactly which fields are available.</p> <h3>Step 2: Add Idempotency Checking</h3> <p>Add an HTTP Request node calling a Redis GET with the HubSpot event ID from the payload. Connect this to an IF node: if the key exists, route to a stop node and return 200. If not, route forward and immediately SET the idempotency key with a 24-hour TTL. You now have idempotent processing — the same event can arrive ten times and your agent will only act once.</p> <h3>Step 3: Add the AI Agent Node</h3> <p>Add an AI Agent node. Set the model to Claude Sonnet and write the system prompt with the agent's scoring criteria: what a high-value prospect looks like for your business, what signals indicate urgency, and — critically — the JSON output format you want. A score from 0 to 100, a tier (hot, warm, or cold), and a recommended first action. Pass the HubSpot contact fields as the user message using n8n's expression syntax.</p> <p>The output should be <a href="/blog/structured-outputs-ai-agents-production">structured output</a> — a JSON object your downstream nodes can route on without parsing free text. This is the engineering layer that makes subsequent branching reliable. Enforce the schema at the system prompt level and use JSON mode where the model supports it.</p> <h3>Step 4: Branch on the Score</h3> <p>Add a Switch node routing on the tier field. Hot leads (score 80+) trigger an immediate Slack notification to the sales owner plus a personalised HubSpot sequence enrolment. Warm leads create a CRM task for follow-up within 24 hours. Cold leads are tagged, added to a nurture sequence, and no human is looped in. The whole process — from form submission to routed output — completes in under 90 seconds, compared to the 15-minute window a polling agent would leave open.</p> <p>This is the same underlying logic that powers the <a href="/blog/build-ai-lead-qualification-agent">lead qualification agent tutorial</a>, now triggered by an event rather than a schedule. The agent logic is identical; what changes is when it runs — and that timing change is where most of the commercial value lives.</p> <h2>The Reliability Layer: Idempotency, Retries, and Rate Limits</h2> <figure> <img src="https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=1200&q=80" alt="Event-driven AI agent reliability statistics — 96 wasted polling runs per agent per day, sub-90-second response time with webhooks vs 15-minute polling window, 99% event processing accuracy with idempotency and retry patterns" width="1200" height="800" loading="lazy" /> </figure> <p>The architecture above works in development. Getting it to production-reliable requires three additional layers that most builds skip until they fail in production.</p> <h3>Signature Validation</h3> <p>Every serious webhook provider — Stripe, HubSpot, Shopify, GitHub — signs their payloads with an HMAC-SHA256 signature using a secret you set during webhook configuration. Your receiver must validate this signature before processing. In n8n, this is a Code node at the very start of the workflow that computes the expected signature from the raw request body and compares it to the header value. If it does not match, return 401 and stop. Without this, any system that discovers your webhook URL can trigger your agent with arbitrary payloads — a significant attack surface that connects to the <a href="/blog/ai-agent-security-prompt-injection">agent security</a> layer.</p> <h3>Exponential Backoff on Downstream Calls</h3> <p>When your agent makes API calls to downstream systems — updating the CRM, sending a Slack notification, booking a calendar event — those systems may be temporarily unavailable. Hard failures without retry mean lost actions. Exponential backoff means the first retry waits two seconds, the second waits four, the third waits eight. In n8n, this is implemented with a Loop node around the action plus a Wait node whose duration doubles on each iteration up to a maximum. After five retries, route to the dead letter queue for manual review.</p> <h3>Rate Limit Awareness</h3> <p>Event-driven agents can process events faster than downstream APIs allow. If a marketing campaign generates 500 form submissions in an hour and your CRM API allows 100 writes per minute, your agent will hit rate limits by minute two. The fix is a rate limiter at the point of each API call — n8n's Wait node plus a counter variable handles simple cases; a Redis-backed token bucket handles production volumes. Build this into your first webhook integration, not as a retrofit after the first incident.</p> <p>Getting these three layers right means an event-driven agent typically processes 99%+ of events correctly without human intervention. The <a href="/blog/ai-agent-observability">observability post</a> covers what to measure to verify you are achieving that — delivery latency, failure rates, retry exhaustion counts, and payload anomaly rates are the four metrics that tell you whether your event-driven architecture is healthy.</p> <h2>Common Webhook Sources for UK Service Businesses</h2> <p>The architecture applies across every integration. These are the most common webhook sources UK service businesses connect to their AI agents:</p> <ul> <li><strong>HubSpot / Salesforce.</strong> Contact created, deal stage changed, task overdue — trigger lead qualification, follow-up, and pipeline management agents.</li> <li><strong>Stripe / GoCardless.</strong> Payment succeeded, payment failed, subscription cancelled — trigger invoice agents, churn alerts, and automated dunning workflows.</li> <li><strong>Calendly / Acuity.</strong> Booking confirmed, booking cancelled, no-show recorded — trigger onboarding agents, reminder sequences, and CRM updates.</li> <li><strong>Typeform / Tally.</strong> Form submission — trigger intake qualification, proposal generation, and document request workflows.</li> <li><strong>Slack / Microsoft Teams.</strong> Message with a specific keyword, channel message in a monitored space — trigger internal routing, escalation, and briefing agents.</li> <li><strong>Gmail / Outlook.</strong> New email from a specific domain, email with attachment — trigger the <a href="/blog/build-ai-email-triage-agent">email triage agent</a> at near-real-time speed rather than a polling schedule.</li> </ul> <p>Each of these integrations follows the same pattern: one webhook URL, one receiver, one router, agents behind the router. The first integration takes the longest to build correctly — typically two to three days when you are setting up idempotency, signature validation, and the error workflow properly. Every subsequent integration takes two to four hours because the infrastructure is already in place. This is the compounding return of building the architecture correctly the first time rather than patching each integration individually.</p> <blockquote><p>The first webhook integration is the hardest because you are building infrastructure, not just a workflow. Every integration after that is fast because the infrastructure already exists. The pattern scales without the pain repeating.</p></blockquote> <p>If you want to design the event-driven layer for your AI operating system — or you want a second opinion on a webhook architecture you are already running — <a href="/contact">get in touch</a>. We build and run AI operating systems for UK service businesses, and getting the event trigger layer right is where most of the reliability and responsiveness gains come from. We have seen it turn good AI agents into great ones — and fix architectures that were silently losing events every day.</p>