flow.to_mermaid() reads the step list and returns a mermaid graph TD string — no execution, no cost.
Quick Start
1
Print a diagram
2
Preview a branching flow
How It Works
The renderer walks the step list — no run, no LLM calls. A step’s label resolves in order:step.name → step.__name__ → step.agent.name → the string itself → the class name. Special characters are handled for you — a " becomes ' and newlines become spaces, so a name can never break the graph.
How Each Step Type Renders
Each step type maps to a mermaid shape.
A control nested inside a branch (an
If inside another If) enters at its own decision, not at its parent’s exit, so it is never bypassed.
Full example combining Parallel, If, and Repeat:
Common Patterns
Sanity-check a flow before running it:mermaid block and GitHub renders it inline:
Best Practices
Name your steps
Name your steps
Give each step a
name= so labels read cleanly. The fallback chain is name → __name__ → agent.name → string → class name, so unnamed callables show up as their function or class name.Prefer to_mermaid() over the telemetry trace for unrun flows
Prefer to_mermaid() over the telemetry trace for unrun flows
Telemetry diagrams need a captured execution — they only exist after a flow has run.
to_mermaid() works on the definition alone, so use it to check a flow you haven’t run yet.Nested controls stay connected
Nested controls stay connected
An
If inside an If, or a Parallel inside a route branch, works. The renderer wires each control through its own decision or fork, so nothing is bypassed.Expand includes with a workflow, not a recipe
Expand includes with a workflow, not a recipe
Include(workflow=...) inlines the included steps because they are known at definition time. Include(recipe="...") stays a single node — the recipe resolves only at runtime. Use workflow= if you want it expanded in the picture.Related
Workflows
Build sequential, parallel, routed, and looped pipelines with AgentFlow.
Workflow Patterns
Reusable shapes for common orchestration scenarios.

