Pipecat Flows
Technical reference for Pipecat’s conversation flow system
New to building conversational flows? Check out our Pipecat Flows guide first.
Installation
Core Types
FlowArgs
Type alias for function handler arguments.
FlowResult
Base type for function handler results. Additional fields can be included as needed.
FlowConfig
Configuration for the entire conversation flow.
NodeConfig
Configuration for a single node in the flow.
Function Handler Types
Legacy function handler that only receives arguments.
Modern function handler that receives both arguments and FlowManager.
ContextStrategy
Strategy for managing conversation context during node transitions.
ContextStrategyConfig
Configuration for context management strategy.
FlowsFunctionSchema
A standardized schema for defining functions in Pipecat Flows with flow-specific properties.
You cannot specify both transition_to
and transition_callback
in the same
function schema.
Example usage:
FlowManager
Main class for managing conversation flows, supporting both static (configuration-driven) and dynamic (runtime-determined) flows.
Methods
Initialize the flow with starting messages.
Set up a new conversation node.
- For dynamic flows, the application must advance the conversation using
set_node
to set up the next node. - For static flows,
set_node
is triggered by a function call that contains atransition_to
field.
Register a handler for a custom action type.
Get the current conversation context.
Returns a list of messages in the current context, including system messages, user messages, and assistant responses.
Example usage:
State Management
The FlowManager provides a state dictionary for storing conversation data:
Usage Examples
Functions that execute operations within a state.
Functions that create transitions between nodes. Use transition_to
(static flow) or transition_callback
(dynamic flow) to specify the target node.
Function Properties
Async function that processes data within a node. Can be specified as:
- Direct function reference
- Either a Callable function or a string with
__function__:
prefix (e.g.,"__function__:process_data"
) to reference a function in the main script
Handler for dynamic flow transitions. Must be an async function with one of these signatures:
The callback receives:
args
: Arguments from the function callresult
: Typed result from the function handler (new style only)flow_manager
: Reference to the FlowManager instance
Example usage:
Note: A function cannot have both transition_to
and transition_callback
.
Handler Signatures
Function handlers can be defined with three different signatures:
The framework automatically detects which signature your handler is using and calls it appropriately.
Return Types
Provider-Specific Formats
You don’t need to handle these format differences manually - use the standard format and the FlowManager will adapt it for your chosen provider.
Actions
pre_actions
and post_actions
are used to manage conversation flow. They are included in the NodeConfig
and executed before and after the LLM completion, respectively.
Three kinds of actions are available:
- Pre-canned actions: These actions perform common tasks and require little configuration.
- Function actions: These actions run developer-defined functions at the appropriate time.
- Custom actions: These are fully developer-defined actions, providing flexibility at the expense of complexity.
Pre-canned Actions
Common actions shipped with Flows for managing conversation flow. To use them, just add them to your NodeConfig
.
Speaks text immediately using the TTS service.
Ends the conversation and closes the connection.
Function Actions
Actions that run developer-defined functions at the appropriate time. For example, if used in post_actions
, they’ll run after the bot has finished talking and after any previous post_actions
have finished.
Calls the developer-defined function at the appropriate time.
Custom Actions
Fully developer-defined actions, providing flexibility at the expense of complexity.
Here’s the complexity: because these actions aren’t queued in the Pipecat pipeline, they may execute seemingly early if used in post_actions
; they’ll run immediately after the LLM completion is triggered but won’t wait around for the bot to finish talking.
Why would you want this behavior? You might be writing an action that:
- Itself just queues another
Frame
into the Pipecat pipeline (meaning there would no benefit to waiting around for sequencing purposes) - Does work that can be done a bit sooner, like logging that the LLM was updated
Custom actions are composed of at least:
String identifier for the action
Async or sync function that handles the action
Example:
Exceptions
Base exception for all flow-related errors.
Raised when flow initialization fails.
Raised when a state transition fails.
Raised when an invalid or unavailable function is called.