Kaskadierte vs. Fusionierte Modelle: Vergleich der Architekturen hinter Sprachagenten

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 Agenten bestimmt, wie natürlich, intelligent und konsistent seine Antworten sind und ob er sich über längere Zeit vorhersagbar verhält. Ein Agent mit einer fusionierten Architektur kann zum Beispiel in kurzen Gesprächen besonders lebensecht klingen, hat aber Schwierigkeiten beim logischen Denken oder bei der Konsistenz in längeren Dialogen.

Bei ElevenLabs setzen wir auf eine kaskadierte Architektur, die spezialisierte Komponenten für Spracherkennung, logisches Denken und Sprachsynthese miteinander verbindet. Im Gegensatz dazu nutzt das Realtime-Modell von OpenAI einen fusionierten Ansatz, bei dem diese Schritte in einem einzigen Netzwerk zusammengefasst werden.

In diesem Beitrag stellen wir die fünf wichtigsten Architekturen für Sprachagenten vor, beschreiben deren Aufbau, Vor- und Nachteile und zeigen, wie Teams je nach Zielsetzung die passende Lösung wählen.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 Entwicklung von Agenten optimieren

• 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

Gesprächskontext aufbauen 

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.

Die Dokumentenabfrage ist jedoch nur eine Möglichkeit, wie Agenten mit externen Systemen interagieren.

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.

Fusionierte Ansätze hingegen vereinen diese Schritte in einem einzigen multimodalen Modell. Audio wird direkt verarbeitet und ausgegeben, wobei Spracherkennung, Logik und Generierung im selben Netzwerk ablaufen. 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.“
• System-Prompt-Anweisung: „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.

Die fünf möglichen Architekturendynamische 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

Mit Ausführung und Orchestrierung als Grundlage folgt nun die Frage, wie die Leistung gemessen werden kann.

Bei einfachen kaskadierten Architekturen wird Audio transkribiert, das LLM erzeugt eine Textantwort und TTS spricht die exakten Worte aus. Da jede Stufe auf reinem Text basiert, haben Teams volle Transparenz und Kontrolle. Leitplanken können auf Textebene gesetzt werden, Tool-Aufrufe und API-Integrationen übernimmt das LLM direkt, und deterministische Abläufe ermöglichen eine vorhersehbare Steuerung von Gesprächen und Geschäftslogik.

Allerdings erkennt der Agent keine Nuancen wie Tonfall, Rhythmus oder Emotion, was die Natürlichkeit der Konversation einschränken kann.Datenerfassung 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.

Mögliche Anwendungsfälle sind:

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.

2. Fortgeschritten Kaskadiert

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.

Erweiterte kaskadierte Architekturen nutzen kontextuelles TTS, bei dem das LLM nicht nur entscheidet, was gesagt wird, sondern auch wie – etwa durch Anweisungen wie „antworte beruhigend“ oder „mit Nachdruck antworten“ an das TTS-Modell. Der Agent spricht dadurch realistischer, behält aber die gleichen Leitplanken, deterministischen Abläufe, Tool-Nutzung und Nachvollziehbarkeit wie ein einfaches kaskadiertes System.

Das ist der Ansatz hinter

Mögliche Anwendungsfälle sind ausdrucksstärkere Varianten von:

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.
• Der Ablauf durch verschiedene Übergangspunkte im Graphen gesteuert wird.

Spezialisierte Gesprächsziele

Einige kaskadierte Architekturen leiten akustische Merkmale (z. B. Aussprache, Emotion, Tonfall) direkt aus der Eingangssprache als Embeddings ins LLM weiter. So bleibt mehr von der ursprünglichen Absicht des Nutzers erhalten, während TTS modular bleibt. Tool-Nutzung und Leitplanken sind weiterhin möglich, aber der fusionierte ASR+LLM-Block ist schwerer zu prüfen als eine reine Textübergabe, und das LLM lässt sich nicht mehr so einfach austauschen wie bei einem kaskadierten Modell.

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.

4. Sequenzielle Fusion

Workflow-Übergänge mit LLM-Bedingungen steuern

Bei sequenziell fusionierten Architekturen übernimmt ein einziges multimodales Modell Erkennung, Logik und Sprachgenerierung. Das Modell arbeitet rundenbasiert: Es hört zu, bis der Nutzer fertig ist, und erzeugt dann direkt Audio. Durch die durchgängige Audiobearbeitung werden Merkmale wie Aussprache, Tempo und Intonation natürlich erfasst, was oft zu flüssigerer und ausdrucksstärkerer Sprache führt.

Der Nachteil: Leitplanken sind ohne Textebene schwerer durchzusetzen, Tool-Nutzung ist durch leichtere Logik-Kerne begrenzt und die Nachvollziehbarkeit ist ohne klare Zwischenstände eingeschränkt.

Wenn ein Gespräch in eine neue Phase übergeht, aktiviert das System eine speziell auf diesen Schritt zugeschnittene Agenten-Version. Jede Phase arbeitet mit eigenen, fokussierten Anweisungen und hat nur Zugriff auf das Wissen und die Tools, die für ihre Aufgabe relevant sind. Beispielsweise kann eine Phase zur Rückerstattungsbearbeitung auf Rückerstattungsrichtlinien zugreifen, ohne Kontext aus Onboarding oder Triage zu übernehmen. Der Wechsel zwischen Phasen wird durch explizite Übergangsbedingungen gesteuert. Diese Bedingungen legen fest, wann die Verantwortung wechselt, und ermöglichen eine natürliche Gesprächsführung. Um Kontinuität zu gewährleisten, bleibt das Nutzererlebnis über die Übergänge hinweg nahtlos, wobei jede Phase den relevanten Gesprächskontext übernimmt, ohne die Übergabemechanik offenzulegen. Schutzmechanismen überwachen zudem die Übergänge, um nicht zielführende Schleifen zu verhindern und den Workflow stabil und zielgerichtet zu halten.

Sicherheit und Datenschutz

5. Duplex-Fusion

Schutzmechanismen

Bei duplex-fusionierten Architekturen verarbeitet das Modell Ein- und Ausgabe gleichzeitig. Dadurch entsteht ein besonders menschlicher Gesprächsfluss mit echter Überschneidung in kurzen Dialogen, allerdings steigt die Komplexität deutlich. Leitplanken sind schwerer durchzusetzen, Übersprechen und Unterbrechungen können zu Fehlern führen und die Nachvollziehbarkeit ist im Vergleich zu kaskadierten Architekturen minimal.

Konforme Datenverarbeitung

Nutzer können Agenten gelegentlich sensible Informationen anvertrauen, die besonderen Anforderungen an Speicherung und Verarbeitung unterliegen – etwa medizinische Daten, die HIPAA-konform verarbeitet werden müssen. Für solche Fälle bieten wir den Zero Retention Mode (ZRM) auf Agenten- oder Workspace-Ebene an. Ist dieser aktiviert, werden alle Gesprächsdaten ausschließlich im Arbeitsspeicher verarbeitet und nie dauerhaft gespeichert. Nach Abschluss des Gesprächs und der Verarbeitung werden keine Informationen von ElevenLabs gespeichert. Gesprächsprotokolle, Audioaufnahmen und Analyseergebnisse sind daher nicht im Agents Dashboard verfügbar; diese Richtlinie gilt sowohl für kundenseitige Systeme als auch für interne Logs. Obwohl die Daten nicht gespeichert werden, werden sie während des Gesprächs verarbeitet und alle konfigurierten Post-Call-Webhooks erhalten die Ergebnisse, sodass Kunden Protokolle oder Analyseergebnisse bei Bedarf in eigenen Systemen speichern können.

Die passende Architektur für Ihren Anwendungsfall wählen

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.

In diesem Beitrag haben wir gezeigt, wie ElevenLabs Agenten Gesprächskontext, Tools, Bewertung und strukturierte Workflows steuern, um zuverlässige Echtzeit-Erlebnisse im großen Maßstab zu ermöglichen. Während Kunden Agenten in immer komplexeren Umgebungen einsetzen, erweitern wir kontinuierlich die Flexibilität unserer Orchestrierungs-Engine – von konfigurierbaren Bewertungsmodellen und erweiterten Übergangssteuerungen bis hin zu tieferer Transparenz bei Prompt-Komposition und Token-Nutzung über alle Phasen hinweg.

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.