> ## 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-Übersicht

> Verwandle einen Anruf in einen Graphen aus Agenten, Tools und Entscheidungen

Der Flow Builder ist ein visuelles Canvas, auf dem du einen Anruf als **Graphen** gestaltest: Knoten erledigen die Arbeit, Kanten legen fest, wohin sich die Konversation als Nächstes bewegen kann. Unter der Haube ist jeder `agent`-Knoten ein vollständiger Gesprächsagent, und die Bewegung entlang einer Kante ist eine **Übergabe** zwischen Agenten.

## Das mentale Modell

* **Knoten** sind Schritte: begrüßen, unterhalten, entscheiden, eine API aufrufen, Daten sammeln, weiterleiten, beenden.
* **Kanten** sind mögliche Pfade. Ein Agent-Knoten mit drei ausgehenden Kanten kann die Konversation an drei verschiedene nächste Schritte übergeben.
* **Das LLM wählt den Pfad** – basierend auf dem Gespräch und, entscheidend, auf deinen **Edge-Labels**.

## Warum Edge- und Agent-Labels wichtig sind

Das ist das wichtigste Konzept im Flow Builder:

<Warning>
  **Edge-Labels sind keine Dekoration.** Jede ausgehende Kante eines `agent`-Knotens wird zu einem *Handoff-Tool*, das das LLM aufrufen kann – und das Edge-Label wird zur Beschreibung dieses Tools. Das LLM entscheidet anhand deiner Labels, wohin es die Konversation weiterleitet. Vage Labels führen zu vagem Routing.
</Warning>

Zum Vergleich:

| Schwaches Label | Starkes 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` |

Das Gleiche gilt für `condition`-Knoten: Die **Beschreibung** des Knotens sagt dem LLM, worüber entschieden wird, und jedes Edge-Label beschreibt ein mögliches Ergebnis. Das LLM muss sich für genau eine Kante entscheiden – die Labels müssen sich also gegenseitig ausschließen und alle Fälle abdecken, die du erwartest.

Auch die **Namen** von Agent-Knoten spielen eine Rolle: Sie tauchen in Handoff-Tools und Logs auf – `Qualification agent` schlägt also `Agent 2`.

## Ein kleiner, aber nützlicher 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...]
```

## Variablen

`collect`- und `dtmf`-Knoten speichern Ergebnisse in **Flow-Variablen** (z. B. `customer_phone`). Die Variablen sind Teil des `call.completed`-Webhooks und der Anrufdetails, sodass nachgelagerte Systeme strukturierte Daten bekommen – nicht nur ein Transkript.

## Fallback-Verhalten

* Ein `agent`-Knoten mit **leeren Anweisungen** nutzt den System-Prompt des Assistenten (Advanced Prompt) als Basis – gibt es zusätzlichen Knotentext, wird dieser **angehängt**. Der Flow führt einen Agenten nie ohne Anweisungen aus.
* Ein `collect`-Knoten, der nach Ausschöpfung seines Retry-Budgets scheitert, nimmt die ausgehende Kante mit dem Label `failed`, falls vorhanden – andernfalls die normale Kante.
* Fehlerhafte Flow-Konfigurationen bringen einen Anruf nie zum Absturz: Die Engine fällt auf einen sicheren Stack zurück und protokolliert ein `flow_node_error`-Event.

Weiter geht's mit der [Knotenreferenz](/flow-builder/nodes) und den [Best Practices](/flow-builder/best-practices).