Technical reference for Pipecat’s conversation flow system
New to building conversational flows? Check out our Pipecat Flows guide first.
Type alias for function handler arguments.
Base type for function handler results. Additional fields can be included as needed.
Configuration for the entire conversation flow.
Configuration for a single node in the flow.
Legacy function handler that only receives arguments.
Returns either:
FlowResult
(⚠️ deprecated)FlowResult
NodeConfig
(for dynamic flows) or string (for static flows)Modern function handler that receives both arguments and FlowManager
.
Returns either:
FlowResult
(⚠️ deprecated)FlowResult
NodeConfig
(for dynamic flows) or string (for static flows)Function that is meant to be passed directly into a NodeConfig
rather than into the handler
field of a function configuration.
It must be an async
function with flow_manager: FlowManager
as its first parameter.
It must return a ConsolidatedFunctionResult
, which is a tuple (result, next node) where:
FlowResult
NodeConfig
(for dynamic flows) or string (for static flows)Strategy for managing conversation context during node transitions.
Configuration for context management strategy.
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:
Main class for managing conversation flows, supporting both static (configuration-driven) and dynamic (runtime-determined) flows.
Initialize the flow with starting messages.
Set up a new conversation node programmatically (dynamic flows only).
set_node
to set up each next node.set_node
is triggered under the hood when a node contains a transition_to
field.Deprecated: use the following patterns instead of set_node
:
FlowManager.initialize()
set_node_from_config()
(note: its name will be read from its NodeConfig
)Set up a new conversation node programmatically (dynamic flows only).
Note that this method should only be used in rare circumstances. Most often, you should:
FlowManager.initialize()
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:
The FlowManager provides a state dictionary for storing conversation data:
Functions that execute operations within a single conversational state, without switching nodes.
Functions that specify a transition between nodes (optionally processing data first).
Async function that processes data within a node and/or specifies the next node (more details here). Can be specified as:
__function__:
prefix (e.g., "__function__:process_data"
) to reference a function in the main scriptHandler for dynamic flow transitions.
Deprecated: instead of transition_callback
, use a “consolidated” handler
that returns a tuple (result, next node).
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 instanceExample usage:
Note: A function cannot have both transition_to
and transition_callback
.
Function handlers passed as a handler
in a function configuration can be defined with three different signatures:
The framework automatically detects which signature your handler is using and calls it appropriately.
If you’re passing your function directly into your NodeConfig
rather than as a handler
in a function configuration, you’d use a somewhat different signature:
You don’t need to handle these format differences manually - use the standard format and the FlowManager will adapt it for your chosen provider.
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:
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.
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.
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:
Frame
into the Pipecat pipeline (meaning there would no benefit to waiting around for sequencing purposes)Custom actions are composed of at least:
String identifier for the action
Async or sync function that handles the action
Example:
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 specified.
Technical reference for Pipecat’s conversation flow system
New to building conversational flows? Check out our Pipecat Flows guide first.
Type alias for function handler arguments.
Base type for function handler results. Additional fields can be included as needed.
Configuration for the entire conversation flow.
Configuration for a single node in the flow.
Legacy function handler that only receives arguments.
Returns either:
FlowResult
(⚠️ deprecated)FlowResult
NodeConfig
(for dynamic flows) or string (for static flows)Modern function handler that receives both arguments and FlowManager
.
Returns either:
FlowResult
(⚠️ deprecated)FlowResult
NodeConfig
(for dynamic flows) or string (for static flows)Function that is meant to be passed directly into a NodeConfig
rather than into the handler
field of a function configuration.
It must be an async
function with flow_manager: FlowManager
as its first parameter.
It must return a ConsolidatedFunctionResult
, which is a tuple (result, next node) where:
FlowResult
NodeConfig
(for dynamic flows) or string (for static flows)Strategy for managing conversation context during node transitions.
Configuration for context management strategy.
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:
Main class for managing conversation flows, supporting both static (configuration-driven) and dynamic (runtime-determined) flows.
Initialize the flow with starting messages.
Set up a new conversation node programmatically (dynamic flows only).
set_node
to set up each next node.set_node
is triggered under the hood when a node contains a transition_to
field.Deprecated: use the following patterns instead of set_node
:
FlowManager.initialize()
set_node_from_config()
(note: its name will be read from its NodeConfig
)Set up a new conversation node programmatically (dynamic flows only).
Note that this method should only be used in rare circumstances. Most often, you should:
FlowManager.initialize()
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:
The FlowManager provides a state dictionary for storing conversation data:
Functions that execute operations within a single conversational state, without switching nodes.
Functions that specify a transition between nodes (optionally processing data first).
Async function that processes data within a node and/or specifies the next node (more details here). Can be specified as:
__function__:
prefix (e.g., "__function__:process_data"
) to reference a function in the main scriptHandler for dynamic flow transitions.
Deprecated: instead of transition_callback
, use a “consolidated” handler
that returns a tuple (result, next node).
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 instanceExample usage:
Note: A function cannot have both transition_to
and transition_callback
.
Function handlers passed as a handler
in a function configuration can be defined with three different signatures:
The framework automatically detects which signature your handler is using and calls it appropriately.
If you’re passing your function directly into your NodeConfig
rather than as a handler
in a function configuration, you’d use a somewhat different signature:
You don’t need to handle these format differences manually - use the standard format and the FlowManager will adapt it for your chosen provider.
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:
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.
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.
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:
Frame
into the Pipecat pipeline (meaning there would no benefit to waiting around for sequencing purposes)Custom actions are composed of at least:
String identifier for the action
Async or sync function that handles the action
Example:
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 specified.