Published 24 October 2026
Every AI agent that does anything beyond answer questions eventually needs to talk to other systems — a CRM, an order management platform, a document store, an internal API. How that communication happens is an architecture decision with real consequences for latency, reliability, and how much custom glue code you end up maintaining. The three dominant patterns are webhooks, polling, and event-driven messaging, and they get chosen inconsistently in agent projects, often based on whatever the target system happens to support rather than what the use case actually needs.
This post walks through what each pattern is actually good for, where agents commonly get this wrong, and how to decide between them for a given integration.
Polling: Simple, Predictable, and Often Wasteful
Polling means the agent (or a service behind it) periodically asks a system “has anything changed?” — checking for new records, status updates, or new messages on a fixed interval. It’s the easiest pattern to implement and debug, because the agent is always in control of when it checks, and there’s no dependency on the target system supporting outbound notifications.
The tradeoff is the gap between polling interval and responsiveness. Poll every five minutes and the agent can be up to five minutes behind reality — fine for a report that refreshes hourly, unacceptable for a customer-facing agent that needs to see a payment status change within seconds. Polling more frequently to close that gap increases load on the target system and your own infrastructure, often for a large number of checks that return “nothing changed.” For high-volume integrations, this becomes a real cost and rate-limit problem, not just an inefficiency.
Polling is the right choice when the target system has no webhook support, when near-real-time responsiveness isn’t actually required, or as a reconciliation safety net running alongside a webhook integration to catch anything a missed webhook delivery would otherwise lose.
Webhooks: Low Latency, But the Agent Is No Longer in Control
Webhooks invert the relationship: the source system pushes a notification to the agent’s endpoint the moment something happens, instead of the agent asking repeatedly. This gets near-instant responsiveness with much lower overhead than aggressive polling, which is why it’s the preferred pattern for agents that need to react quickly — a support agent that should start working a ticket within seconds of it being created, for example.
The cost is operational complexity that polling doesn’t have. The agent needs a publicly reachable, authenticated endpoint. It needs to handle webhook delivery failures and retries from the source system’s side, verify payload signatures to confirm the webhook is actually from who it claims to be, and — critically — handle duplicate deliveries idempotently, because most webhook providers guarantee at-least-once delivery, not exactly-once. An agent that processes the same “order created” webhook twice and creates two downstream records has a webhook handler bug, not a webhook problem; idempotency keys on the receiving end are not optional for production reliability.
Webhook payloads are also often thin — many providers send a minimal “something changed on resource X” notification and expect you to call back to their API for the full record, rather than including the complete object in the payload. Building the agent’s integration logic around “the webhook tells me what to fetch” rather than “the webhook tells me everything” avoids a class of bugs where partial or outdated payload data gets used as if it were complete.
Event-Driven Architecture: The Right Choice at Scale
Webhooks are a point-to-point pattern — one source, one destination. Once an agent system needs to react to events from multiple sources, fan out a single event to multiple downstream consumers, or guarantee processing even when a downstream consumer is temporarily down, a message broker (Kafka, SQS, RabbitMQ, or similar) sitting between event producers and the agent becomes the more robust pattern. Events get published to a queue or topic, and the agent consumes from it at its own pace, with built-in durability — if the agent is down for ten minutes, the events are still there when it comes back, which a webhook delivery generally is not.
This pattern adds real infrastructure to run and operate, and it’s overkill for a single-source, single-consumer integration where a webhook would do the job with far less complexity. It earns its cost when there are multiple event sources and consumers, when guaranteed delivery and replay matter (debugging what an agent did last Tuesday requires being able to replay the event stream, not just trust that it worked), or when the agent’s processing speed needs to be decoupled from the rate events arrive at, which is common during traffic spikes.
How Agent Projects Get This Wrong
The most common mistake is building the integration around what the agent framework’s tutorial showed rather than the actual latency and volume requirements of the use case. A second common mistake is treating webhook delivery as reliable by default and skipping the reconciliation polling job that catches missed deliveries — webhook providers do lose deliveries, infrequently but not never, and a system with no fallback mechanism quietly accumulates missed events with no alert until a customer notices something that should have happened didn’t.
A third mistake, more specific to agents than to traditional backend integration, is having the agent itself directly consume raw webhook payloads inline in its reasoning loop rather than through a normalization layer. Different source systems format similar events differently, and feeding that variance directly into an LLM-based agent produces inconsistent behavior that’s hard to debug, versus normalizing events into a consistent internal schema before the agent ever sees them.
Security Is Different for Each Pattern
The security posture for each pattern differs enough that it’s worth planning for explicitly rather than retrofitting. Polling, since the agent initiates every request, keeps credentials and network exposure entirely on the agent’s side, which is simpler to secure but means the agent needs long-lived credentials for every system it polls. Webhooks invert that: the agent exposes a public endpoint, which means it inherits all the usual concerns of any internet-facing service — signature verification on every payload, IP allowlisting where the provider supports it, and rate limiting to absorb a burst of legitimate (or malicious) traffic without falling over. Event-driven architectures push most of that exposure into the broker itself, which is usually easier to secure as a single hardened chokepoint, but makes the broker a single point of failure that needs its own availability plan.
Choosing Between Them
A reasonable default: use polling only when webhooks aren’t available or latency genuinely doesn’t matter, use webhooks for single-source integrations where near-real-time matters, and move to an event-driven architecture once you have more than a couple of integrated systems or need guaranteed, replayable delivery. Most agent integrations in practice end up as a mix — webhooks for the primary real-time triggers, a reconciliation poll as a safety net, and a message broker introduced once the number of integrated systems makes point-to-point webhooks unmanageable.
Getting Started
Getting this architecture decision right early avoids a rebuild later, since the integration pattern tends to get baked into how the rest of the agent system is structured. We design and build these integration layers as part of our broader API integration and AI agent work — if you’re scoping how an agent should connect to your existing systems, you can start a project to talk through the specifics of your stack.
Related