Sprachassistenten hören nicht zu – sie lesen.

Während sie nachdenken, sind sie fast wie taub und blind. Sie können nichts anderes mehr von dem wahrnehmen, was um sie herum passiert. -

@miramurati

Es verblüfft mich, dass die meisten Voice Agents ihre Entscheidungen immer noch auf Basis eines Transkripts treffen.

Jeder Anruf wird von Audio in Text umgewandelt, bevor die „Denkschicht“ des Agenten ihn zu sehen bekommt. Diese Umwandlung ist verlustbehaftet. Nur die Wörter überleben. Das Zögern, das „Ähm“, die sinkende Tonhöhe am Satzende, die Hintergrundgeräusche, das halbe Wegdrehen, um mit jemand anderem zu sprechen: all das geht verloren.

Also rät der Agent. Er fällt Leuten mitten im Gedanken ins Wort, wartet zu lange, nachdem sie fertig gesprochen haben, und übersieht die Wut hinter einem höflichen Satz.

Ich glaube, das ist heute die größte Lücke in der Voice-KI.

Dieser Artikel ist meine Sicht auf den Status quo und geht folgenden Fragen nach:

• Kann ein Agent gute Entscheidungen treffen, wenn er den Anruf nie hört?
• Warum hat ein Netz aus LLMs diese Lücke nicht geschlossen?
• Warum nicht einfach Speech-to-Speech-Modelle nutzen?
• Wie würde eine „Denkschicht“ aussehen, die wirklich zuhört?

Wo steht der Markt heute?

https://x.com/jordan_dearsley/status/2085602471918064064

Jahrelang wurde vorhergesagt, dass Sprache zur universellen Art wird, mit Software zu kommunizieren. 2026 beginnt sich diese Vorhersage zu bewahrheiten. KI wickelt jedes Jahr Milliarden von Geschäftsanrufen ab – dank Unternehmen wie @ElevenLabs und @DeepgramAI sowie mehr als 800 Voice-KI-Produkten.

Aber wie in der Frühphase jeder Technologiewelle hat die Verbreitung die Qualität überholt. Nur etwa jedes fünfte Unternehmen ist mit seinen Agenten im Produktivbetrieb sehr zufrieden. Deshalb bleiben die meisten Agenten bei dem, was bezahlbar und zuverlässig ist: ausgehende Anrufe nach Skript oder eingehende Anfragen, die simpel genug sind, um sie vorherzusagen.

Fast alle Voice Agents sind kaskadiert aufgebaut: Speech-to-Text (STT), dann ein LLM, dann Text-to-Speech (TTS). Entwickler lieben dieses Design, weil sie für jede Aufgabe das beste Modell wählen, jeden Zwischenschritt mitlesen und streng kontrollieren können, was der Agent sagt und tut.

Während STT und TTS bei Latenz und Kosten große Fortschritte gemacht haben, ist der schwache Punkt die Denkschicht.

Was ein Transkript alles wegwirft

Die Aufgabe der Denkschicht ist simpel: erkennen, in welchem Zustand sich das Gespräch befindet, und die Aktion wählen, die es in den richtigen nächsten Zustand bringt – sprechen, handeln, übergeben oder weiter zuhören.

Dein Code weiß immer, an welchem Schritt des Workflows ein Anruf gerade ist. Was er nicht weiß, ist, was bei der Person am anderen Ende passiert. Genau das muss die Denkschicht bei jedem Turn lesen:

• Ist der Nutzer fertig oder hat er nur eine Pause gemacht?
• Welche Sprache spricht er?
• Ist er neugierig oder wütend wegen schlechtem Service?
• Ist das ein Fernseher im Hintergrund oder spielende Kinder?
• Spricht er mit mir oder mit seinem Partner?
• Was will er: eine Rückerstattung, ein neues Konto, eine Statusabfrage?

Zwei Audioclips mit demselben Transkript: „Ja, legen Sie los.“ Einer ist an den Agenten gerichtet, der andere an jemanden im Raum. Nur das Audio unterscheidet sie.

Die fett gedruckten Fragen oben verraten uns, wie etwas gesagt wurde, nicht nur was. Ein Transkript behält die Wörter und verwirft Tonhöhe, Tempo, Pausen und Raumklang.

Nimm die erste Frage. Wir alle wissen, dass jemand gleich fertig ist, bevor die Stille kommt: Die Tonhöhe sinkt, das Tempo wird langsamer, die Stimme verklingt. Modelle, die das Audio hören, lernen genau diese Signale zu nutzen (Ekstedt & Skantze, 2022). Aber Modelle, die nur Transkripte lesen, können das nicht, weil die Prosodie nie aufgeschrieben wurde (Rajaa, 2026).

Gleiches gilt für die fünfte Frage. Als Apple testete, ob Sprache für seinen Assistenten bestimmt war, reduzierte das Hinzufügen des Audios zum Transkript die Fehlerquote um bis zu 39 % im Vergleich zum reinen Transkript.

Die besten Entscheidungen nutzen Audio und Text zusammen. Leider bekommen heutige Agenten nur den Text.

Nur Transkript: Bei 74,8 % der Turns wurde zu früh unterbrochen. Mit Audio: 7,8 %. Uniphore, arXiv 2609.11066.

Warum das Netz aus LLMs an eine Wand stößt

Für die „Denkschicht“ haben Entwickler die gierige Lösung gewählt. Sie nahmen den einfachsten Weg mit dem größten sofortigen Ertrag: das jeweils beste Frontier-LLM mieten und ihm ein einziges riesiges Handbuch geben, was es tun soll. So lief das gesamte Jahr 2023–24.

Das bringt ein paar Probleme mit sich.

• Erstens merkten Teams, dass LLMs unberechenbar und langsam sind und sie Anweisungen in langen, dichten Prompts verlieren.
• Zweitens reicht ein einzelner LLM-Aufruf nicht aus, um eine Äußerung zu verstehen.

Der nächste logische Schritt war also ein Netz aus schnelleren, günstigeren LLMs: jedes für eine andere Aufgabe, mit einem Orchestrator darüber. Die Demos waren fantastisch. Käufer waren beeindruckt und die Umsätze begannen zu fließen.

Das ist heute der Frontier-Stack.

Im Produktivbetrieb zeigte diese Architektur jedoch zwei Risse:

• Jede Komponente liest immer noch dasselbe Transkript. Mehr LLMs hinzuzufügen kann die Pause oder den Tonfall nicht zurückbringen, die das Transkript bereits geschluckt hat.
• Die Komponenten warten aufeinander. Jeder Aufruf kostet Zeit. Den Turn zu erkennen, zu entscheiden, was zu tun ist, und die Aufgaben auszuführen, beansprucht bis zu 80 % der Antwortzeit.

Ein kaskadierter Voice Agent: Das Audio des Anrufers geht zu Speech-to-Text, dann folgen mehrere LLM-Aufrufe, dann Text-to-Speech. Tonhöhe, Pausen, Klang, Hintergrund und Adressat gehen schon bei Speech-to-Text verloren.

Die Branche hat die Denkschicht nach Aufgaben aufgeteilt. Sie hätte sie nach Input aufteilen sollen: Entscheidungen, die Audiosignale brauchen, sollten an ein audio-natives Modell gehen, und das LLM sollte nur mit Text arbeiten.

Warum das Transkript nicht einfach ganz weglassen?

Speech-to-Speech-Modelle (STS) zeigten dieses Jahr erstmals echte Lebenszeichen. Der Reiz liegt auf der Hand: geringere Latenz, besseres Gesprächsverständnis und weniger Engineering-Aufwand, weil STT, LLM und TTS in einem einzigen Modell komprimiert werden.

Der größte Nachteil ist der Mangel an Kontrolle und verifizierten Daten. Man kann nicht festnageln, was ein STS-Modell sagen wird, und Tool-Aufrufe oder Code-Ausführung liegen einem Modell, das in Audio denkt, nicht natürlich.

Ich glaube, STS ist kurzfristig noch weit von der Realität entfernt. Selbst wenn es schneller vorangeht, wird es zunächst für einfachere Anwendungsfälle wie FAQ-Antworten passen. Entwickler werden bei der Kaskade bleiben – teils aus Gewohnheit, vor allem aber, weil sie deren Kontrolle und Flexibilität brauchen.

Deshalb baue ich Modelle, die den kaskadierten Stack leichter kontrollierbar machen und sowohl bei Kosten als auch bei Latenz realistisch einsetzbar.

Die Schicht, die zuhört

Ich bin überzeugt, dass es einen Weg gibt, Agenten zu kontrollieren und den Ballast abzuwerfen: Entscheidungsmodelle.

Schau dir GPT-Live genau an, und du findest im Kern eine Decision Engine. Mehrmals pro Sekunde entscheidet sie, ob sie sprechen, weiter zuhören, pausieren, unterbrechen oder ein Tool aufrufen soll. Die Kaskade braucht dieselbe Engine – als Komponente, die man sehen und steuern kann.

Ein Entscheidungsmodell nimmt den aktuellen Zustand und eine begrenzte Menge an Optionen (sprechen oder warten, eskalieren oder fortfahren, welcher Intent) und liefert eine Wahl mit einer Wahrscheinlichkeit zurück – schneller und deutlich günstiger als ein LLM. @typesafeai hat viele damit überrascht, wie gut das bei Text funktioniert.

Mein Vorschlag:

• Das Entscheidungsmodell hört dem Anruf zu und trifft die begrenzten Entscheidungen.
• Deine Software hält Workflow-Zustand, Berechtigungen und Tools.
• Das LLM tut, worin es am besten ist: die Antwort formulieren, sobald die Entscheidung gefallen ist, was zu tun ist.

Ein Entscheidungsmodell nimmt Audio, den bisherigen Gesprächsverlauf und eine Reihe von Optionen entgegen und gibt für jede Option eine Wahrscheinlichkeit zurück: refund_status 0,91, cancel_order 0,06, escalate 0,03 (Beispiel).

Der Konfidenzwert ist das, was das Ganze zum Laufen bringt. Frag ein LLM, wie sicher es sich ist, und es wird meist „sehr“ sagen – selbst wenn es falsch liegt (Xiong et al., 2024). Die Werte eines Klassifikators lassen sich so kalibrieren, dass sie halten, was sie versprechen: Wenn ein Klassifikator sagt, er sei sicher, stimmt das meistens auch (Guo et al., 2017).

Unsere frühen Experimente mit Designpartnern zeigen, dass 30 bis 40 % dessen, was ein LLM in einem Agenten tut, genau diese Art von Arbeit ist: Routing, Triage, Auswahl zwischen begrenzten Optionen.

Aber heutige Entscheidungsmodelle arbeiten mit Text oder Bildern. TypeSafe AI berichtet, dass jedes Modell – Jev eingeschlossen – schlechtere Entscheidungen trifft, wenn neben Text eine weitere Modalität hinzukommt, und Jev hat keine dokumentierte Audio-Unterstützung.

Man kann Audio nicht einfach an ein Text-Entscheidungsmodell anflanschen. Eines zu bauen, das zuhört, erfordert drei Dinge:

• Echtes Gesprächsaudio, das in jedem Moment mit der richtigen Entscheidung gelabelt ist
• Ein Modell, das Audio und Text gemeinsam für die Entscheidung nutzt
• Konfidenzwerte, die über Akzente, Rauschen und schlechte Telefonleitungen hinweg stabil bleiben.

Das richtige Entscheidungsmodell für Sprache ist eines, das zuhört – eine audio-native Entscheidungsschicht.

Was sich ändert, wenn die Entscheidungsschicht hören kann

Mit einem audio-nativen Entscheidungsmodell erschließt du folgende Anwendungsfälle:

1. Agenten, die du debuggen kannst. Viele Teams entwerfen einen Agenten heute als Zustandsgraphen: begrüßen, Identität prüfen, Rückerstattung bearbeiten, eskalieren. Jeder Turn läuft auf zwei Entscheidungen hinaus: In welchem Zustand ist das Gespräch wirklich, und in welchen Zustand soll es als Nächstes wechseln? Ist eine davon falsch, driftet der ganze Anruf ab.

Mit einem Entscheidungsmodell an jedem Schritt wird jeder Übergang zu einer kleinen, erklärbaren Einheit: Was wurde gehört, welche Optionen gab es, was wurde gewählt und wie sicher war das Modell? Wenn ein Anruf schiefgeht, debuggst du keinen riesigen Prompt. Du findest das eine Zahnrad, das verrutscht ist, und reparierst genau dieses Teil.

1. Antworten, die bereit sind, bevor der Anrufer fertig ist. Menschen verraten, was sie wollen, bevor sie den Satz beenden. „Ich rufe wegen der Bestellung an, die ich letzte Woche aufgegeben habe …“ ist bereits eine Bestellabfrage. Ein text-zentrierter Agent wartet, bis der Nutzer aufhört, wartet auf das finale Transkript, entscheidet, welches Tool er aufruft, und ruft es erst dann auf. Jeder Schritt verlängert die Stille.

Zeitachse eines Anrufers, der sagt: „Ich rufe wegen meiner Bestellung von letzter Woche an.“ Ein text-zentrierter Agent wartet bis zum Ende, transkribiert dann, entscheidet und ruft get_order auf. Ein zuhörender Router feuert get_order schon mitten im Satz ab und antwortet, sobald der Anrufer aufhört – das spart Zeit.

Ein Entscheidungsmodell, das zuhört, arbeitet wie ein Router, der dem Anruf zuvorkommt. Es erkennt den Intent mitten im Satz und startet die Abfrage, während der Nutzer noch spricht, sodass die Bestelldetails in dem Moment bereitliegen, in dem er aufhört.

Forscher von Meta und der CMU haben gezeigt, was das bringt: Tool-Anfragen parallel zur Sprache des Nutzers vorherzusagen, senkte die Tool-Latenz um 20 % und machte die Antworten präziser.

1. Persönliche Agenten, die sich sofort anfühlen. Persönliche Agenten hören den ganzen Tag Sprachbefehle – in Küchen, Autos und auf belebten Straßen. Das meiste davon braucht nur einen schnellen Check: Ist das eine Aufgabe, eine Erinnerung, ein flüchtiger Gedanke oder gar nicht an mich gerichtet?

Jede Äußerung an ein Frontier-LLM zu schicken, ist langsam und teuer. Ein kleines Modell, das zuhört, trifft diese Entscheidung in einem Bruchteil der Zeit und weckt das LLM nur, wenn echte Arbeit ansteht. Der Agent fühlt sich sofort an, weil die erste Entscheidung nie auf das große Modell warten muss.

https://x.com/signulll/status/2077444321243013306

Die Zukunft der Voice-KI

Sprache sollte eigentlich das universelle Interface werden. Heute funktioniert sie nur, wenn das Gespräch vorhersehbar ist.

Aber ein ungeskriptetes Gespräch ist nicht grenzenlos. Bei jedem Turn sind die sinnvollen Züge wenige: sprechen, warten, fragen, handeln, übergeben. Was niemand skripten kann, ist die Reihenfolge. Du musst ein Gespräch nicht skripten, um es zu kontrollieren. Du musst jede einzelne Entscheidung gut treffen – basierend auf dem, was tatsächlich gehört wurde.

Auf diesen Wandel setze ich: erst entscheiden, dann prompten. Ein zuhörendes Modell trifft die Entscheidungen, deine Software hält den Zustand, und das LLM formuliert die Worte. Jede Entscheidung ist sichtbar, schnell und messbar. Wenn das funktioniert, hört Sprache auf, nur ein Kanal für einfache Anrufe zu sein, und wird zu der Art, wie Menschen mit Software sprechen.

Ich baue diese Entscheidungsschicht bei @tazolabs und werde in den nächsten Tagen mehr über unsere Modelle teilen.

Wenn du Voice Agents baust, würde ich gerne hören, mit welchen Entscheidungen dein Agent heute kämpft. Und wenn dich diese Vision anspricht, komm zu Tazo Labs und bau mit uns.

Welche Entscheidung macht dein Voice Agent am häufigsten falsch?