Die Orchestrierungs-Engine von ElevenAgent im Detail

ElevenAgents basieren auf einer latenzarmen Orchestrierungs-Engine, die speziell für Echtzeitgespräche entwickelt wurde und weniger als 100 ms Overhead verursacht. Diese Architektur kombiniert die Forschung von ElevenLabs mit führenden LLMs von Anbietern wie OpenAI, Google und Anthropic sowie ausgewählten Open-Source-Modellen, die bei ElevenLabs gehostet werden. Durch den Einsatz mehrerer Modelle in verschiedenen Phasen der Antwort-Pipeline stellt der Agent sicher, dass Gespräche sowohl reaktionsschnell als auch kontextbewusst sind. Indem wir die Stärken jedes Modells dynamisch kombinieren, erzielen wir zuverlässige, skalierbare Leistung für unterschiedlichste Unternehmensaufgaben und Gesprächsszenarien – bei optimiertem Verhältnis von Intelligenz, Geschwindigkeit und Kosten.

In diesem Beitrag erklären wir, wie diese Modelle zusammenarbeiten, um die Kernfunktionen bereitzustellen, die Agents für komplexe Umgebungen benötigen – und insbesondere, welches Modell welche Tokens wann sieht. Im Mittelpunkt steht die Verwaltung des Gesprächsverlaufs an verschiedenen Punkten der Interaktion. Wir zeigen erneut, wie und wo der Gesprächsverlauf geteilt wird, um seine Rolle in der Orchestrierung unabhängiger und Multi-Agent-Workflows zu verdeutlichen.

Unabhängiger Agent 

Wir beginnen mit dem unabhängigen Agent und seinen Kernkomponenten. Ein Agent mit minimalem Funktionsumfang verfügt sinnvollerweise über einen System Prompt, Zugriff auf mehrere Tools und eine Wissensdatenbank. Kunden sollten unabhängige Agents Workflows vorziehen, wenn ihr Anwendungsfall nur begrenzt eine strikte Abfolge von Schritten überprüfen muss oder wenn Wissenssilos innerhalb der Agents vermieden werden sollen. Wissenssilos entstehen, wenn bestimmte Tools, Dokumente oder historische Kontexte einigen Sub-Agents zugänglich sind, anderen jedoch nicht. Sie sind Multi-Agent-Workflows inhärent und bedeuten einen Kompromiss zwischen Flexibilität und Determinismus. 

Bei unabhängigen ElevenLabs Agents ist es wichtig zu verstehen, wie sie:

• effektive Generierungsanfragen erstellen
• relevante Dokumente abrufen und einbeziehen
• Tool-Aufrufe generieren und ausführen, um Agent-Antworten zu informieren
• Ergebnisse für Auswertung und Datenerfassung ausgeben

Gesprächskontext aufbauen 

Ein Gespräch zwischen einem Kunden und einem ElevenLabs Agent besteht aus einer Reihe von Turns, wobei jeder Turn einen Nachrichtenaustausch zwischen beiden Seiten umfasst. Diese abwechselnde Liste aus Agent- und Nutzernachrichten ist der Ausgangspunkt für den Gesprächskontext. Bei jedem Turn erhält das zugrunde liegende LLM Generierungsanfragen mit einer Reihe abwechselnder Agent- und Nutzernachrichten, die eine Nachricht länger ist als im vorherigen Turn. Dieser Nachrichtenreihe geht natürlich eine einzelne Systemnachricht mit dem System Prompt des Agents voraus.

Der ElevenLabs Orchestrator reduziert die wahrgenommene LLM-Latenz, indem er vorhersagt, wann ein Nutzer aufgehört hat zu sprechen. In manchen Fällen führt dies innerhalb eines einzelnen Turns zu mehreren LLM-Generierungsanfragen mit demselben Gesprächskontext.  Während die Orchestrierung optimiert, wie schnell Agents antworten, hängt die Antwortqualität ebenso stark davon ab, wie auf Wissen zugegriffen wird. Mit zunehmender Nutzung verankern Kunden die Antworten ihrer Agents typischerweise in einer Kombination aus proprietärer Dokumentation und öffentlichen Inhalten. Seit mehreren Jahren ist Retrieval-Augmented Generation (RAG) der Standardansatz dafür. ElevenAgents Wissensdatenbanken bauen auf RAG auf – mit einer optimierten Multi-Modell-Architektur, die wir in einem früheren Beitrag beschrieben haben. Sie ermöglicht zuverlässigen Dokumentenabruf, selbst wenn die letzte Nutzereingabe eine Rückfrage, die Bestätigung einer Klärung oder anderweitig keine explizite Frage ist.

Abruf ist jedoch nur eine Möglichkeit, wie Agents mit externen Systemen interagieren.

Aktionen ausführen und Informationen mit Tools abrufen

ElevenLabs Agents können über ein flexibles Tool-System während eines Gesprächs reale Aktionen ausführen und aktuelle Informationen abrufen. Diese Leistungsfähigkeit bringt eine wichtige Designüberlegung mit sich: Jedes aktivierte Tool vergrößert den serialisierten Prompt, da Name, Beschreibung und Parameterschema zusammen mit System Prompt und Gesprächsverlauf enthalten sind. Mit jedem weiteren Tool steigt auch der Schlussfolgerungsaufwand für das Modell, die richtige Abfolge von Tools aufzurufen. Im Agent Builder beschreibt die Tool-Beschreibung, was das Tool tut und welche Felder es zurückgibt. Diese Informationen nutzt das Sprachmodell, um den Nutzungskontext zu verstehen. Nach der Definition gehören die konkreten Bedingungen zum Aufrufen des Tools in den System Prompt des Agents. 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.“
• Anweisung im System Prompt: „Rufen Sie nach der Überprüfung der Kundenidentität das Tool lookup_order auf, um die Bestelldetails abzurufen.“

Diese Trennung der Verantwortlichkeiten hält Tool-Definitionen über Agents hinweg wiederverwendbar, während der System Prompt jedes Agents den exakten Zeitpunkt des Tool-Aufrufs steuert. Um Kunden bei der effektiven Gestaltung dieser System Prompts zu unterstützen, geben wir in unserem Prompting Guide weiterführende Hinweise. In diesem Rahmen lassen sich vor allem folgende Tool-Typen definieren:

• Webhook-Tools, die externe APIs aufrufen.
• Client-Tools, die Tool-Anfragen als Ereignisse über den Gesprächs-WebSocket senden.
• System-Tools für integrierte Aktionen wie Anrufweiterleitungen.
• MCP-Tools, die sich mit Model-Context-Protocol-Servern verbinden.

Wenn ein Agent ein Tool verwenden möchte, entnimmt er dem Gespräch die erforderlichen Details und sendet eine Anfrage zur Ausführung. Sobald das Tool ein Ergebnis zurückgibt, wird dieses zum Gespräch hinzugefügt, sodass das Modell in seiner nächsten Antwort natürlich darauf Bezug nehmen kann. Bei Bedarf kann die Tool-Ausgabe auch die gespeicherten Informationen des Agents als dynamische Variable aktualisieren. Diese gespeicherten Informationen werden als einfache Schlüssel-Wert-Paare abgelegt, die mithilfe vordefinierter Zuordnungen aus der Tool-Antwort extrahiert werden. Nach dem Setzen können diese Variablen über den System Prompt, künftige Tool-Parameter und Workflow-Bedingungen wieder in den Agent einfließen. Dieser Feedback-Loop gibt Agents eine Art Arbeitsgedächtnis, das sich im Verlauf der Interaktion weiterentwickelt.

Dies beschreibt zwar, wie Tools in die Schlussfolgerungen des Agents eingebunden werden, doch auch der Zeitpunkt ihrer Ausführung lässt sich konfigurieren. Tools können in drei Ausführungsmodi laufen, die jeweils für unterschiedliche Gesprächsanforderungen geeignet sind. Im Immediate Mode wird das Tool ausgeführt, sobald das LLM es anfordert. Dies ist der Standard für schnelle Abfragen, bei denen Nutzer eine nahezu sofortige Antwort erwarten, etwa bei der Prüfung eines Bestellstatus. In Verbindung mit Pre-Tool Speech erzeugt der Agent zunächst eine kurze Bestätigung wie „Ich prüfe das für Sie“ und gibt sie an den Nutzer zurück, während das Tool parallel läuft. Das minimiert Sprechpausen. Bei langsameren Tools verlängert die Plattform diese Füllnachrichten automatisch entsprechend der erwarteten Wartezeit. Der Post-Tool Speech Mode hingegen verzögert die Ausführung, bis der Agent zu Ende gesprochen hat. Das ist entscheidend für Aktionen mit realen Folgen, etwa die Weiterleitung eines Anrufs, das Beenden einer Sitzung oder das Absenden einer Zahlung. Der Nutzer hört den vollständigen Kontext, etwa „Ich verbinde Sie jetzt mit der Rechnungsabteilung“, und kann unterbrechen, bevor die Aktion ausgeführt wird. Im Async Mode läuft das Tool vollständig im Hintergrund, ohne das Gespräch anzuhalten. Dieser Modus eignet sich am besten für Fire-and-Forget-Vorgänge wie das Versenden einer E-Mail, das Auslösen eines externen Workflows oder das Protokollieren von Daten, bei denen der Agent das Ergebnis nicht in seiner Antwort erwähnen muss.

Nachdem Ausführung und Orchestrierung eingerichtet sind, geht es im nächsten Schritt darum, die Leistung zu messen.

Leistung messen

Nach Abschluss eines Anrufs mit einem Agent möchten Kunden möglicherweise bestimmte Informationen aus dem Anruf für weitere Analysen und zur Speicherung extrahieren oder feststellen, ob ein Anruf erfolgreich war. Hier kommen Datenerfassung und Bewertungskriterien ins Spiel. Die Datenerfassung ermöglicht es Ihnen, strukturierte Informationen aus einem Anruftranskript für nachgelagerte Analysen und Aggregationen zu extrahieren. Kunden exportieren diese Ergebnisse häufig in ihr unternehmensweites Data Lakehouse für Reporting- oder Anreicherungs-Workflows. Beispielsweise kann ein Sales Development Agent Details zu Interessenten automatisch aus einem Gespräch extrahieren, um einen Lead im Customer-Relationship-Management-System (CRM) anzulegen oder zu aktualisieren. Bewertungskriterien bestimmen dagegen, ob ein Anruf als erfolgreich gilt. Wenn alle konfigurierten Kriterien erfüllt sind, wird der Anruf als erfolgreich markiert, andernfalls als fehlgeschlagen. So erfüllen Gespräche konsistent definierte Standards für Qualität und Integrität und liefern zugleich schnelles Feedback. Nach Ende eines Anrufs und Auslösen des Post-Call-Webhooks verarbeitet der Agent das finale Transkript, einschließlich Tool-Ausführungen und Metadaten, gemeinsam mit allen konfigurierten Datenerfassungspunkten und Bewertungskriterien über ein LLM. Das Modell verwendet diesen kombinierten Prompt, um festzustellen, ob jedes Bewertungskriterium erfüllt ist, und die angegebenen Datenpunkte für nachgelagerte Analysen zu extrahieren. Da das LLM diese Konfigurationen direkt als Teil seines Eingabe-Prompts interpretiert, ist eine klare und einheitliche Formatierung wichtig, damit das Modell sie korrekt versteht und anwendet. Deshalb empfehlen wir die folgenden Best Practices für Beschreibungen von Bewertungskriterien und Datenerfassung.

Bewertungskriterien

1. Ein klares Ziel pro Kriterium: Ein Satz oder kurzer Stichpunkt ist besser als mehrere Ziele in einem Kriterium. 
2. Beobachtbar und transkriptbasiert: Formulieren Sie das Ziel so, dass Erfolg oder Misserfolg anhand des Transkripts entschieden werden kann – also anhand dessen, was gesagt wurde, was der Agent getan hat und was der Nutzer gefragt hat. Vermeiden Sie Ziele, die externen Kontext erfordern, den das LLM nicht hat.
3. Explizite Ergebnisse für Erfolg, Misserfolg und unbekannt: Das LLM weiß bereits, dass das Ziel für „erfolgreich“ erfüllt sein muss, für „fehlgeschlagen“ nicht erfüllt sein darf und für „unbekannt“ nicht anhand des Transkripts erkennbar sein darf. Formulieren Sie das Ziel daher so, dass „erfüllt“ und „nicht erfüllt“ klar definiert sind. Bei Mehrdeutigkeit kann das Modell zu unbekannten oder falschen Klassifizierungen neigen.
4. Prägnant formulieren: Manchmal werden viele Bewertungskriterien zusammen gesendet. Lange Bewertungskriterien können daher Rauschen hinzufügen und möglicherweise Halluzinationen verursachen.
5. Die Sprache ist wichtig: Jede Begründung des LLM dazu, ob ein Bewertungskriterium erfüllt wurde, wird in derselben Sprache wie die Kriterienbeschreibung ausgegeben. Behalten Sie dies im Blick.

Datenerfassung

1. Beschreiben Sie genau, was extrahiert werden soll: Die Beschreibung ist das wichtigste Signal für das LLM. Geben Sie an, was das Feld bedeutet, in welcher Situation es gesetzt werden soll und was bei Unklarheit zu tun ist, z. B. „Null lassen, wenn der Kunde nie ein Wunschdatum genannt hat“.
2. Dem erwarteten Typ entsprechen: Der vom LLM bereitgestellte Wert entspricht immer dem Datentyp, der dem Datenerfassungspunkt zugewiesen ist, z. B. Boolean, String oder Integer. Die Beschreibung sollte dazu passen. Verwenden Sie etwa „Extrahieren Sie die Anzahl der angefragten Artikel“ für Integer und „Ja/Nein, ob der Kunde dem Angebot zugestimmt hat“ für Boolean.
3. Enums verwenden, wenn möglich: Wenn bei String-Typen die möglichen Werte festgelegt sind, verwenden Sie ein Enum im Schema. Das begrenzt das Modell und reduziert ungültige Ausgaben.
4. Ein Extraktionsziel pro Element: Packen Sie nicht mehrere unabhängige Fakten in die Beschreibung eines Elements. Teilen Sie sie in separate Elemente auf, damit jeder Aufruf ein einziges klares Extraktionsziel hat.
5. Beschreibungen kurz halten: Beschreibungen können aus wenigen Sätzen bestehen. Lange Absätze sind nicht nötig. Das Transkript steht bereits in der Nutzernachricht; Schema und kurze Beschreibung reichen aus.

Aktuell ist das LLM für diesen Bewertungs- und Extraktionsschritt auf ein latenzarmes Modell festgelegt, um eine schnelle Verarbeitung sicherzustellen. In naher Zukunft wollen wir Optionen einführen, die Kunden mehr Flexibilität bieten. 

Als Nächstes betrachten wir Anwendungsfälle, die strukturierte Orchestrierung, Determinismus oder Spezialisierung über mehrere Gesprächsrollen hinweg erfordern und für die Kunden stattdessen Workflows nutzen können.

Workflows

Workflows bieten eine visuelle Oberfläche zum Entwerfen komplexer Gesprächsabläufe. Sie erzeugen letztlich das logische Objekt, das der Orchestrator verwendet, um mehrere Sub-Agents, Tools und Übergaben unter einer unabhängigen Agent-ID zu verwalten. Workflows führen zusätzliche Komponenten ein, die über die bereits für unabhängige Agents beschriebenen hinausgehen, darunter:

• wie System Prompts und Gesprächsziele von Sub-Agents zusammenwirken.
• wie der Durchlauf verschiedener Übergangspunkte im Graphen bestimmt wird.

Spezialisierte Gesprächsziele

Workflows nutzen Funktionen unabhängiger Agents wieder, um Verhalten durchzusetzen, das während einer Interaktion konsistent bleibt. Dazu gehören gemeinsame Elemente wie der Basis-System-Prompt, zentrale Tools und globale Wissensdatenbanken, die unabhängig vom aktiven Teil des Workflows immer verfügbar sein sollten. Der übergeordnete System Prompt definiert typischerweise den globalen Gesprächskontext, den erwarteten Ton, Sicherheitsvorgaben sowie marken- oder produktübergreifende Anweisungen.

Auf dieser gemeinsamen Grundlage führen Workflows spezialisierte Sub-Agents ein, die in einem gerichteten Graphen arbeiten. Jeder Sub-Agent erhält ein eng abgegrenztes Ziel und erweitert die Basiskonfiguration um zusätzliche Prompt-Anweisungen, Tools und Wissensquellen, die nur für seine Rolle relevant sind. Statt die gesamte Gesprächskonfiguration neu zu definieren, ergänzen Sub-Agents ihre Absicht durch Prompt-Komposition und selektive Kontexterweiterung zum Basis-Agent. Der Gesprächsverlauf bleibt bei Übergängen zwischen Sub-Agents erhalten, um Kontinuität zu gewährleisten. Dennoch arbeitet jeder Sub-Agent mit einer bewusst eingeschränkten Sicht auf das System. Wissensdatenbanken und Tools werden selektiv freigegeben. Das schafft klare Silos und verhindert Informationslecks zwischen Verantwortungsbereichen. Um diese Trennung zu verstärken, wird das Orchestrator-Objekt bei jedem Übergang neu aufgebaut, als wäre es ein unabhängiger Agent. Dadurch bleiben Prompt-Status, Konfiguration und verfügbare Fähigkeiten des aktiven Sub-Agents vollständig deterministisch. Dieses Design ermöglicht es Workflows, globale Konsistenz mit lokaler Spezialisierung zu verbinden. Das Ergebnis sind vorhersehbares Verhalten, eine klare Trennung von Verantwortlichkeiten und präzise Kontrolle darüber, wie Kontext, Wissen und Aktionen in jeder Phase einer Interaktion eingesetzt werden.

Ein zentraler Mechanismus für diese Kontrolle ist die Steuerung der Übergänge zwischen Sub-Agents.

Workflow-Übergänge mit LLM-Bedingungen steuern

Workflows durchlaufen einen gerichteten Graphen von Sub-Agents, wobei Übergänge zwischen Knoten durch explizite Bedingungen gesteuert werden. Diese Bedingungen bestimmen, wann die Steuerung von einem Sub-Agent zum nächsten wechselt, und ermöglichen Workflows, auf Nutzereingaben, Tool-Ergebnisse und dynamische Variablen zu reagieren. Graph-Bedingungen können deterministisch oder LLM-ausgewertet sein. Deterministische Bedingungen wie bedingungslose Übergänge, Prüfungen auf Basis dynamischer Variablenausdrücke oder Tool-Ergebnisbedingungen bieten starke Garantien für den Kontrollfluss und eignen sich gut, um einen strikten Ablauf durch einen Workflow durchzusetzen. LLM-basierte Bedingungen ermöglichen dagegen die semantische Bewertung von Kriterien in natürlicher Sprache, etwa das Erkennen von Nutzerabsichten oder die Feststellung, ob bestimmte Informationen bereitgestellt wurden.

Wichtig ist, dass LLM-Bedingungen außerhalb des System Prompts des aktiven Agents ausgewertet werden und das Generierungsverhalten des Agents nicht beeinflussen. Stattdessen wertet der Orchestrator sie parallel anhand des aktuellen Gesprächszustands aus. Diese Trennung stellt sicher, dass die Übergangslogik weder den Prompt des Agents beeinträchtigt noch die Generierung von Antworten beeinflusst. Gleichzeitig können Workflows LLM-Schlussfolgerungen für eine flexible Graph-Traversierung nutzen. Durch die Kombination deterministischer und LLM-ausgewerteter Bedingungen können Workflows sowohl Vorhersagbarkeit als auch Anpassungsfähigkeit erreichen: mit deterministischen Übergängen, wenn Korrektheit entscheidend ist, und LLM-basierten Übergängen, wenn semantische Interpretation erforderlich ist.

Wenn ein Gespräch in eine neue Phase übergeht, aktiviert das System eine speziell auf diesen Schritt zugeschnittene Version des Agents. Jede Phase arbeitet mit eigenen fokussierten Anweisungen und hat nur Zugriff auf Wissen und Tools, die für ihre Verantwortung relevant sind. Beispielsweise kann eine Phase zur Bearbeitung von Rückerstattungen auf Erstattungsrichtlinien zugreifen, ohne irrelevanten Kontext aus Onboarding oder Triage zu übernehmen. Der Wechsel zwischen Phasen wird durch explizite Übergangsbedingungen geregelt. Diese Bedingungen bestimmen, wann Verantwortung wechseln soll, und ermöglichen Routing-Entscheidungen, die sich natürlich aus dem Gesprächsverlauf ergeben. Um Kontinuität zu wahren, bleibt die Nutzererfahrung über Übergänge hinweg nahtlos. Jede Phase übernimmt den relevanten Gesprächskontext, ohne die Mechanik der Übergabe offenzulegen. Schutzmechanismen überwachen zudem Übergänge, um unproduktive Routing-Zyklen zu verhindern und den Workflow stabil und zielgerichtet zu halten.

Sicherheit und Schutz

Für Fälle mit erhöhten Sicherheits- und Schutzanforderungen können Kunden zusätzliche Komponenten des Orchestrators nutzen. 

Guardrails

ElevenLabs Agents implementieren Sicherheits-Guardrails über ein konfigurierbares Moderations- und Alignment-System, das Nutzer- und Agent-Nachrichten in Echtzeit auswertet. Eingehende Inhalte werden in mehreren Risikokategorien klassifiziert, darunter sexuelle Inhalte, Gewalt, Belästigung, Hass und Selbstverletzung, jeweils mit unabhängig konfigurierbaren Schwellenwerten. Wenn ein Guardrail ausgelöst wird, wird das Gespräch sofort beendet und der Client erhält einen eindeutigen Fehlergrund. So werden unsichere Interaktionen frühzeitig und konsistent blockiert, ohne sich allein auf Prompt-basierte Maßnahmen zu stützen. Guardrails arbeiten außerhalb der Prompt-Logik des Agents und bieten eine zuverlässige Durchsetzungsebene, die weder durch Modellverhalten noch durch Nutzereingaben umgangen werden kann. Dieser Ansatz ermöglicht Kunden, die Sicherheitssensitivität an ihren Bereich anzupassen und gleichzeitig eine deterministische Durchsetzung zur Laufzeit beizubehalten.

Konforme Datenverwaltung

Sprecher teilen mit einem Agent manchmal sensible Informationen, die strengen Anforderungen an Speicherung und Verarbeitung unterliegen, etwa medizinische Daten, die HIPAA-konform verarbeitet werden müssen. Für diese Anwendungsfälle bieten wir den Zero Retention Mode (ZRM) auf Agent- oder Workspace-Ebene. Wenn er aktiviert ist, werden alle Anrufdaten ausschließlich im Speicher verarbeitet und niemals in einem persistenten Speicher abgelegt. Nach Abschluss von Anruf und Verarbeitung bewahrt ElevenLabs keine Informationen auf. Daher sind Transkripte, Audioaufzeichnungen und Analyseergebnisse nicht im Agents Dashboard verfügbar. Diese Richtlinie gilt sowohl für kundenorientierte Systeme als auch für interne Logs. Obwohl die Daten nicht gespeichert werden, werden sie während des Anrufs verarbeitet. Konfigurierte Post-Call-Webhooks erhalten die Ergebnisse, sodass Kunden Transkripte oder Analyseergebnisse bei Bedarf in ihren eigenen Systemen speichern können. 

Wenn ZRM aktiv ist, stellen wir außerdem sicher, dass Subprozessoren keine Daten speichern. Dafür beschränken wir die verfügbaren LLMs auf Anbieter mit vertraglichen Verpflichtungen, die Training mit oder Speicherung von Kundendaten untersagen. Derzeit umfasst dies Modelle von Google Gemini und Anthropic Claude. Kunden, die unter ZRM ein anderes LLM nutzen möchten, können eine eigene Vereinbarung mit diesem Anbieter schließen und es als benutzerdefiniertes LLM mit API-Schlüsseln konfigurieren, die unter diese Vereinbarung fallen. Da dies die Datenverarbeitung über unsere standardmäßige Vertrauensgrenze hinaus erweitert, muss unser Safety-Team den Anwendungsfall vor der Aktivierung manuell prüfen und genehmigen. ZRM stellt zwar sicher, dass ElevenLabs und seine Subprozessoren keine Anrufdaten speichern, Kunden bleiben jedoch dafür verantwortlich, dass externe Tools oder Webhooks ihres Agents die geltenden Aufbewahrungs- und regulatorischen Anforderungen erfüllen.

Ausblick

In diesem Beitrag haben wir untersucht, wie ElevenLabs Agents Gesprächskontext, Tools, Auswertung und strukturierte Workflows verwalten, um zuverlässige Echtzeiterlebnisse im großen Maßstab bereitzustellen. Da Kunden Agents in zunehmend komplexen Umgebungen einsetzen, erweitern wir die Flexibilität unserer Orchestrierungs-Engine fortlaufend – von konfigurierbaren Bewertungsmodellen und umfassenderen Übergangssteuerungen bis hin zu tieferen Einblicken in Prompt-Komposition und Token-Nutzung über alle Phasen hinweg.

Unser Forward Deployed Engineering Team arbeitet eng mit Kunden zusammen, damit sich diese Fähigkeiten im Gleichschritt mit realen Deployments weiterentwickeln. Die nächste Generation von Agents wird noch mehr Transparenz, Determinismus und Anpassungsfähigkeit bieten, ohne die latenzarme Leistung zu beeinträchtigen, die Echtzeitgespräche ermöglicht.