> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ouraicalling.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Flow builder overview

> Turn a call into a graph of agents, tools, and decisions

The flow builder is a visual canvas where you design a call as a **graph**: nodes do the work, edges define where the conversation can go next. Under the hood, each `agent` node is a full conversational agent, and moving along an edge is a **handoff** between agents.

## The mental model

* **Nodes** are steps: greet, converse, decide, call an API, collect data, transfer, end.
* **Edges** are possible paths. An agent node with three outgoing edges can hand the conversation to three different next steps.
* **The LLM chooses the path** — based on the conversation and, crucially, on your **edge labels**.

## Why edge and agent labels matter

This is the most important concept in the flow builder:

<Warning>
  **Edge labels are not decoration.** Every outgoing edge of an `agent` node becomes a *handoff tool* that the LLM can call — and the edge label becomes that tool's description. The LLM decides where to route the conversation by reading your labels. Vague labels produce vague routing.
</Warning>

Compare:

| Weak label | Strong label                                      |
| ---------- | ------------------------------------------------- |
| `next`     | `caller wants to book an appointment`             |
| `option 2` | `caller asks about pricing or invoices`           |
| `transfer` | `caller explicitly asks for a human, or is angry` |

The same applies to `condition` nodes: the node's **description** tells the LLM what is being decided, and each edge label describes one outcome. The LLM is forced to pick exactly one edge — so the labels must be mutually exclusive and cover all cases you expect.

Agent node **names** matter too: they appear in handoff tooling and logs, so `Qualification agent` beats `Agent 2`.

## A minimal useful flow

```text theme={null}
[start: greeting]
      │
[agent: Reception]
  ├─ "caller wants an appointment" ──► [collect: name] ─► [collect: phone] ─► [end: confirm & goodbye]
  ├─ "caller has a billing question" ─► [agent: Billing FAQ] ─► [end]
  └─ "caller asks for a human" ───────► [warm_transfer: +49...]
```

## Variables

`collect` and `dtmf` nodes store results in **flow variables** (e.g. `customer_phone`). Variables are included in the `call.completed` webhook and the call details, so downstream systems get structured data — not just a transcript.

## Fallback behavior

* An `agent` node with **empty instructions** uses the assistant's system prompt (Advanced prompt) as the base — with node text, that text is **appended**. The flow never runs an agent without instructions.
* A `collect` node that fails after its retry budget takes the outgoing edge labeled `failed` if one exists, otherwise the normal edge.
* Broken flow configurations never crash a call: the engine falls back to a safe stack and logs a `flow_node_error` event.

Continue with the [node reference](/flow-builder/nodes) and [best practices](/flow-builder/best-practices).