The workflow system is built around the concept of a directed acyclic graph (DAG) where nodes represent processing steps and edges represent the flow of data between them. The Workflow class in workflow.py serves as the orchestrator, managing the execution flow and passing the task context between nodes.
Workflow Class
The foundation of the workflow system is the abstract Workflow class:
Key capabilities:
- Abstract base class for concrete workflows
- Schema validation during initialization
- Node execution and routing management
- Task context passing between nodes
- Optional Langfuse tracing via
enable_tracing=True (default False)
Execution Methods
A Workflow instance exposes three entry points:
run and run_async both return the final TaskContext. Pass event= for a fresh run, or context= to continue with an existing TaskContext — this is how one workflow composes another without losing accumulated state.
When enable_tracing=True and Langfuse credentials are missing or invalid, the workflow constructor raises LangfuseAuthenticationError.
Nested Workflows
Use nested workflows when one step in a larger workflow deserves its own workflow definition. A parent node can delegate to a child workflow and pass the current TaskContext forward:
When context= is provided, the child workflow reuses the existing TaskContext instead of parsing a fresh event. That means:
- The child workflow can read the same
task_context.event and previous node outputs.
- Outputs saved by child nodes remain available to later parent nodes.
- The workflow engine temporarily swaps in the child’s node registry while the child runs, then restores the parent’s registry afterward.
should_stop is reset when entering the child workflow so a child can run even if a parent step previously stopped another branch.
This pattern is useful for reusable sub-processes like drafting a reply, extracting invoice data, running a review workflow, or grouping a specialized sequence behind a single parent node.
See the Nested Workflow example for a complete parent/child workflow implementation.
Schema Definitions
The schema.py module defines the structure and configuration of workflows using Pydantic models.
WorkflowSchema
Key attributes:
description: Optional description of the workflow’s purpose
event_schema: Pydantic model for validating incoming events
start: The entry point Node class for the workflow
nodes: List of NodeConfig objects defining the workflow structure
Benefits:
- Type Safety: Pydantic models ensure type validation
- Documentation: Built-in schema documentation
- Validation: Automatic validation of workflow structure
- IDE Support: Full autocomplete and type checking
NodeConfig
NodeConfig attributes:
node: The Node class to be instantiated
connections: List of Node classes this node can connect to
is_router: Flag indicating if this node performs routing logic
description: Optional description of the node’s purpose
concurrent_nodes: Optional list of Node classes that can run concurrently
Workflow Validation
The validate.py module provides validation logic for workflow schemas, ensuring they form valid directed acyclic graphs (DAGs) and have proper routing configurations.
Validation Features:
- DAG Validation - Validates that the workflow forms a proper DAG with no cycles
- Reachability Check - Ensures all nodes are reachable from the start node
- Router Validation - Validates that only router nodes have multiple connections
Workflow Example
Here’s a complete example of a workflow implementation:
This example demonstrates a typical workflow pattern: concurrent analysis, routing based on results, and a terminal action node for the selected path.