Workflows
Conditions
Branching nodes split execution into a true and a false path. Two evaluation modes: LLM-based for natural-language decisions, formula-based for typed expressions.
What you'll learn
- The difference between LLM-based and formula-based conditions
- When to use each mode
- How to wire the true and false branches
Two evaluation modes
Pick the mode that matches the kind of decision you need to make.
- 1
LLM-based
Write a question in plain English ("Is this ticket about billing?"). The configured LLM evaluates the prompt against the incoming payload and returns true or false. Best for semantic, fuzzy, or natural-language decisions. - 2
Formula-based
Write a typed expression — for example, trigger.priority == "high". Evaluated deterministically without an LLM call. Best for numeric thresholds, enum checks, and exact string matches.
Wiring the branches
Every Condition node has two output handles: true on the top and false on the bottom. Drag an edge from each to the next node. Either branch can be left disconnected — execution simply terminates on that path.
Combining conditions
Chain condition nodes to express AND/OR logic — a true branch flows into another condition, and the second condition's outputs go where you need them. For complex boolean trees, prefer formula-based mode since it composes more cleanly than nested LLM calls.
Frequently asked questions
- How much does an LLM-based condition cost?
- One LLM call per evaluation, billed at the model's token rate. The execution trace shows the exact token count and dollar cost per condition evaluation.
- What if the LLM returns something other than true or false?
- The runtime coerces ambiguous answers to false and logs a warning in the trace. Tighten your prompt to ask a clear yes/no question to avoid this.
- Can I use a different LLM for the condition than for the agents downstream?
- Yes. The Condition node has its own model picker. A fast cheap model for conditions plus a heavier model for agents is a common pattern.