Skip to main content

Event-based (asynchronous) execution

Some applications take long enough — multi-step Tools, deep research, large document processing — that holding a synchronous HTTP connection open until they finish is impractical. Event-based execution lets you fire the application and get the result asynchronously once it's done, instead of blocking on the response.

When to use it​

  • The workflow is high-latency (seconds to minutes) and you don't want the caller to wait on an open connection.
  • You're triggering runs from an external system or event (a webhook, a queue, an upstream job) rather than a live user.
  • You need to fan out many runs without managing long-lived connections for each.

How it works​

  1. Submit the run asynchronously. The platform accepts the request immediately and returns a reference (run / conversation id) instead of the final output.
  2. The application executes in the background on the asynchronous execution path.
  3. When the run completes, the result is delivered back via your configured callback (and is also retrievable by polling the run reference).

Because it shares the same engine as synchronous runs, the asynchronous result carries the same outputs, guardrail behaviour, credits, and trace as if it had been run synchronously.

  • Bulk Run — for processing a known batch of inputs in one job.
  • Scheduled runs — for time-based, recurring triggers.