AI agents that react to real-time events

A deal stage changes in Salesforce. A ticket gets reassigned in Zendesk. A payment fails in Stripe. Nobody typed a prompt for any of that, but an agent that's supposed to react to it still needs a way to find out it happened. Paragon's Workflows is that mechanism: a trigger listens for the event, the agent's defined action runs when it fires, and both run on a durable engine executing 10M+ requests per day, with managed webhook triggers so supported apps don't need a hand-built receiver.

Most "AI agent" demos are request-response: a person types something, the agent calls a tool, the agent replies. Reacting to real-time events needs three things a plain chat loop doesn't have: a standing subscription to third-party events, a place for those events to land, and an engine that turns "this happened" into "the agent does that."

How an agent finds out something happened

Paragon's Workflows is that trigger-to-action mechanism, running on a durable engine that executes 10M+ requests per day with built-in auto-retry on failure. A third-party app fires an event, a configured trigger receives it, and the agent's defined action runs as the first step of that workflow run.

Concretely, the flow is event to trigger to action. Something changes in a connected app (a new row, a status change, a message posted). A trigger configured in Workflows is listening for that specific event type. When it fires, Workflows starts a run, and the first step in that run is whatever the agent is supposed to do about it: look up a related record, call a tool, post a summary, kick off a downstream workflow. The agent doesn't poll for changes and doesn't need its own event bus. It's handed the event, already shaped as input to whatever action comes next.

A tool-calling setup like ActionKit answers "what can the agent do right now, on demand." Workflows answers "what should happen when something occurs, with nobody asking." Both questions apply to the same agent. An AI SDR that emails a lead on request also needs to notice when that lead replies. A support agent that looks up an order when asked also needs to notice when the order's shipping status changes. Those are two separate mechanisms wired into one agent: a callable action and a listening trigger.

What can trigger a workflow

A workflow can be triggered from anywhere: a third-party webhook event, an event inside your own application, a cron job, or a direct HTTP request. All four trigger types feed the same durable engine, so an agent's reaction logic doesn't change based on how the event arrived.

• Third-party webhook events: something changes in a connected app (HubSpot deal stage, Jira issue status, Slack message) and the app pushes a webhook.

• App events: an event inside your own product (a user completes onboarding, a plan upgrades) that you want to hand off to an agent action.

• Cron jobs: scheduled runs (nightly reconciliation, weekly digest) that don't depend on an external event at all.

• HTTP requests: a direct call into a workflow, useful when another service (or another agent) needs to kick one off synchronously.

For an agent that's supposed to "react to real-time events," the third-party webhook trigger is usually the one doing the work, since it's the only type that originates outside your own systems entirely.

Managed webhook triggers vs. building your own

Paragon ships managed webhook triggers for supported apps, meaning the receiver, the payload parsing, and the routing into a workflow run are already built. You configure the trigger and connect the account; you don't stand up an endpoint, verify signatures, or write a parser for that app's event schema.

Building this yourself, per app, is not a small amount of work. Each provider has its own webhook registration flow, its own signature scheme for verifying the payload actually came from that provider, its own retry behavior when your endpoint is briefly down, and its own event payload shape that has to be normalized before anything downstream can use it. Multiply that by however many apps your product needs to react to, and "add a webhook" turns into a maintenance surface of its own, one that grows every time a provider changes their payload format.

Managed webhook triggers collapse that into configuration: pick the app, pick the event, connect the account through Paragon's per-user auth flow, and the workflow starts receiving events. That's the same connector catalog Paragon maintains for actions and sync, reused for the trigger side of the same apps.

Custom webhooks for events outside the pre-built set

Not every event type is pre-built as a managed trigger. For a Paragon account on the Pro plan or above, Custom Webhooks let you define a trigger for an event outside the managed set, through a three-step wizard: basic information about the webhook, then either an API request to register it with the provider or a manual registration step, then event routing and payload verification. Once it's set up, a custom webhook functions like any other trigger inside the Workflow Builder, so the agent's downstream logic doesn't need to know whether the trigger was pre-built or custom.

This matters for teams building on top of a niche or internal API that doesn't have a managed trigger yet: the wizard gives you a defined path to wire it in, rather than requiring a one-off integration built outside the platform.

What happens when something fails

Every workflow run, and every action inside it, is logged, and Workflows includes built-in auto-retry when a step fails. That's the confirmed behavior. What's intentionally out of scope here is the exact retry schedule or a formal delivery-guarantee model (at-least-once, exactly-once, dead-letter handling); that level of mechanics is covered in Paragon's webhook infrastructure content, specifically the guaranteed-delivery and retry piece, rather than restated here.

For an agent-reacts-to-events design, the practical takeaway is simpler than the full reliability story: a failed action doesn't silently disappear, and the run log gives you a record of what happened at each step, which is usually what you need to debug why an agent didn't do the thing it was supposed to do.