Ein Graph statt eines Prompts: wie das Studio einen Sprachagenten aus Text baut
Ein Sprachagent entsteht meist aus einem einzigen langen Prompt. In der Demo funktioniert das: Das Modell klingt sicher und bleibt beim Ablauf. Beim hundertsten Anruf nicht mehr. Jemand unterbricht mitten im Satz, jemand antwortet „na, vielleicht“, jemand fragt mitten in der Terminbuchung nach dem Versand. Und ein Prompt lässt sich nicht öffnen, um zu sehen, wo genau das Gespräch abgebogen ist: Er hat keine Struktur, nur Text.
HANC Studio geht anders vor. Aus einer Beschreibung in gewöhnlicher Sprache baut es das Gespräch als Graph — und bevor es ihn herausgibt, weist es dessen Korrektheit nach.
Ein Briefing statt eines Prompts
Eingabe ist keine Anweisung an das Modell, sondern ein Briefing in Ihren eigenen Worten: wer anruft, was geschehen soll, was nicht, und wie das Gespräch endet. Hängen Sie ein Dokument, einen Screenshot einer Oberfläche oder einen Link zu Ihrer Website an — das Studio liest sie und zieht die Anforderungen heraus: Rolle, Tonfall, Pflichtfragen, wohin schwierige Fälle gehen, welche Daten zu erheben sind.
Von da an lebt die Beschreibung nicht als Text weiter, sondern als Spezifikation, gegen die der Build später geprüft wird.
Ein Graph statt eines Prompts
Das Gespräch besteht aus Knoten, und jeder tut genau eine Sache:
- start — der Einstieg des Anrufs;
- say — eine Äußerung des Agenten;
- gather_input — eine Frage, deren Antwort in einer Variablen landet;
- condition — eine Verzweigung über den Wert einer Variablen;
- update_state — Setzen oder Ändern einer Variablen im laufenden Gespräch;
- tool — eine Aktion: API-Aufruf, Suche in der Wissensbasis, SMS, E-Mail, Weiterleitung an eine Nummer;
- integration — ein Schritt in ein Fremdsystem: Kalender, CRM, MCP-Server;
- subagent — ein Gesprächsteil, den ein eigener Helfer mit eigener Aufgabe übernimmt;
- end_call — der Abschluss.
Das lässt sich lesen. Das lässt sich Kolleginnen und Kollegen zeigen. Auf einen einzelnen Knoten kann man zeigen und sagen: Hier redet der Agent zu viel.
Die Route wählt nicht das Modell
Die zentrale Regel: Eine Kante des Graphen entscheidet nie das Modell. Eine Kante nach dem Motto „die KI soll wählen“ besteht den Build gar nicht erst.
Die Absicht klärt ein stiller Sub-Agent — er sagt kein Wort und liefert einen strengen Wert aus einer festen Liste zurück. Die Route wählen danach gewöhnliche Bedingungskanten über diesen Wert, dazu ein unbedingter Ausweichpfad für den Fall, dass nichts passt.
Der Unterschied zeigt sich nicht in der Demo, sondern im Protokoll: Dieselbe Antwort der anrufenden Person nimmt jedes Mal denselben Zweig.
Der Build muss seine Korrektheit beweisen
Bevor der Agent in Ihrem Konto erscheint, durchläuft der Graph Prüfungen. Keine Empfehlungen — blockierende Prüfungen:
- genau ein Einstieg, und der Anruf beginnt dort;
- kein unerreichbarer Knoten;
- keine Sackgasse: Von jedem Knoten führt ein Weg zum Gesprächsende;
- keine endlosen Schleifen — alle stark zusammenhängenden Komponenten werden analysiert, ein versteckter Zyklus fällt daher genauso auf wie ein offensichtlicher;
- jede Verzweigung hat einen Ausweichpfad;
- ein Zweig, den ohnehin eine unbedingte Kante überdeckt, wird als tot verworfen statt als Dekoration behalten;
- jeder Sub-Agent hat einen eigenen Prompt und eine eigene Ergebnisliste statt der Einstellungen des Elternagenten;
- eine Weiterleitung hat eine Nummer, und die Nummer ist gegen E.164 geprüft.
Sind die Anforderungen nicht erfüllbar, sagt das Studio „Build fehlgeschlagen“ und bewahrt den Entwurf zur Reparatur auf. Ein Provisorium wird nie als fertiges Ergebnis ausgegeben — das ist eine eigene Regel, kein Zufall.
Geprüft per echtem Anruf
Danach ruft das Studio den gebauten Agenten selbst an und geht den Ablauf durch wie eine gewöhnliche anrufende Person, entlang einer Checkliste: Jeder Punkt erhält PASS oder FAIL. Dazu kommen Simulationen — ein Durchlauf aller Zweige für die Abdeckung und absichtlich verdorbene Antworten für die Robustheit.
Am Ende bleibt ein Bericht: was verbunden ist, wie es endet, wo Schleifen liegen, welche Helfer beteiligt sind. Veröffentlichen oder reparieren entscheiden Sie — aber Sie entscheiden mit Blick auf Fakten.
Änderungen nach Bedeutung
Ein fertiger Agent wird in Worten geändert, nicht über Bezeichner: „ändere die erste Begrüßung“, „füge den Tesla-Zweig hinzu“, „nimm die Wiederholung am Ende raus“. Den passenden Knoten findet das Studio selbst.
Die Änderung greift als ein atomarer Vorgang — der übrige Graph wird nicht neu gebaut und verliert keine manuellen Anpassungen. Haben Sie Knotentexte direkt in HANC bearbeitet, übernimmt das Studio sie vorher. Jede frühere Version lässt sich auf den aktuellen Workflow zurückspielen, und das Ergebnis ist sofort sichtbar.
Wissen, Aktionen und Daten
Preislisten, FAQ und Dokumente werden als Quelle angebunden: Der Agent antwortet daraus und nennt die Herkunft der Antwort, statt sie zu erfinden.
Aktionen sind Knoten, keine Absichten: im Kalender buchen, im CRM einen Deal anlegen, eine SMS oder E-Mail senden, Ihre API aufrufen, an einen Menschen übergeben. Vor dem Gesprächsende schreibt ein eigener Knoten alles Erhobene — Name, Telefonnummer, Anliegen, Ergebnis — in Ihre Datenbank.
Veröffentlichung
Der Agent wird in Ihrem HANC-Konto angelegt: Rufnummer, Widget auf der Website, WhatsApp. Dort lebt er weiter, und das Studio bleibt der Ort, an dem er gebaut und geändert wird.
Wozu das alles
Einem Prompt kann man nur glauben. Einen Graphen kann man lesen, prüfen und reparieren — und wenn er doch bricht, sieht man, in welchem Knoten.