The trigger decision is an architecture decision

Before an AI workflow retrieves evidence or drafts an action, something has to tell it a case exists. That something is either a webhook, where the source system pushes an event to an endpoint the workflow owns, or a poll, where the workflow periodically asks the source whether anything changed.

The choice looks small, but it sets the reliability and latency ceiling for everything downstream. A workflow built on a webhook that silently stops arriving has no case to review, no queue to inspect, and no obvious symptom until someone notices the output stopped. A workflow built on polling has a visible schedule, but it inherits the cost and lag of asking a question that usually has the same answer: nothing changed.

Webhooks: fast, but the workflow inherits the sender's reliability

A webhook delivers an event within moments of it occurring, which suits workflows where minutes matter, such as routing a support escalation or reacting to a payment failure. Stripe's webhook documentation is a useful reference here even outside payments, because it is explicit about the operational reality vendors build around push delivery: it retries failed deliveries for up to three days with backoff, does not guarantee ordering, and can redeliver the same event more than once.

That means a workflow consuming webhooks has to do real work to stay correct: verify the sender's signature, return a fast acknowledgement before doing anything slow, store the event id to reject duplicates, and accept that events can arrive out of sequence. None of that is optional if the workflow writes anything back to another system.

  • Verify the signature before trusting the payload.
  • Acknowledge quickly, then process asynchronously.
  • Deduplicate on event id, not on timestamp.
  • Design for out-of-order delivery.

Polling: slower, but the schedule is yours to control

Polling trades latency for control. The workflow decides how often to check, so a missed check is not silent data loss but a known lag, and a source outage shows up as a failed request rather than an event that never arrived. AWS describes EventBridge's event buses as built for routing many sources to many targets with retention and replay; a scheduled poll can borrow the same underlying discipline, tracking a cursor or last-seen id so a gap in one run is caught by the next.

The cost is efficiency. Most polls return no new data, and the interval becomes a tradeoff between responsiveness and load on the source system. A workflow that needs sub-minute reaction time will find polling expensive to run tight enough to compete with a push.

Choose based on what the workflow can tolerate losing

The practical question is not which pattern is more modern, but which failure the workflow can afford. If a missed push has no visible symptom and the case simply never appears, and the source has no reconciliation endpoint, polling or a hybrid design is the safer default even at the cost of some latency.

If the source system can be trusted to retry deliveries and expose an event log for occasional reconciliation, a webhook gives faster, cheaper triggering. Many production integrations end up hybrid: a webhook for fast reaction, backed by a slower daily or hourly poll that reconciles anything the push channel missed. That combination is usually less work than making either pattern perfect on its own.