Routing

Control execution flow with conditional routing. Route to different paths based on data, loop for agentic workflows, or terminate early.

  • @ifelse - Simple boolean routing: True goes one way, False goes another

  • @route - Route execution to one of several target nodes based on a function's return value

  • END - Sentinel indicating execution should terminate along this path

  • multi_target - Route to multiple nodes in parallel when needed

  • Real patterns - RAG with diagram detection, multi-turn conversations, quality gates

When to Use Routing

Routing solves problems that pure DAGs cannot:

Pattern
Example
Why DAGs Fail

Conditional paths

Route based on document type

DAGs execute all branches

Early termination

Stop if cache hit

DAGs run to completion

Agentic loops

Retry until quality threshold

DAGs have no cycles

Multi-turn conversation

Continue until user satisfied

DAGs are single-pass

Binary Branching with @ifelse

For simple true/false decisions, use @ifelse. It's cleaner than @route when you only have two paths.

Basic If/Else

The function returns True or False. Based on the result:

  • True → routes to when_true target

  • False → routes to when_false target

Early Termination with END

When when_false=END, returning False terminates execution along this path.

When to Use @ifelse vs @route

Use @ifelse when...
Use @route when...

Two mutually exclusive paths

Three or more paths

Decision is boolean

Decision returns a name

No fallback needed

Need fallback for None

Simple branching

Multi-target routing

Flexible Routing with @route

Route to One of Several Targets

The routing function examines data and returns the target node name. Only that node executes.

Terminate Early with END

When a route returns END, execution terminates along that path. Other independent paths continue.

Real-World Example: RAG with Diagram Detection

Documents containing diagrams need special handling - convert pages with diagrams to images and send them alongside text to a multimodal LLM.

The routing logic is clean and explicit:

  1. Retrieve documents

  2. Analyze for diagrams

  3. Route to appropriate LLM based on content type

  4. Generate response with the right model

Agentic Loops

Routing enables cycles - essential for agentic workflows where the system iterates until a condition is met.

Multi-Turn RAG with Refinement

The graph loops: retrieve → generate → update → should_continue → retrieve, until should_continue returns END.

Quality Gate with Retry

Multi-Target Routing

Sometimes you need to run multiple paths in parallel. Use multi_target=True.

With multi_target=True, the function returns a list of targets to execute. All returned targets run (potentially in parallel with AsyncRunner).

Important: When using multi_target=True, target nodes must have unique output names. If multiple nodes produce the same output name, you'll get a GraphConfigError at build time.

Fallback Targets

When a routing function might return None, use fallback to specify a default:

Validation and Error Handling

Build-Time Validation

Hypergraph validates routing at graph construction:

Invalid Return Values at Runtime

If a routing function returns a value not in its targets:

Type Safety

Routing functions must be synchronous and non-generator:

Patterns and Best Practices

Keep Routing Functions Simple

Routing functions should be fast and deterministic. Move complex logic to regular nodes:

Use Descriptive Targets

You can provide descriptions for visualization and documentation:

Chained Gates

Gates can route to other gates for multi-stage decisions:

Next Steps

Last updated