Add Branch nodes for if/else routing, use LLM-driven classification for nuanced decisions, merge paths back together, and keep complex canvases readable.
The Branch node
The Branch node evaluates one or more conditions and routes execution to the matching outgoing edge. Each condition is a boolean expression — for example, `{{steps.classify.output.category}} === 'billing'` — and you can combine multiple conditions with AND/OR logic. Conditions are evaluated in the order they are listed; the first matching condition wins. If no condition matches, execution follows the Default edge (if configured) or the run fails with a no-matching-branch error. Label each outgoing edge descriptively (e.g., 'Is billing', 'Is technical', 'Fallback') — these labels appear in the run logs and make the execution trace much easier to read.
LLM-driven routing
For routing decisions that require natural-language understanding, use an LLM node to produce a classification or decision before feeding it into a Branch node. Configure the LLM node with a structured output schema that returns a single `route` field with a set of allowed string values. The Branch node downstream then checks `{{steps.llm.output.route}}` against each value. This pattern lets you handle routing scenarios that are too nuanced for simple keyword matching — for example, distinguishing between a frustrated customer asking about a refund versus a neutral customer asking about a billing cycle.
Merging branches back together
After a branching section of your workflow, you often want the paths to converge back into a common step — such as a final notification or a database write. Use a Merge node to collect the outputs from multiple incoming edges and continue as a single flow. The Merge node exposes the outputs of each incoming branch under a named key that matches the edge label. In the downstream step, use `{{steps.merge.output.billing.result}}` or `{{steps.merge.output.technical.result}}` depending on which branch actually ran. Note that fields from branches that did not execute will be undefined; handle this with null-coalescing expressions.
Nested conditions and switch-style logic
For complex routing logic with many cases, a chain of Branch nodes can become hard to read. Consider using a single LLM or data-lookup step that produces an enum value, then use a Switch-style Branch with many outgoing edges — one per case — rather than a binary tree of nested branches. Keep the canvas readable by grouping related nodes into Subworkflow frames (right-click on the canvas and select Group into Frame) and labeling each frame. Well-organized canvas layouts dramatically reduce the time it takes to understand an agent's logic when you return to it weeks after building it.