Kaskadierte vs. Fused-Modelle: Wie die Architektur bestimmt, ob Ihr Voice-Agent unternehmensbereit ist

ElevenAgents werden von einer speziell für Echtzeit-Gespräche entwickelten Orchestrierungs-Engine mit niedriger Latenz betrieben, die weniger als 100 ms Verzögerung verursacht. Diese Architektur vereint die Forschung von ElevenLabs mit fortschrittlichen LLMs führender Anbieter wie OpenAI, Google und Anthropic sowie ausgewählten Open-Source-Modellen, die von ElevenLabs gehostet werden. Durch den Einsatz mehrerer Modelle in verschiedenen Phasen der Antwortpipeline sorgt der Agent für reaktionsschnelle und kontextbewusste Gespräche. Indem die Stärken der einzelnen Modelle dynamisch kombiniert werden, erreichen wir zuverlässige und skalierbare Leistung für verschiedenste Enterprise-Aufgaben und Gesprächsszenarien – bei optimalem Verhältnis von Intelligenz, Geschwindigkeit und Kosten.

Die Architektur des Agents bestimmt, wie zuverlässig er im Einsatz arbeitet, wie gut er sich an spezifische Geschäftsanforderungen anpassen lässt und wie natürlich er im Gespräch klingt. Eine fusionierte Architektur wie das Realtime-Modell von OpenAI kann in kurzen Dialogen sehr lebensecht wirken. Doch wenn Teams Compliance-Vorgaben durchsetzen, Fehler analysieren oder ein stärkeres LLM integrieren möchten, sobald es verfügbar ist, bietet ein einziges fused Netzwerk kaum Flexibilität.

Bei ElevenLabs setzen wir auf eine fortschrittliche, kaskadierte Architektur. Wir nutzen spezialisierte Komponenten für Spracherkennung, Reasoning und Sprachsynthese, um hohe Intelligenz und Zuverlässigkeit zu gewährleisten. Kontextuelle Prosodie, Optimierung für niedrige Latenz und intelligentes Turn-Taking sorgen für einen natürlichen Gesprächsfluss. Wir haben diese Architektur gewählt, weil Unternehmen und Behörden, mit denen wir arbeiten, Agents benötigen, die realistisch klingen und im produktiven Einsatz bei komplexen Aufgaben vertrauenswürdig sind.

Dieser Artikel stellt die fünf Hauptarchitekturen vor, zeigt ihre Stärken und Schwächen und erläutert, wie wir die Basis für Agents in kritischen Workflows sehen.Tools und eine Wissensdatenbank. Unabhängige Agenten sind sinnvoll, wenn der Anwendungsfall keine strikte Abfolge von Schritten erfordert oder wenn Wissenssilos zwischen Agenten vermieden werden sollen. Wissenssilos entstehen, wenn bestimmte Tools, Dokumente oder Kontextinformationen nur einzelnen Subagenten zur Verfügung stehen. Das ist bei Multi-Agent-Workflows inhärent und führt zu einem Kompromiss zwischen Flexibilität und Determinismus.

Worauf Teams bei der Wahl einer Architektur achten

• Effektive Generierungsanfragen erstellen
• Relevante Dokumente abrufen und einbinden
• Tool-Aufrufe generieren und ausführen, um Agentenantworten zu unterstützen
• Ergebnisse zur Auswertung und Datenerfassung bereitstellen

Kann der Agent komplexe Aufgaben bewältigen? 

Neben Faktoren wie Parallelität, Integrationen und Stimmqualität lassen sich die oben genannten Dimensionen am direktesten durch die Architektur des Agenten beeinflussen. Erfolgreiche Teams passen ihre Architektur gezielt an, um diese Dimensionen für ihren Anwendungsfall zu optimieren.

Kaskadierte Architekturen bestehen aus einer Kette spezialisierter Komponenten: , einem Large Language Model, und Text to Speech. Jede Stufe kann unabhängig optimiert, getestet und aktualisiert werden.früheren Beitrag beschrieben haben. So gelingt eine zuverlässige Dokumentenabfrage auch dann, wenn die letzte Nutzereingabe eine Rückfrage, eine Bestätigung oder keine explizite Frage enthält.

Ist der Agent im Produktivbetrieb vertrauenswürdig?

Diese Modularität ermöglicht es Teams, aktuelle LLMs für bessere Logik einzubinden, explizite Leitplanken auf Textebene zu setzen und die Sprachausgabe des Agenten durch kontextbezogene TTS präzise zu steuern. Der Hauptnachteil: Kaskadierte Architekturen verlieren oft mehr prosodische Merkmale – wie Intonation, Rhythmus und Emotion –, da Sprache zunächst in Text umgewandelt und dann neu generiert wird. Diese Merkmale lassen sich teilweise durch gezieltes Modellieren zurückgewinnen, werden aber nicht so natürlich erfasst wie bei fusionierten Ansätzen. Andere Faktoren wie Latenz und Gesprächssteuerung lassen sich in beiden Ansätzen meist auf vergleichbare Werte optimieren.

Die Abwägungen zwischen kaskadierten und fused Architekturen Mit jedem weiteren Tool steigt auch die Komplexität für das Modell, die richtige Reihenfolge der Tools zu wählen. Im Agent Builder beschreibt die Tool-Beschreibung, was das Tool macht und welche Felder es zurückgibt. Diese Informationen nutzt das Sprachmodell, um den Kontext der Anwendung zu verstehen. Die konkreten Bedingungen für den Einsatz des Tools werden im System-Prompt des Agenten definiert. Zum Beispiel:

• Tool-Beschreibung für lookup_order: „Ruft die Bestelldetails eines Kunden anhand der Bestell-ID ab. Gibt Bestellstatus, gekaufte Artikel, Lieferadresse und Sendungsnummer zurück.“
• Speech to Text„Nach Verifizierung der Identität des Kunden rufen Sie das Tool lookup_order auf, um die Bestelldetails abzurufen.“

Durch dieses Design können fusionierte Architekturen Prosodie effektiver erhalten und wiedergeben, da das Modell Aussprache und Intonation direkt verarbeitet. Allerdings sind fusionierte Modelle schwieriger zu testen und zu steuern, da Zwischenstände nicht sichtbar sind. Sie setzen zudem meist auf leichtere LLM-Kerne, was die Logik- und Tool-Nutzung im Vergleich zu kaskadierten Ansätzen einschränkt, die mit den leistungsstärksten Modellen kombiniert werden können.Prompting Guide. Innerhalb dieses Rahmens lassen sich verschiedene Tool-Typen definieren, insbesondere:

• Webhook-Tools, die externe APIs aufrufen.
• Client-Tools, die Tool-Anfragen als Events über den Conversation-Websocket senden.
• System-Tools für eingebaute Aktionen wie Anrufweiterleitungen.
• MCP-Tools, die mit Model Context Protocol-Servern verbunden sind.

Ein häufiger Kritikpunkt an kaskadierten Architekturen ist der Verlust prosodischer Merkmale. Sprache wird zu Text reduziert, und Intonation, Rhythmus und Emotionen müssen auf der Ausgabeseite rekonstruiert werden. Diese Merkmale lassen sich teilweise durch explizite Modellierung zurückgewinnen, werden aber nicht so natürlich erfasst wie bei fused Ansätzen. Andere Aspekte wie Latenz und Turn-Taking lassen sich in beiden Ansätzen meist auf vergleichbare Werte optimieren.dynamische Variable gespeichert werden. Diese Informationen werden als einfache Schlüssel-Wert-Paare abgelegt, die mithilfe vordefinierter Zuordnungen aus der Tool-Antwort extrahiert werden. Einmal gesetzt, können diese Variablen über den System-Prompt, zukünftige Tool-Parameter und Workflow-Bedingungen wieder in den Agenten einfließen. Dieser Feedback-Loop verleiht Agenten eine Art Arbeitsgedächtnis, das sich mit jeder Interaktion weiterentwickelt.

1. Basis-Kaskadiert

Fused Architekturen verfolgen einen grundsätzlich anderen Ansatz. Erkennung, Reasoning und Generierung erfolgen in einem einzigen multimodalen Netzwerk. Audio kommt rein, Audio geht raus – ohne überprüfbare Zwischenschritte.

Das Fehlen von Zwischenstufen ist sowohl Vorteil als auch Einschränkung. Fused-Architekturen können prosodische Merkmale natürlich erhalten, da Sprache nie in Text zerlegt wird. Allerdings sind Guardrails schwer durchsetzbar, einzelne Komponenten kaum austauschbar und Zwischenoutputs zur Fehleranalyse fehlen. Auch das Feintuning von STT für branchenspezifische Begriffe oder die Integration eines anderen LLMs für besseres Reasoning und Tool-Nutzung sind eingeschränkt. Das System ist ein Netzwerk, und Teams sind auf die Reasoning-Fähigkeiten beschränkt, mit denen es ausgeliefert wird – meist leichtere Kerne, die bei komplexen Aufgaben nicht mit den stärksten LLMs mithalten.

Die fünf ArchitekturenDatenerfassung und Bewertungskriterien ins Spiel. Die Datenerfassung ermöglicht es, strukturierte Informationen aus dem Gesprächsprotokoll für Analysen und Auswertungen zu extrahieren. Oft werden diese Daten in das Enterprise Data Lakehouse exportiert, um Berichte oder Anreicherungs-Workflows zu unterstützen. Beispielsweise kann ein Sales Development Agent automatisch Kontaktdaten aus einem Gespräch extrahieren, um einen Lead im CRM-System zu erstellen oder zu aktualisieren. Bewertungskriterien legen fest, ob ein Gespräch als erfolgreich gilt. Werden alle Kriterien erfüllt, wird das Gespräch als erfolgreich markiert, andernfalls als nicht erfolgreich. So wird sichergestellt, dass Gespräche stets die definierten Qualitäts- und Integritätsstandards erfüllen und schnelles Feedback möglich ist. Nach Abschluss eines Gesprächs und Auslösen des Post-Call-Webhooks verarbeitet der Agent das finale Protokoll – inklusive Tool-Ausführungen und Metadaten – zusammen mit allen konfigurierten Datenerfassungs- und Bewertungspunkten in einem LLM. Das Modell nutzt diesen kombinierten Prompt, um zu prüfen, ob jedes Bewertungskriterium erfüllt ist, und um die gewünschten Datenpunkte für die weitere Analyse zu extrahieren. Da das LLM diese Konfigurationen direkt als Teil des Prompts interpretiert, ist eine klare und konsistente Formatierung entscheidend, damit das Modell sie korrekt versteht und anwendet. Wir empfehlen daher folgende Best Practices für die Formulierung von Bewertungskriterien und Datenerfassungsbeschreibungen.

1. Basis-Kaskadiert

1. Kundensupport Eine Aussage oder ein kurzer Stichpunkt ist besser als mehrere Ziele in einem Kriterium.
2. Vertriebsassistenten Das Ziel so formulieren, dass Erfolg/Misserfolg anhand des Gesprächsprotokolls (was gesagt wurde, was der Agent getan hat, was der Nutzer gefragt hat) entschieden werden kann. Ziele vermeiden, die externen Kontext erfordern, den das LLM nicht kennt.
3. KI-Empfang Das LLM weiß bereits, dass das Ziel erfüllt sein muss, um als erfolgreich zu gelten, nicht erfüllt für Misserfolg und als unbekannt, wenn es nicht aus dem Protokoll hervorgeht. Das Ziel sollte daher so formuliert sein, dass „erfüllt“ vs. „nicht erfüllt“ klar unterscheidbar ist; bei Unklarheiten kann das Modell sonst zu „unbekannt“ oder falscher Klassifizierung tendieren.
4. NPCs in Unterhaltung und Gaming Oft werden viele Bewertungskriterien gleichzeitig geprüft. Lange Kriterien können zu Störungen führen und Halluzinationen begünstigen.
5. IVR-Ersatz Jede Begründung des LLM, ob ein Kriterium erfüllt wurde, erfolgt in der Sprache der Kriterienbeschreibung. Das sollte berücksichtigt werden.

Audio wird transkribiert, das LLM generiert eine Textantwort, und TTS spricht diese aus. Jede Stufe arbeitet mit Klartext, sodass Sie alles einsehen, testen und steuern können.

1. Genau beschreiben, was extrahiert werden soll: Die Beschreibung ist das wichtigste Signal für das LLM. Erklären Sie, was das Feld bedeutet, wann es gesetzt werden soll und was zu tun ist, wenn es unklar ist (z. B. „Leer lassen, falls der Kunde kein Wunschdatum genannt hat“).
2. Dem erwarteten Typ entsprechen: Der vom LLM gelieferte Wert entspricht immer dem Datentyp des Erfassungspunktes (z. B. Boolean, String, Integer). Die Beschreibung sollte dazu passen. Beispiel: „Anzahl der angeforderten Artikel extrahieren“ für Integer, „Ja/Nein, ob der Kunde dem Angebot zugestimmt hat“ für Boolean.
3. Enums verwenden, wenn möglich: Bei String-Typen, falls die Werte festgelegt sind, Enum im Schema nutzen; das schränkt das Modell ein und reduziert ungültige Ausgaben.
4. Ein Extraktionsziel pro Item: Keine mehreren, nicht zusammenhängenden Fakten in einer Beschreibung bündeln; für jedes Ziel ein eigenes Item anlegen.
5. Beschreibungen kurz halten: Beschreibungen können wenige Sätze umfassen; lange Absätze sind nicht nötig. Das Protokoll ist bereits in der Nutzernachricht enthalten, daher reichen Schema und kurze Beschreibung.

Beispielanwendungen:

Das ist der Ansatz hinter

2. Fortgeschritten kaskadiert

Kundensupport bieten eine visuelle Oberfläche zur Gestaltung komplexer Gesprächsabläufe. Am Ende entsteht ein logisches Objekt, das vom Orchestrator genutzt wird, um mehrere Subagenten, Tools und Übergaben unter einer unabhängigen Agentenkennung zu steuern. Workflows bringen zusätzliche Komponenten mit sich, die über die bereits für unabhängige Agenten beschriebenen hinausgehen, insbesondere wie:

• System-Prompts und Subagenten-Ziele zusammenwirken.
• Expressive Mode

Das LLM steuert dann das TTS nicht nur inhaltlich, sondern auch in der Art der Wiedergabe – etwa „beruhigend“, „mit Nachdruck“ oder „dringlich“ – und passt den Tonfall dynamisch an. Das Turn-Taking-System nutzt die gleichen Signale, um zu bestimmen, wann der Agent antwortet oder abgibt. Die Sprachmodelle sind in einem Stack zusammengefasst, ohne Netzwerk-Latenz zwischen den Komponenten.

Die Architektur behält alle Vorteile der Basis-Kaskade: volle Transparenz, Guardrails auf Textebene, Austauschbarkeit der Komponenten, Domänenanpassung und Zugriff auf die stärksten Reasoning- und Tool-Modelle. Hinzu kommen deutlich bessere Prosodie, Latenz und Turn-Taking. Teams können ein neues LLM sofort integrieren oder STT für medizinische Begriffe anpassen, ohne andere Komponenten neu zu bauen.

Auf dieser gemeinsamen Basis führen Workflows spezialisierte Subagenten ein, die innerhalb eines gerichteten Graphen agieren. Jeder Subagent erhält ein eng umrissenes Ziel und ergänzt die Basiskonfiguration um zusätzliche Prompt-Anweisungen, Tools und Wissensquellen, die nur für seine Rolle relevant sind. Anstatt das gesamte Gesprächs-Setup neu zu definieren, erweitern Subagenten die Intention des Basisagenten durch Prompt-Komposition und gezielte Kontext-Erweiterung. Während der Gesprächsverlauf über Subagenten-Wechsel hinweg erhalten bleibt, arbeitet jeder Subagent mit einer bewusst eingeschränkten System-Sicht. Wissensdatenbanken und Tools werden selektiv freigegeben, um klare Silos zu schaffen und Überschneidungen zu verhindern. Zur Verstärkung dieser Isolation wird das Orchestrator-Objekt bei jedem Übergang neu aufgebaut, als wäre es ein unabhängiger Agent. So bleibt der Prompt-Zustand, die Konfiguration und die verfügbaren Fähigkeiten des aktiven Subagenten vollständig deterministisch. Dieses Design ermöglicht es Workflows, globale Konsistenz mit lokaler Spezialisierung zu verbinden – für vorhersehbares Verhalten, klare Verantwortlichkeiten und präzise Steuerung von Kontext, Wissen und Aktionen in jeder Phase der Interaktion.

3. Hybrid Kaskadiert und Fused

Workflow-Übergänge mit LLM-Bedingungen steuern

Bei manchen Architekturen werden akustische Merkmale (Aussprache, Emotion, Tonfall) direkt aus der Eingangssprache als Embeddings ins LLM eingespeist, statt zuerst in Text umzuwandeln. TTS bleibt modular.

Dadurch erhält das LLM mehr Informationen darüber,

Beispielanwendungen:

Sicherheit und Datenschutz

4. Sequenziell Fused

Schutzmechanismen

Ein einziges multimodales Modell übernimmt Erkennung, Reasoning und Generierung in einem Durchgang, jeweils für eine Gesprächsrunde. Diese Architektur steckt hinter Modellen wie der Realtime API von OpenAI.

Die Prosodie kann stark sein. Da Sprache nie in Text zerlegt wird, bleiben Tempo, Intonation und emotionale Signale natürlich erhalten. Kurze Gespräche wirken dadurch sehr flüssig.

Allerdings sind Guardrails ohne Textebene kaum durchsetzbar, Zwischenoutputs zur Fehleranalyse fehlen, und die Flexibilität, ein besseres LLM zu integrieren oder STT für die eigene Domäne zu optimieren, ist begrenzt. Die Reasoning-Kerne sind meist leichter als die stärksten LLMs, sodass komplexe Tool-Nutzung und mehrstufige Aufgaben leiden. Bei komplexen Anforderungen reicht Prosodie allein nicht aus.

Beispielanwendungen:

Es gibt keine universelle Architektur für Sprachagenten. Jede Variante bringt Stärken und Abwägungen mit sich – von der Vorhersehbarkeit und Kontrolle kaskadierter Modelle bis zur natürlichen Prosodie fusionierter Ansätze.

5. Duplex Fusioniert

Unser Forward Deployed Engineering Team arbeitet eng mit Kunden zusammen, um sicherzustellen, dass diese Fähigkeiten sich im Gleichschritt mit realen Einsätzen weiterentwickeln. Die nächste Generation von Agenten wird noch mehr Transparenz, Determinismus und Anpassungsfähigkeit bieten – ohne Kompromisse bei der niedrigen Latenz, die Echtzeit-Gespräche möglich macht.