So funktionieren KI-Sprachagenten: Architektur & Call Flow erklärt

Die meisten Erklärtexte über KI-Sprachagenten beginnen und enden bei "das ist KI, die am Telefon spricht". Was natürlich stimmt. Aber das Spannendste passiert in der Lücke zwischen dem Moment, in dem jemand den Mund öffnet, und dem Moment, in dem er eine Antwort hört. Da passiert ziemlich viel, und alles in unter 2 Sekunden.

Stellen wir uns kurz vor, ein Kunde ruft bei seiner Zahnarztpraxis an, um einen Donnerstagstermin auf die Folgewoche zu verschieben. Auf Kundenseite ist das eine simple 30-Sekunden-Interaktion. Auf Systemseite ist das Bild deutlich komplexer: Der Anruf wird geparst, verstanden, gegen den Kalender geprüft, bestätigt und dem Anrufer zurückgemeldet, bevor er auflegen oder um eine Weiterleitung bitten kann. Dieses Beispiel begleitet uns durch den ganzen Artikel, während wir jedes Teil des Prozesses auseinandernehmen.

Nebenbei: Genau für diese Art von Problem ist die Sprachagenten-Plattform von telli gebaut. Unternehmen nutzen KI-Sprachagenten häufig für Aufgaben wie Lead-Qualifizierung und Terminbuchung, wo Gespräche natürlich ablaufen und sich gleichzeitig in Business-Systeme integrieren müssen. Wir nutzen dieses Beispiel deshalb, um zu zeigen, wie ein reales System wie telli jeden Schritt des Prozesses angeht, statt rein theoretisch zu bleiben.

Die Pipeline eines KI-Sprachagenten

Auf den Kern reduziert durchlaufen alle KI-Sprachagenten mehr oder weniger dieselbe Abfolge von Schritten:

Anrufer spricht → Spracherkennung → Sprachverständnis → LLM-Reasoning → Wissensabruf → Tool Calls → Sprachgenerierung → Anrufer hört eine Antwort

Jeder einzelne Schritt ist für das Funktionieren der Pipeline absolut notwendig, und alle hängen kritisch voneinander ab. Ein fantastisches Sprachmodell hilft wenig, wenn die Transkriptions-Engine schlampig arbeitet und nicht richtig hört, was der Kunde sagt. Beste Audioqualität bringt kaum etwas, wenn die Sprach-Engine langsam ist und den Kunden ein, zwei Sekunden warten lässt. Jedes Glied dieser Kette ist genauso wichtig wie jedes andere.

Hier eine allgemeine Beschreibung, wofür jedes Glied der Pipeline zuständig ist:

Nun verfolgen wir unser Umbuchungs-Beispiel durch die Stufen der Pipeline.

Schritt 1: Sprache wird zu Text

In dem Moment, in dem ein Anrufer sagt "Ich muss meinen Donnerstagstermin verschieben", ist im Hintergrund bereits eine Speech-to-Text-Engine (STT), auch Automatic Speech Recognition (ASR) genannt, aktiv. Anbieter wie Deepgram, Speechmatics, Whisper und die Speech-Modelle von Google setzen das auf unterschiedlichste Weise um, aber alle mit demselben Ziel: ein Transkript des gesprochenen Worts mit Satzzeichen zu erzeugen, so nah an Echtzeit wie möglich.

Jede nachgelagerte Komponente erbt Fehler, die in der Transkription entstehen. Wird aus "meinen Donnerstagstermin verschieben" ein "meinen Donnerstagstermin streichen", ändert das die Aussage des Kunden komplett und kann unnötige Reibung erzeugen.

Akzente, Hintergrundgeräusche, schlechte Telefonverbindungen und schlichtes Nuscheln machen diese Stufe komplex, aber kritisch. Die meisten Echtzeit-Systeme setzen deshalb auf Rauschunterdrückung und mehrsprachige Spracherkennung statt auf einen einzigen Durchlauf.

Die Faktoren, die die Transkriptionsgenauigkeit laut Forschung zur ASR-Performance tatsächlich beeinflussen, sind:

Das ist keine Randnotiz. Eine Studie von 2020, die in der Forschung breit zitiert wird, zeigte einen deutlichen Unterschied in der Fehlerquote von ASR-Modellen zwischen afroamerikanischen und weißen amerikanischen Sprechern, überwiegend aufgrund von Datenlimitierungen und nicht wegen der Technologie. Eine gute Erinnerung daran, dass Transkriptionsqualität je nach Sprecher variiert und dass Genauigkeitswerte, die nur auf wenigen Akzenten basieren, die reale Performance nicht unbedingt widerspiegeln.

Schritt 2: Verstehen, was der Anrufer wirklich meint

Die richtigen Worte zu erfassen ist nicht dasselbe wie die richtige Bedeutung zu erfassen. Hier kommen Natural Language Understanding (NLU) und Intent-Erkennung ins Spiel. "Kannst du mir die Rechnung schicken?" und "Kannst du mir die Rechnung nochmal schicken?" klingen grammatikalisch fast identisch, verlangen aber unterschiedliche Ergebnisse.

In unserem Beispiel sagt der Anrufer: "Ich muss meinen Donnerstagstermin verschieben." Das System muss die Absicht bestimmen (verschieben, nicht absagen), die richtige Entität identifizieren (genau diesen Donnerstagstermin), sich an früher im Gespräch genannte Details erinnern (wer der Anrufer ist, ob er authentifiziert wurde) und die Stimmung erkennen (ob er genervt ist, sich freut usw.).

Schritt 3: Wie das LLM entscheidet, was es sagt

Diesen Schritt verstehen die meisten am gründlichsten falsch. Ein LLM, das einen Sprachagenten steuert, improvisiert nicht einfach Antworten wie in einer Chatbot-Demo. Es arbeitet innerhalb klar definierter Grenzen: ein System-Prompt mit den Geschäftsregeln, der bisherige Gesprächskontext, Informationen aus der Wissensdatenbank des Unternehmens und vorab freigegebene Tool-Aktionen.

Wenn der Anrufer den Donnerstagstermin verschieben will, erfindet das LLM keine plausibel klingende Aussage über das Verschieben. Es geht Fragen durch wie: "Erlauben wir Umbuchungen innerhalb derselben Woche?" "Ist das Kalender-Tool erreichbar?" "Welche zusätzlichen Informationen (zum Beispiel ein neues Datum) braucht es, um zu handeln?"

Erst wenn genug Informationen vorliegen, antwortet es, indem es entweder den Anrufer um weitere Angaben bittet oder die passende Funktion auslöst. Das ist der fundamentale Unterschied zwischen Text generieren und mit Tools echte Aufgaben lösen. Und es ist der Unterschied zwischen etwas sagen, das plausibel klingt, und tatsächlich tun, was getan werden muss.

Je nach zugrundeliegendem LLM (GPT, Claude, Gemini, Llama usw.) steigt das Halluzinationsrisiko deutlich, wenn Modelle frei aus ihren Trainingsdaten antworten dürfen, statt verifizierte, abgerufene Informationen zu nutzen. Gute Systeme vermeiden solche Situationen aktiv.

Schritt 4: Unternehmensspezifische Informationen abrufen

Nur weil ein LLM intelligenten Text erzeugen kann, heißt das nicht, dass es die Preise deiner Praxis "kennt", die Feinheiten deiner Stornoregeln oder deine Öffnungszeiten. LLM-gesteuerte Agenten müssen diese Informationen bei Bedarf abrufen.

Das ist der Job von Retrieval-Augmented Generation (RAG), einem Ansatz aus einem Paper von 2020, der das vorhandene ("parametrische") Wissen eines LLM um externe Informationen ergänzt, die genau dann abgerufen werden, wenn das LLM sie braucht. Statt zu nutzen, was das LLM im Training gelernt hat (was allgemein ist und für unternehmensspezifische Details schlicht fehlen kann), zieht das System relevante Dokumente wie FAQs, interne Unterlagen, CRM-Daten oder Richtlinien aus der Wissensdatenbank des Unternehmens, bereitet die Daten auf und speist sie in die Sprachgenerierung ein.

Der Unterschied liegt darin, wo das Wissen lebt. Ein trainiertes Modell hat es fest eingebacken: Es zu aktualisieren heißt Nachtrainieren oder Fine-Tuning, und seine Antworten zu deinem konkreten Geschäft sind oft generisch oder schlicht falsch. Retrieval zieht dieselben Informationen live aus deinen eigenen Dokumenten und Datenbanken, ist in dem Moment aktuell, in dem du deine Wissensbasis aktualisierst, und verankert jede Antwort in etwas Echtem statt in einer halluzinierten Vermutung.

In unserem Beispiel muss der Agent klären, ob für den Anrufer bei einer Umbuchung innerhalb derselben Woche eine Gebühr anfällt, denn dieses Detail steckt nicht im generischen LLM.

Es muss aus der eigenen Richtlinien-Dokumentation der Praxis abgerufen werden. Das ist einer der Punkte, an denen Praxis und Theorie auseinandergehen.

Die Agenten von telli können zum Beispiel auf einen hochgeladenen Dokumenten-Korpus zugreifen (FAQs, Preislisten, Richtlinien) und während des Anrufs selbst entscheiden, ob sie semantische Suche, Keyword-Suche oder beides nutzen. Steht die Richtlinie zum Beispiel in einem PDF, wird sie direkt gelesen und vom Agenten verwendet statt geraten. Wird sie nicht gefunden, fällt der Agent auf den Prompt zurück, statt eine Antwort zu erfinden.

Schritt 5: Externe Systeme aufrufen

Was bringt eine sprechende KI, die sonst nichts kann? Unternehmen wollen KI-Agenten, die handeln: ins CRM schauen, Kundenprofile anlegen, Informationen prüfen oder Anrufe weiterleiten. All das läuft über Integrationen, APIs und Webhooks.

In unserem Szenario würde der Agent nach der Authentifizierung des Anrufers den Kalender nach freien Donnerstagsterminen abfragen, den Termin umbuchen, das Kundenprofil aktualisieren und sicherstellen, dass alles im CRM protokolliert ist, ganz ohne menschliches Zutun.

telli setzt das um, indem Agenten mitten im Gespräch "Tool Calls" auslösen können. Dazu gehören Funktionen, die Anrufe beenden, oder ein eigener HTTP-Endpoint, der die Kalenderverfügbarkeit prüft. Der Anrufer merkt von Tool Calls nichts; er hört nur: "Einen Moment, das schaue ich kurz nach."

Schritt 6: Text wird zu Sprache

Wenn das LLM schließlich weiß, was es sagen will, wandelt Text-to-Speech (TTS) diese Antwort zurück in das Audio, das der Anrufer hört. Moderne Systeme bieten ausgefeilte neuronale Stimmen statt der silbenweise zusammengestückelten Roboterstimmen von vor zehn Jahren, was Tempo, Aussprache und Tonfall der Agenten prägt.

Was menschlich klingende von künstlich klingender Sprache unterscheidet:

• Prosodie: natürliches Heben und Senken der Stimme statt flacher Aussprache
• Aussprache: Namen, Zahlen und Abkürzungen korrekt handhaben
• Tempo: weder gehetzt noch unnatürlich langsam
• Latenz: eine Antwort unter einer Sekunde, die den Austausch lebendig hält
• Streaming: Audio startet, bevor die vollständige Antwort überhaupt fertig generiert ist

Latenz wiegt hier schwerer als fast überall sonst in der Pipeline. Eine Stimme, die perfekt ist, aber zwei Sekunden zu spät kommt, fühlt sich kaputt an. Menschen erwarten einen Antwortrhythmus wie von einem anderen Menschen. Über Sprachen hinweg warten Menschen im Schnitt 200 ms zwischen dem Ende eines Satzes und dem Beginn des nächsten.

Voice-KI, die mehrere Anbieter für Spracherkennung, Sprachmodell und Sprachsynthese zusammenschaltet, liegt meist zwischen 600 ms und 1.700 ms Ende-zu-Ende, und alles über 800 ms ist laut Branchen-Benchmarks bereits spürbar zu spät.

Die eigene Erfahrung von telli zeigt gut, wie wichtig dieser Schritt ist. telli baut konversationelle KI-Agenten für B2C-Sales-Calls, wo eine hölzerne, unmenschliche Stimme nicht nur schlecht klingt, sondern aktiv die Conversion drückt, weil Anrufer auflegen, sobald die Stimme die Schwelle dessen unterschreitet, was sich "menschlich" anfühlt. Deshalb setzt telli auf einen TTS-Anbieter mit niedriger Latenz und Voice-Cloning-Fähigkeiten, statt die Stimmqualität als Nebensache hinter dem LLM zu behandeln.

So gehen KI-Sprachagenten mit Unterbrechungen um

Echte Gespräche laufen nicht rundenbasiert ab wie ein Text-Chat. Wir unterbrechen uns, machen Denkpausen oder lassen Sätze ausklingen. Diese Eigenschaft echter Gespräche heißt Barge-in und gehört zu den am schwersten zu lösenden Problemen der Voice-KI-Branche.

Sagt unser Anrufer mitten in der Umbuchungs-Bestätigung plötzlich "Warte, eigentlich möchte ich lieber absagen", muss das System diese Unterbrechung sofort erkennen, aufhören zu sprechen und die neue Eingabe verarbeiten, statt erst den Satz zu Ende zu sprechen und dann zu bemerken, dass der Anrufer seine Meinung geändert hat. Um solche Intent-Wechsel und Unterbrechungen korrekt zu erkennen, braucht das System kontinuierliche Voice Activity Detection in Echtzeit, nicht nur am Anfang und Ende eines Gesprächsbeitrags.

So funktionieren Übergaben an Menschen

Die besten KI-Gespräche enden auch nicht alle beim Agenten. Wenn die KI eine Anfrage nicht bearbeiten kann oder der Anrufer explizit nach einem Menschen fragt, muss der Anruf warm übergeben werden: Der Anrufer landet bei der richtigen Person, begleitet von einer Zusammenfassung des bisherigen Gesprächs, damit er nichts wiederholen muss.

An dieser Stufe scheitern viele an sich gute Voice-KI-Systeme. Wenn bei der Übergabe Transkript oder Kontext zwischen KI und Mensch verloren gehen, ist das nicht besser als ein komplett kalter Anruf. Absicht, CRM-Daten und bereits bestätigte Details müssen mit zur menschlichen Ansprechperson wandern.

Der Warm-Transfer-Ansatz von telli legt den Anrufer in die Warteschleife, brieft den menschlichen Agenten mit einer automatischen Zusammenfassung des Gesprächs und verbindet dann beide. Läuft die Übergabe in einen Timeout oder auf eine Mailbox, geht der Anruf zurück an den KI-Agenten.

Häufige technische Herausforderungen

Voice-KI hat reale Fehlerquellen. So sehen sie in der Praxis aus, statt der üblichen generischen Pro-und-Contra-Liste:

• Latenz entsteht durch sequenzielle Verarbeitung über STT → LLM → TTS. Lösung: Streaming-Architektur und parallelisierte Inferenz.
• Halluzinationen passieren, wenn das Modell aus Allgemeinwissen antwortet statt aus abgerufenen Fakten. Lösung: striktes Grounding und Retrieval-First-Prompting.
• Hintergrundgeräusche verschlechtern die Eingabequalität aus der Umgebung des Anrufers. Lösung: Rauschunterdrückung und Konfidenz-Schwellen.
• Schwache Dokumentation bedeutet eine dünne oder veraltete Wissensbasis. Lösung: regelmäßige Audits der Wissensbasis.
• API-Ausfälle kommen von Timeouts oder Fehlern in Drittanbieter-Integrationen. Lösung: Retry-Logik und saubere Fallback-Kommunikation.
• Unerwartete Fragen passieren, wenn der Anrufer vom Skript abweicht. Lösung: Fallback-Antworten und definierte Eskalationspfade.

Was Enterprise-KI-Sprachagenten anders macht

Die Anforderungen eines kleinen Unternehmens, das seinen ersten KI-Rezeptionisten testet, unterscheiden sich deutlich von denen eines Enterprise-Unternehmens, das KI-gestützte Telefoninteraktionen skaliert. Kurz gesagt trennt Enterprise-Deployments von kleineren Setups im Allgemeinen Folgendes:

• Compliance: Gesprächsaufzeichnung, Datenstandort, branchenspezifische Regulierung (Finanzdienstleistungen, Gesundheitswesen usw.)
• Observability: Transparenz darüber, wie jede Entscheidung im Anruf zustande kam, über das reine Transkript hinaus.
• Analytics: Conversions tracken, Abbrüche analysieren, Trends über Anrufe hinweg beobachten.
• Prompt-Versionierung: strukturierte Rollouts mit der Möglichkeit, Änderungen zurückzurollen.
• Testing: simulierte Test-Anrufe, bevor ein neues Deployment die Produktion erreicht.
• Monitoring: Echtzeit-Alerts, wenn Latenz oder Fehlerraten ausschlagen.
• Wissensmanagement: ein Rahmen, der sicherstellt, dass die Retrieval-Ebene bei Richtlinienänderungen aktuell bleibt

Das sind die Unterschiede zwischen einer Demo, die funktioniert, und einem System, das zehntausend Anrufe im Monat durchhält.

Das Observability-Feature von telli nutzt zum Beispiel das Konzept der "auto-structured fields". Während eines Anrufs zerlegt das System jede Interaktion in definierte Schlüsselfelder pro Agent, etwa Boolean-Werte, Kategorien, Zahlen oder Freitextfelder. Diese werden direkt aus dem Transkript gezogen, streng nach Schema. Lässt sich für ein Feld kein Wert im Transkript finden, bleibt es null. So werden aus tausenden unstrukturierten, chaotischen Anrufen durchsuchbare, vergleichbare Daten. Genau das ist der Kern dessen, was "enterprise-ready" bedeutet.

Häufige Missverständnisse

Ein paar Dinge, die es wert sind, direkt richtiggestellt zu werden:

• "LLMs speichern die Daten deines Unternehmens." Tun sie nicht. Sie rufen sie per RAG aus Unternehmensquellen wie FAQs, PDFs oder Wissensdatenbanken ab.
• "Voice-KI ist nur Spracherkennung mit einem Text-Bot dahinter." Spracherkennung ist nur eines von vielen beweglichen Teilen, die KI-Sprachagenten managen müssen, und typischerweise nicht das schwierigste.
• "Ein stärkeres Modell bedeutet automatisch einen besseren Sprachagenten." Modelle werden zwar immer besser, aber ein besseres Modell verbessert die Gesamtleistung des KI-Sprachagenten nicht, wenn zuverlässiger Datenabruf und Tool-Zugriff fehlen, um Aktionen korrekt auszuführen.

Alles zusammengesetzt

Nimmt man alle Schichten zwischen den Schritten weg, hat das ganze System nur einen Job: eine gesprochene Anfrage entgegennehmen und in normaler Gesprächszeit ein passendes Ergebnis erzeugen. Es beginnt mit Spracherkennung, die Worte von Audio in Text übersetzt. Sprachverständnis interpretiert diese Worte. Ein Large Language Model entscheidet auf Basis von Worten und Absicht, was zu tun ist. Retrieval liefert die unternehmensspezifischen Fakten. Tool Calls führen die Aktionen aus, und Sprachsynthese wandelt die Textantwort zurück in Sprache. Jede einzelne dieser Komponenten kann die gesamte Pipeline zum Scheitern bringen, egal wie gut die anderen funktionieren.

Verwendete Quellen

1. researchgate.net - Herausforderungen der Spracherkennung in lauten Umgebungen
2. pnas.org - Studie zu ethnischen Unterschieden in automatischer Spracherkennung
3. arxiv.org - Retrieval-Augmented Generation (RAG)
4. docs.telli.com - Knowledge-Base-Überblick
5. docs.telli.com - Tool-Calls-Überblick
6. researchgate.net - Universalien des Turn-Takings im Gespräch
7. telnyx.com - Voice-KI-Latenz-Benchmark
8. cartesia.ai - Die Low-Latency-Voice-Integration von telli
9. telli.com - Barge-in und Umgang mit Unterbrechungen bei KI-Sprachagenten
10. docs.telli.com - Call Transfer
11. docs.telli.com - Call Analysis