Skip to main content
Workflows run in the background, but sometimes they need input from the user or want to send progress updates to the conversation. Requests and notifications are the bridge between workflows and conversations.

Requests

A request pauses the workflow and asks the conversation for data. The workflow defines what it needs, the conversation handler collects it from the user and sends it back to the workflow.

Define requests in the workflow

Declare the request schemas in the workflow definition:
step.request() pauses the workflow and sends a workflow_request event to the conversation. The first argument is the name of the data being requested, and the second argument is a natural language prompt for that data.

Handle requests in the conversation

When a workflow makes a request, the conversation handler receives it as type: "workflow_request":
The request.type is formatted as "workflowName:requestName". Use request.workflow.provide() to send the data back, passing request.step as the third argument so the workflow knows exactly which pending step to resume. Omitting it works when only one step is pending for that request, but throws an error if multiple are pending. The workflow resumes once the data is provided.

Let the AI handle requests

You can also let execute() handle workflow requests by passing them as context:

Notifications

A notification sends data from the workflow to the conversation without pausing the workflow. Use it for progress updates, status changes, or any information the user should see while the workflow keeps running.

Define notifications in the workflow

The third argument to step.notify() is an optional step name. Use unique step names when sending the same notification type multiple times from one handler.

Handle notifications in the conversation

Notifications arrive as type: "workflow_notify":

Workflow callbacks

When a workflow completes (successfully or with failure), the conversation receives a workflow_callback event:
Last modified on April 27, 2026