Die Orchestrierungs-Engine von ElevenAgent im Detail

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.

In diesem Beitrag erklären wir, wie diese Modelle zusammenarbeiten, um die zentralen Fähigkeiten bereitzustellen, die Agenten in komplexen Umgebungen benötigen – insbesondere, welches Modell zu welchem Zeitpunkt welche Tokens sieht. Im Mittelpunkt steht dabei das Management des Gesprächsverlaufs an verschiedenen Punkten der Interaktion. Wir zeigen, wie und wo der Gesprächsverlauf geteilt wird, um seine Rolle in der Orchestrierung für unabhängige und Multi-Agent-Workflows zu verdeutlichen.

Unabhängiger Agent

Wir beginnen mit dem unabhängigen Agenten und seinen Kernkomponenten. Ein minimal wertvoller Agent verfügt typischerweise über einen System-Prompt, Zugriff auf verschiedene 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.

Für unabhängige Agenten bei ElevenLabs ist es wichtig zu verstehen, wie sie:

• 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 

Ein Gespräch zwischen einem Kunden und einem ElevenLabs Agent besteht aus einer Reihe von Gesprächsrunden, in denen beide Parteien abwechselnd Nachrichten austauschen. Diese Abfolge von Agenten- und Nutzernachrichten bildet die Grundlage für den Gesprächskontext. In jeder Runde erhält das zugrundeliegende LLM eine Generierungsanfrage mit einer Serie abwechselnder Agenten- und Nutzernachrichten, die jeweils um eine Nachricht länger ist als in der vorherigen Runde. Diese Nachrichtenreihe beginnt stets mit einer Systemnachricht, die den System-Prompt des Agenten darstellt.

Der ElevenLabs Orchestrator reduziert die wahrgenommene LLM-Latenz, indem er vorhersagt, wann ein Nutzer mit dem Sprechen fertig ist. Dadurch kann es vorkommen, dass innerhalb einer Runde mehrere LLM-Generierungsanfragen mit identischem Gesprächskontext gestellt werden. Während die Orchestrierung die Reaktionsgeschwindigkeit optimiert, hängt die Antwortqualität ebenso stark davon ab, wie Wissen abgerufen wird. Mit zunehmender Nutzung binden Kunden die Antworten ihrer Agenten meist sowohl an eigene Dokumentationen als auch an öffentliche Inhalte. Seit einigen Jahren ist Retrieval-Augmented Generation (RAG) der Standardansatz dafür.ElevenAgents Wissensdatenbanken bauen auf RAG auf und nutzen eine optimierte Multi-Modell-Architektur, die wir in einem 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.

Aktionen ausführen und Informationen mit Tools abrufen

ElevenLabs Agenten können während des Gesprächs reale Aktionen ausführen und Live-Informationen über ein flexibles Tool-System abrufen. Dabei gilt es zu beachten: Jedes aktivierte Tool vergrößert den serialisierten Prompt, da Name, Beschreibung und Parameterschema zusammen mit System-Prompt und Gesprächsverlauf übermittelt werden. 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.“

Diese Trennung sorgt dafür, dass Tool-Definitionen agentenübergreifend wiederverwendbar bleiben, während der System-Prompt den genauen Einsatzzeitpunkt steuert. Für die Gestaltung effektiver System-Prompts bieten wir weiterführende Hinweise in unserem 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.

Immer wenn ein Agent ein Tool nutzen möchte, entnimmt er die nötigen Details aus dem Gespräch und sendet eine Anfrage zur Ausführung. Sobald das Tool ein Ergebnis liefert, wird dieses dem Gespräch hinzugefügt, sodass das Modell in der nächsten Antwort darauf Bezug nehmen kann. Falls erforderlich, kann das Tool-Ergebnis auch als 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.

Neben der Integration in die Agentenlogik lässt sich auch der Ausführungszeitpunkt von Tools konfigurieren. Tools können in drei Ausführungsmodi laufen, die jeweils für unterschiedliche Gesprächssituationen geeignet sind. Im Immediate Mode wird das Tool sofort nach Anforderung durch das LLM ausgeführt – ideal für schnelle Abfragen wie Bestellstatus, bei denen Nutzer eine sofortige Antwort erwarten. In Kombination mit Pre-Tool-Speech erzeugt der Agent zunächst eine kurze Bestätigung wie „Ich prüfe das für Sie“ und sendet diese an den Nutzer, während das Tool parallel läuft, um Wartezeiten zu minimieren. Bei langsameren Tools verlängert die Plattform diese Zwischenmeldungen automatisch entsprechend der erwarteten Wartezeit. Im Post-Tool-Speech Mode wird die Ausführung dagegen verzögert, bis der Agent zu Ende gesprochen hat – wichtig für Aktionen mit realen Konsequenzen wie Anrufweiterleitungen, Sitzungsende oder Zahlungsabwicklung. Der Nutzer hört den vollständigen Kontext, z. B. „Ich verbinde Sie jetzt mit der Abrechnung“, und kann vor der Ausführung noch eingreifen. Im Async Mode läuft das Tool komplett im Hintergrund, ohne das Gespräch zu unterbrechen – ideal für Aufgaben wie das Versenden von E-Mails, das Auslösen externer Workflows oder das Protokollieren von Daten, bei denen das Ergebnis nicht in der Antwort benötigt wird.

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

Leistung messen

Nach Abschluss eines Gesprächs mit einem Agenten möchten Kunden bestimmte Gesprächsinhalte extrahieren, analysieren oder den Erfolg bewerten. Hier kommen 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.

Bewertungskriterien

1. Ein klares Ziel pro Kriterium: Eine Aussage oder ein kurzer Stichpunkt ist besser als mehrere Ziele in einem Kriterium.
2. Beobachtbar und transkriptbasiert: 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. Explizite Ergebnisse für Erfolg/Misserfolg/Unbekannt: 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. Kurz halten: Oft werden viele Bewertungskriterien gleichzeitig geprüft. Lange Kriterien können zu Störungen führen und Halluzinationen begünstigen.
5. Sprache beachten: Jede Begründung des LLM, ob ein Kriterium erfüllt wurde, erfolgt in der Sprache der Kriterienbeschreibung. Das sollte berücksichtigt werden.

Datenerfassung

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.

Aktuell wird für diesen Auswertungs- und Extraktionsschritt ein LLM mit niedriger Latenz verwendet, um schnelle Verarbeitung zu gewährleisten. In Kürze werden wir Optionen einführen, die Kunden mehr Flexibilität bieten.

Im nächsten Schritt betrachten wir Anwendungsfälle, die strukturierte Orchestrierung, Determinismus oder Spezialisierung über mehrere Gesprächsrollen hinweg erfordern. Hierfür können Kunden Workflows nutzen.

Workflows

Workflows 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

Workflows nutzen Funktionen unabhängiger Agenten, um ein konsistentes Verhalten während der gesamten Interaktion sicherzustellen. Dazu gehören gemeinsame Elemente wie der Basis-System-Prompt, zentrale Tools und globale Wissensdatenbanken, die immer verfügbar sein sollen – unabhängig davon, welcher Teil des Workflows aktiv ist. Der übergeordnete System-Prompt definiert in der Regel den globalen Gesprächskontext, den gewünschten Ton, Sicherheitsvorgaben und marken- oder produktspezifische Anweisungen.

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.

Ein zentrales Element dieser Steuerung ist die Regelung der Übergänge zwischen Subagenten.

Workflow-Übergänge mit LLM-Bedingungen steuern

Workflows schreiten voran, indem sie einen gerichteten Graphen von Subagenten durchlaufen, wobei Übergänge zwischen den Knoten durch explizite Bedingungen gesteuert werden. Diese Bedingungen legen fest, wann die Kontrolle von einem Subagenten zum nächsten wechselt, und ermöglichen es Workflows, auf Nutzereingaben, Tool-Ergebnisse und dynamische Variablen zu reagieren. Graph-Bedingungen können deterministisch oder LLM-basiert sein. Deterministische Bedingungen – wie bedingungslose Übergänge, Ausdrücke auf Basis dynamischer Variablen oder Tool-Ergebnisse – bieten starke Garantien für den Ablauf und eignen sich für strikt vorgegebene Workflows. LLM-basierte Bedingungen ermöglichen dagegen die semantische Auswertung von Kriterien in natürlicher Sprache, etwa das Erkennen von Nutzerintentionen oder das Feststellen, ob bestimmte Informationen vorliegen.

Wichtig ist: LLM-Bedingungen werden außerhalb des aktiven System-Prompts des Agenten ausgewertet und beeinflussen nicht das Generierungsverhalten des Agenten. Sie werden stattdessen parallel vom Orchestrator anhand des aktuellen Gesprächszustands geprüft. Diese Trennung stellt sicher, dass die Übergangslogik den Prompt des Agenten nicht beeinflusst und die Antwortgenerierung unbeeinträchtigt bleibt, während Workflows dennoch LLM-Logik für flexible Graph-Durchläufe nutzen können. Durch die Kombination deterministischer und LLM-basierter Bedingungen erreichen Workflows sowohl Vorhersehbarkeit als auch Anpassungsfähigkeit – mit deterministischen Übergängen, wo Korrektheit entscheidend ist, und LLM-basierten Übergängen, wo semantische Interpretation erforderlich ist.

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

Für Anwendungsfälle mit erhöhten Anforderungen an Sicherheit und Datenschutz können Kunden auf zusätzliche Funktionen des Orchestrators zurückgreifen.

Schutzmechanismen

ElevenLabs Agenten setzen Schutzmechanismen durch ein konfigurierbares Moderations- und Alignmentsystem um, das Nutzer- und Agenten-Nachrichten in Echtzeit bewertet. Eingehende Inhalte werden in verschiedene Risikokategorien wie sexuelle Inhalte, Gewalt, Belästigung, Hass und Selbstgefährdung eingestuft, jeweils mit individuell einstellbaren Schwellenwerten. Wird ein Schutzmechanismus ausgelöst, wird das Gespräch sofort beendet und der Client mit einer klaren Fehlermeldung informiert. So werden unsichere Interaktionen frühzeitig und konsequent blockiert, ohne sich allein auf Prompt-basierte Maßnahmen zu verlassen. Schutzmechanismen arbeiten außerhalb der Prompt-Logik des Agenten und bieten eine zuverlässige Durchsetzungsebene, die nicht durch Modellverhalten oder Nutzereingaben umgangen werden kann. Kunden können die Sensitivität der Schutzmechanismen an ihre Anforderungen anpassen und erhalten gleichzeitig deterministische Durchsetzung zur Laufzeit.

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.

Bei aktiviertem ZRM stellen wir zudem sicher, dass Subprozessoren keine Daten speichern, indem wir die verfügbaren LLMs auf Anbieter beschränken, die vertraglich zusichern, keine Kundendaten für Training oder Speicherung zu verwenden – aktuell sind das Modelle von Google Gemini und Anthropic Claude. Kunden, die unter ZRM ein anderes LLM nutzen möchten, können dies tun, indem sie eine eigene Vereinbarung mit dem Anbieter abschließen und das Modell als Custom LLM per API-Key einbinden. Da dies die Datenverarbeitung über unsere Standard-Grenzen hinaus erweitert, muss unser Safety-Team den Anwendungsfall vor Freischaltung manuell prüfen und genehmigen. Während ZRM sicherstellt, dass ElevenLabs und Subprozessoren keine Gesprächsdaten speichern, bleibt es in der Verantwortung der Kunden, dass externe Tools oder Webhooks ihres Agenten die geltenden Aufbewahrungs- und Compliance-Anforderungen erfüllen.

Ausblick

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.