%201%20(1).jpg)
Niemand ruft bei einem Unternehmen an, um eine Architektur zu erleben. Aber am Telefon ist Architektur hörbar: in der Pause vor der Antwort, in der Auskunft, die stimmt oder eben nicht, und in dem Moment, in dem man ins Wort fällt und die Maschine damit umgehen muss. Zwei Sekunden Stille fühlen sich am Telefon wie eine Ewigkeit an. Der grundlegende Zielkonflikt der Voice AI ist deshalb kein technisches Detail, sondern das Produkt selbst: Je mehr ein System prüft und absichert, desto verlässlicher wird seine Antwort. Und desto länger braucht sie.
Bei sipgate entwickeln wir seit Jahren eine Voice-Agent-Plattform, mit der unsere Kund:innen eigene Agenten anlegen, ohne AI-Wissen mitzubringen. Inzwischen sind tausende davon im Einsatz. In dieser Größenordnung ist Architektur keine Geschmacksfrage mehr. Wir sind dreimal durch dieselbe Frage gegangen: Wie viel Absicherung ist uns eine Antwort wert, und wie viel Wartezeit ist sie den Anrufer:innen wert? Wir haben sie dreimal unterschiedlich beantwortet. Dieser Artikel erzählt die Geschichte dieser drei Antworten.
Der eine große Prompt
Der einfachste denkbare Aufbau besteht aus einem Modell und einem einzigen Systemprompt, der alles enthält: Rolle, Tonfall, erlaubte und verbotene Handlungen, Sonderfälle. Die Anruferin spricht, das Modell antwortet. Das ist schnell, einfach und für einen eng umrissenen Anwendungsfall völlig legitim. Auch ein einzelner Agent kann Werkzeuge gezielt einsetzen und Leitplanken haben.
Die Grenze zeigt sich beim Wachsen. Je mehr Rollen, Regeln und Sonderfälle in einem einzigen Prompt um Aufmerksamkeit konkurrieren, desto eher überspringt das Modell Anweisungen oder vermischt Zuständigkeiten. Im schlimmsten Fall erfindet es eine Auskunft, die plausibel klingt und trotzdem falsch ist. Im Kundenkontakt am Telefon ist das der teuerste Fehler überhaupt, denn es gibt keine Instanz, die die Antwort prüft, bevor sie ausgesprochen wird.
Das Team aus Spezialisten
Unsere Antwort auf den überforderten Generalisten war ein Team aus Spezialisten: kleine Agenten mit je einem eigenen Prompt, einer engen Zuständigkeit und einem begrenzten Werkzeugkasten. Einer für Termine, einer für die Wissenssuche in FAQ und Dokumenten, einer für Rückrufe, einer für die Übergabe an Menschen. Der Gedanke dahinter: Ein Agent, der nur eine Sache können muss, hat weniger Spielraum für Fehler. Das drückt das Risiko erfundener Auskünfte massiv. Nicht auf null, das schafft keine Architektur, aber weit genug, um Agenten guten Gewissens mit echten Anrufer:innen sprechen zu lassen.
Das Lehrbuch sagt an dieser Stelle: Multi-Agent-Systeme bedeuten viele Modellaufrufe, hohe Kosten und hohe Latenz, also spürbare Wartezeit im Gespräch. Unser Produktionssystem sieht anders aus. An vier Stellen managen wir den Trade-off aktiv:
- Nicht jeder Schritt ist ein Modellaufruf. Werkzeuge wie Datenbankabfragen, Kalender-APIs oder die Dokumentensuche laufen als deterministischer Code. Das Modell entscheidet nur, dass etwas getan wird. Die Ausführung selbst kostet keinen Modellaufruf.
- Die Orchestrierung läuft parallel und auf kleinen Modellen. Routing und Themen-Klassifikation, also die Entscheidung, welcher Spezialist übernimmt, starten gleichzeitig und laufen auf bewusst leichtgewichtigen Modellen. Nur der eine ausgewählte Fachagent pro Gesprächsschritt nutzt das volle Modell. Es rennt also kein Staffellauf durch alle Spezialisten.
- Wartezeit wird überbrückt, ohne Zeit zu kosten. Braucht ein Werkzeug länger, generiert ein kleines Modell einen kontextbezogenen Zwischensatz wie „Moment, ich schaue kurz nach“. Das passiert parallel zur Werkzeug-Ausführung, nicht davor.
- Gesprochen wird, bevor die Antwort fertig ist. Die Antwort fließt satzweise in die Sprachsynthese. Sobald ein Satz vollständig ist, wird er gesprochen, während der Rest noch entsteht. Und Anrufer:innen dürfen unterbrechen. Die laufende Antwort wird dann abgebrochen, und das Modell erfährt im nächsten Schritt, dass es unterbrochen wurde.
Diesen Aufbau betreiben wir heute in Produktion, und er trägt. Aber er hat einen ehrlichen Preis, und der besteht aus zwei Posten. Erstens laufen vor der eigentlichen Antwort Schritte, die niemand hört: Routing und Klassifikation arbeiten stumm, bevor der Fachagent überhaupt anfängt. Zweitens wächst das Geflecht, das die Agenten verbindet, mit jeder fachlichen Zuständigkeit. Jede neue Fähigkeit ist echte Entwicklungsarbeit: ein neuer Agent, ein neuer Prompt, eine neue Abstimmung mit dem Routing.
Ein Agent-Harness für die Telefonie
An dieser Architektur bauen wir gerade. Am einfachsten erklärt man sie über eine Parallele: Was Claude Code und Codex fürs Programmieren sind, bauen wir für das Telefongespräch. Einen Agent-Harness. Ein Harness ist die Laufumgebung um ein Sprachmodell herum. Sie gibt ihm Werkzeuge, Wissen und Leitplanken und lässt es in einer Schleife arbeiten, bis die Aufgabe erledigt ist. Bei den Coding-Tools ist die Aufgabe ein Stück Software. Bei uns ist sie ein Gespräch.
Im Zentrum dieses Harness stehen Skills. Ein Skill ist kein Programm und auch kein zweites Modell, sondern geladenes Wissen: ein abgegrenztes Paket aus Instruktionen und Werkzeug-Berechtigungen, das erst dann in den Kontext des Modells kommt, wenn es gebraucht wird. Das Muster dahinter heißt Progressive Disclosure, und das Spannende daran ist, dass das Modell sich seine Fähigkeiten selbst freischaltet. Es startet nur mit einem kompakten Katalog, also Name und Kurzbeschreibung jedes Skills. Erkennt es, dass ein Skill relevant wird, lädt es sich per Werkzeugaufruf dessen vollständige Instruktionen nach, zusammen mit genau den Werkzeugen, die dieser Skill erlaubt.
Die Schleife selbst ist die Latenz-Optimierung. Eine Anfrage wird als Kette von Aufrufen abgearbeitet, die chronologisch aufeinander aufbauen: Modell, Werkzeug, wieder Modell. Jeder Aufruf bringt die Aufgabe direkt voran, ohne vorgelagerte Orchestrierungs-Schichten und mit so wenigen Zwischenschritten und Wartezeiten wie möglich. Anders als bei den Coding-Harnesses, deren Ergebnis in einem Terminal landet, muss unser Harness in Echtzeit sprechen. Das Modell kann reden, während es im selben Zug ein Werkzeug aufruft. Und wenn ein Schritt einmal länger dauert, kümmert sich der Harness darum, dass am Telefon keine unangenehme Stille entsteht: Er spielt zwischendurch Updates ins Gespräch ein, mal als Zwischenergebnis, mal als kurzes Signal, dass die Anfrage gerade bearbeitet wird.
Der Orchestrierungs-Graph verschwindet dadurch nicht. Er schrumpft auf eine kleine, stabile Schleife, die für jede neue Fähigkeit gleich bleibt. Eine neue Fähigkeit ist dann Konfiguration statt Code: ein Prompt plus eine Liste erlaubter Werkzeuge. Kein neuer Agent, kein Eingriff in die Orchestrierung.
Der Aufwand wird dadurch ehrlich proportional: Das System braucht nur noch so viele Modellaufrufe, wie die Bearbeitung der Anfrage tatsächlich erfordert. Es muss nicht mehr bei jedem Gesprächsschritt erst orchestrieren und klassifizieren, bevor überhaupt jemand antwortet. Eine einfache Frage kommt mit wenigen Aufrufen aus, ein komplexes Anliegen darf mehr davon nutzen. Der Aufwand richtet sich nach der Komplexität des Anliegens, nicht nach der Architektur.
Was verschwindet, ist der stumme Modellaufruf
Man könnte diese Geschichte als Ablösung lesen: Das Multi-Agent-System hatte seine Zeit, jetzt kommt der Harness. Aber das trifft es nicht. Das Spezialisten-Prinzip, also ein Problem in kleine, scharf umrissene Zuständigkeiten zu zerlegen, war nie falsch. Es war der Grund, warum wir Agenten überhaupt mit echten Kund:innen sprechen lassen konnten. In der neuen Architektur lebt es weiter. Die Spezialisierung wandert nur vom Architektur-Diagramm in den Kontext des Modells. Was verschwindet, ist nicht das Prinzip und auch nicht der Modellaufruf. Was verschwindet, ist der stumme Modellaufruf. Auch diese Architektur ist kein Endzustand. Ihre Trade-offs heißen jetzt anders: Skill-Auswahlqualität, Kontextwachstum, Beobachtbarkeit. Irgendwann wird jemand diesen Artikel lesen und die vierte Architektur bauen. Genau so soll es sein, denn der Trade-off zwischen Latenz und Qualität verschwindet nie. Man managt ihn nur an einer immer klügeren Stelle. Mal mit Architektur, mal mit Code, mal mit einem gut gesetzten „Moment, ich schaue das eben nach“.
Wie setzt ihr den Trade-off? Lieber die schnelle Antwort oder die abgesicherte? Und an welcher Stelle managt ihr ihn? Schreibt uns, wir sind gespannt.
.jpg)
