Nodes
A multi agent is a flow built from nodes. The Agent node is the primary one - it's where the conversation happens, and it has its own pages. This page covers the others you'll wire it to, and the one rule that decides how they can be wired at all.
The palette, grouped by what a node does
Adding a node opens a picker with five groups:
| Group | For | Includes |
|---|---|---|
| Prompt | Asking for one value | Question, Name, Email, Phone, Date, Multi Select, Location, Widget |
| Message | Saying something | Text, Carousel, Images, Videos, File, Quick Replies, WhatsApp List |
| Action | Doing something | Agent, Execute Workflow, Transfer to Agent, End Call - and the wider workflow set |
| Logic | Branching | Condition, Channel Filter |
| Integration | Third-party services | Empty today |
Condition sits under Logic, not next to the Agent node. That trips people up - it's the most useful non-Agent node in a flow and it's the one people don't find.
Which nodes can branch
This is the rule to internalise, because it decides the shape of every flow you draw:
| Node | Outgoing handles |
|---|---|
| Agent | One per exit - your named branches (up to five), tool exits, response, and on_error |
| Condition | One per condition you write, plus a default |
| Channel Filter | One per active channel you split on |
| Execute Workflow | Exactly one |
| API, validators, Prompt Executor, and most Action nodes | Two - a success path and a failure / fallback path |
| Text, and every Message node | Exactly one |
| Question, Name, Email, and every Prompt node | Exactly one |
| Transfer to Agent | None - terminal |
| End Call | None - terminal |
A few of these have more than one handle, but only Agent and Condition branch on the content of the conversation or memory - an Agent on what the user said, a Condition on a value you compare. The rest don't: Channel Filter splits on the channel, and an Action node like API or a validator gives you a fixed success / failure pair, not a branch on what actually came back. So when a step has to route on what a result was, that step is an Agent or a Condition. The most common design error in a multi agent is expecting a different node to do it - drawing an Execute Workflow node with a "found" and a "not found" arrow coming out of it. It has one handle; those arrows can't exist.
The fix is almost always the same pair: do the work, then branch on the result.
Condition
Branch on a value that's already in memory. No model call, no reasoning, no cost, and the same input always takes the same route.
Reach for it whenever the decision is mechanical. An Agent node whose entire job is to check whether policy_count is greater than one is spending a full language-model turn comparing two values - and can get it wrong.
Handles. You write a list of conditions; each one becomes a handle on the node, and there's a default handle for "none of them matched". The default is the else branch, and leaving it unwired is a dead end - wire it even when you think it can't happen.
Operators. Comparing a variable gives you the full set:
| Kind | Operators |
|---|---|
| Equality | equals, not equals |
| Ordering | greater than, greater than or equal to, less than, less than or equal to |
| Text | starts with, does not start with, ends with, does not end with, contains, does not contain |
| Lists | in list, not in list, contains all of, contains any of, contains none of |
| Presence | is empty, is not empty, is true, is false |
That last row takes no value - you pick the operator and nothing else. They're the ones to use for "did an earlier step actually write this?", which is a check worth making more often than people do.
Execute Workflow
Runs a workflow as a child step: it passes the inputs the workflow declares, captures its output into a variable, and continues.
Use it for any step with no conversation in it - a lookup, a calculation, a record update. It's cheaper than an Agent node and it can't drift, because there's nothing being decided.
It has exactly one outgoing handle. To branch on what a workflow returned, put a Condition node after it:
That's the shape to remember. The workflow answers the question; the Condition node acts on the answer.
Text, and the other message nodes
Text displays a message and moves on. No model call, so the wording is exactly what you typed - which is the point. Use it for anything that must be word-for-word: a regulatory disclosure, a fixed confirmation, a price list.
If you want the same message phrased naturally around the conversation, that's an Agent node instead. The trade is precision against fluency, and for compliance wording you want precision.
The rest of the group - Carousel, Images, Videos, File, Quick Replies, WhatsApp List - sends richer content the same way: one handle, no reasoning.
Prompt nodes
Question, Name, Email, Phone, Date, Location, Multi Select: each asks for one value and saves it, with validation built in for the typed ones.
They're much cheaper than an Agent node, and worth using when you genuinely just need a value. Where an Agent node earns its cost is handling how the answer arrives - a customer who gives two things at once, or argues, or asks why you need it.
One thing to know: a Prompt node has a single outgoing handle. There's no valid/invalid branch on the node itself, so if a wrong answer needs its own path, that's an Agent node (Collect and validate) or a Condition node after the prompt.
Transfer to Agent, and End Call
Both are terminal - no outgoing handles at all. Nothing can follow them on the canvas.
- Transfer to Agent hands the conversation permanently to another agent or flow. This flow is over.
- End Call hangs up a voice call, then ends the flow.
If you find yourself wanting to wire something after either one, the work belongs before it.
The rest of the palette
The Action group also carries the wider workflow set - API, Function, Database, Variable, Delay, validators, and around forty more. They're available, but they're workflow building blocks rather than conversation steps.
A reasonable rule: if you're reaching past the nodes above inside a multi agent, that logic usually belongs in a workflow, called from a single Execute Workflow node. The canvas stays readable, and the logic gets somewhere it can be tested on its own.
Read next: The Agent node · Recipes · Flow canvas