Integration externer Agenten mit der Sprachorchestrierung von ElevenLabs Agents

Frontier-Agent-Orchestratoren können zunehmend komplexe Aufgaben übernehmen und über die gesamte Palette von Enterprise-Tools hinweg arbeiten. Das erfordert ein sorgfältiges Management des Zustands von Anwendung, Konversation und System. Für andere Modalitäten als Sprache haben sich unter dem Sammelbegriff Context Engineering, Muster etabliert, die darauf abzielen, einheitliche Verfahren rund um den System Prompt eines Agenten im Verlauf einer Interaktion zu schaffen. Die Einbindung von Sprache fügt nicht nur eine weitere Zustandsdimension für die Komponenten der Sprachinteraktion hinzu, sondern ermöglicht idealerweise auch die Wiederverwendung von Ergebnissen aus früherer Arbeit mit anderen Modalitäten. 

In diesem Beitrag erläutern wir, wie ElevenLabs Agents externe Agenten unterstützen und welche Muster eine detaillierte Kontrolle über ihre Integration ermöglichen. Mit diesen Mechanismen können Kunden die erstklassige Sprachorchestrierung von ElevenLabs nutzen und zugleich die volle Kontrolle über ihre umfassendere Orchestrierung behalten.

Kernkomponenten

ElevenLabs Agents

In seiner einfachsten Form ist ein ElevenLabs Agent über einen WebSocket-Client zugänglich. Informationen zu Server- und Client-Ereignissen in der Konversation werden als JSON-Objekte an den Agenten und von ihm übertragen. Wenn der Agent Nutzersprache transkribiert, löst er unmittelbar eine Generierungsanfrage aus. Wir unterstützen die meisten großen Modellanbieter und ermöglichen Kunden, ihr eigenes Custom LLM einzubringen. Wenn Kunden einen komplexeren Orchestrator (Agenten) hinter dem Custom LLM einsetzen, um Generierungsanfragen zu beantworten, muss dieser entweder OpenAIs Chat Completions API oder Responses API unterstützen. Diese API-Formatspezifikation wird von den meisten großen Frameworks zur Agentenerstellung problemlos unterstützt (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...). 

Nach der Integration müssen diese Agenten häufig jederzeit ihren internen und externen Zustand lesen und aktualisieren können – unabhängig vom vorgeschalteten Sprachorchestrator. Ein effektives Management stellt die Konsistenz mit bestehenden rein textbasierten Agenten sicher. 

Zustandsverwaltung

Die Daten, die ein Agent zur effizienten Navigation in seiner Umgebung verfolgen muss, sind per Definition stark aufgabenspezifisch. Bei ElevenLabs Agents, die von einem externen Agenten betrieben werden, ist es sinnvoll, den Zustand in einigen klar definierten Kategorien zu verwalten.

Der interne Zustand steuert die Dynamik der Konversation. Zu den Elementen, die als Teil des internen Zustands eines Agenten erfasst werden, gehören:

• Aktueller Gesprächsverlauf, einschließlich Sprachaktivität, Unterbrechungen und Identifizierung des aktiven Sprechers.
• Anwendungsspezifische Erkenntnisse aus der Echtzeitanalyse von Transkripten, etwa erkannte Absichten, Entitäten oder Stimmungen.
• Reasoning-Verlauf, einschließlich Zwischengedanken, Hypothesen und früherer Lösungsversuche.
• Konfigurations- und Betriebsparameter wie aktive Ziele, Betriebsmodus und temporäre Einschränkungen, die sein Verhalten während der Interaktion steuern.

Der externe Zustand konzentriert sich hingegen primär auf relevante Systeme und Personen, mit denen der Agent interagiert oder die er beeinflusst. Zu den Elementen, die als Teil des externen Zustands eines Agenten erfasst werden, gehören:

• Status anderer Nutzer oder Systeme, mit denen er interagiert, beispielsweise ihre aktuellen Ziele, Verfügbarkeit oder Berechtigungen.
• Tools und Wissensdatenbanken, etwa APIs, Datenbanken oder Integrationen, die die Handlungsfähigkeit des Agenten beeinflussen können.
• Laufende Aufgaben und Abhängigkeiten mit externen Akteuren oder Systemen, die die nächsten Schritte des Agenten beeinflussen.

Wir beschreiben ein gängiges Muster, um diese Informationen über den gesamten Lebenszyklus der Beziehung eines Agenten zu einem Nutzer hinweg zuverlässig zu verwalten.

Lösungskomponenten

Überblick 

In diesem Abschnitt behandeln wir die Architekturkomponenten und Implementierungsdetails, die für die erfolgreiche Integration komplexer externer Agenten erforderlich sind. Im Kern dieses Ansatzes steht die Möglichkeit, eine beliebige, aber eindeutige Kennung für eine Sitzung über alle Dienste hinweg weiterzuleiten. Bei ElevenLabs Agents mit Custom LLMs lässt sich das umsetzen, indem die erforderliche Kennung als LLM-Parameter im Extra-Body-Objekt übergeben wird, das Teil der Conversation Overrides beim Starten eines Anrufs ist. So kann die Kennung vom Nutzer über den ElevenLabs Agent bis zum externen Agenten fließen. 

Beachten Sie den zustandsbehafteten Proxy hinter dem Custom LLM. Dieser Dienst, der normalerweise nicht vorhanden ist, ermöglicht es, einzelne Generierungsanfragen beliebigen Kennungen zuzuordnen, die Verbindungen zum externen Agenten darstellen. Die Implementierung dieses Dienstes liegt in der Verantwortung der Entwickler des externen Agenten. In seiner einfachsten Form verwaltet der Proxy Verbindungen, die durch eindeutige Kennungen repräsentiert werden und ElevenLabs-Konversationen oder Call-SIDs (für Telefonie) zugeordnet sind. Erweiterte Versionen können dagegen Hierarchien bei der Zuordnung von Konversationen zu komplexeren Kundenbeziehungen einführen, die mehrere Interaktionen umfassen.

In diesen erweiterten Konfigurationen verwaltet der Proxy zusätzliche Kennungen, die über eine einzelne Anfrage für eine einzelne nachgelagerte Sitzung hinausgehen. Statt dass jede Kennung nur eine Konversation oder Call-SID darstellt, kann der Proxy eine Kennung mehreren zusammenhängenden Interaktionen zuordnen. Dadurch kann das System Customer Journeys kanalübergreifend verfolgen, historischen Kontext wiederverwenden und mehrere Interaktionen gleichzeitig koordinieren. Eine Zuordnung kann beispielsweise mehrere Webchat-Sitzungen, einen anschließenden Sprachanruf und einen internen Support-Workflow unter derselben logischen Kundenkennung zusammenfassen. Der Proxy kann Anfragen dann anhand einfacher Regeln an die richtige Kennung weiterleiten und gleichzeitig einen einheitlichen Zustand hinter dem Custom LLM bewahren. Dies ermöglicht flexiblere, dauerhafte mehrstufige Interaktionen, die vom externen Agenten verwaltet werden.

Nachrichtenübermittlung

Über die erfolgreiche Zuordnung von Generierungsanfragen zu übergeordneten Entitäten hinaus kann der zustandsbehaftete Proxy über API-Anfragen die bidirektionale Nachrichtenübermittlung mit externen Quellen wie dem Anwendungs-Frontend oder einem separaten Router-Dienst unterstützen. Bei Anwendungen, in denen dies erforderlich ist, müssen ElevenLabs Agents nicht wissen, dass Nachrichten an andere Dienste weitergegeben werden.  

Beispielsweise ist es für externe Agenten oft nützlich, Einblick in die laufende Sprachaktivität zu haben. So können sie feststellen, ob der Nutzer spricht, wie lange und ob sie präventiv Maßnahmen ergreifen sollten. Diese Erkenntnisse lassen sich direkt ableiten und nutzen, indem verarbeitete Voice Activity Detection (VAD)-Werte, die ElevenLabs Agents bereitstellen, als Client-Ereignisse über den Conversation-WebSocket empfangen werden. Wenn die Client-Anwendung Werte von ElevenLabs erhält, kann sie VAD-Client-Ereignisse entsprechend den Anforderungen der Anwendung an den zustandsbehafteten Proxy weiterleiten und dabei die beliebige Sitzungskennung in die Nachricht aufnehmen. Der zustandsbehaftete Proxy muss eine Logik zur Anfragezuordnung implementieren, die die bestehende Verbindung für die Sitzung optimal identifiziert. 

Dieses Muster lässt sich auf jedes Ereignis vom Client ausweiten, sofern es als JSON-Block ausgedrückt werden kann. Es ist jedoch auch sinnvoll, Ereignisse sichtbar zu machen, die vom Agenten selbst ausgehen. Ein häufiges Beispiel ist der Lebenszyklus von Tool-Aufrufen oder Wissensdatenbankabfragen, die Vorgänge auf externen Systemen darstellen. Diese Mechanismen sind grundlegend für die Agenten, die Unternehmen heute entwickeln.

Bei der Integration externer Agenten über ein Custom LLM werden die Funktionen von ElevenLabs für Tool Calling und Retrieval-Augmented Generation (RAG) häufig zugunsten der eigenen Implementierung des externen Agenten umgangen. Die Verantwortung für diese Komponenten liegt somit vollständig beim Anbieter des externen Agenten. Anwendungen profitieren dennoch von Transparenz bei Tool-Aktivitäten, da sie dadurch den Fortschritt des Agenten anzeigen und die Endnutzererfahrung entsprechend aktualisieren können.

Um diese Transparenz zu schaffen, sendet der externe Agent bei jedem Tool-Aufruf Nachrichten – sowohl für Anfragen als auch für Antworten. Der zustandsbehaftete Proxy leitet diese Nachrichten an Client-Anwendungen weiter, die sie über eine dedizierte Nachrichtenwarteschlange verarbeiten. Dies entspricht den Mechanismen der Client-Ereignisse von ElevenLabs Agents und stellt sicher, dass Anwendungen nachvollziehen können, wann der Agent aus einem externen System liest oder es verändert.

Mit diesen Kernkomponenten und der bidirektionalen Nachrichtenübermittlung zwischen Proxy und Client-Anwendung können Kunden externe Agenten in ElevenLabs Agents integrieren, um ausschließlich dessen Sprachorchestrierung zu nutzen und gleichzeitig die Verantwortung für alle Teile der LLM-Orchestrierung zu behalten. 

Bezug zum Zustand

Die effektive Unterstützung komplexer externer Agenten erfordert eine klare Aufteilung der Verantwortlichkeiten zwischen Proxy und Agenten, insbesondere bei der Zustandsverwaltung. In diesem Modell verwaltet der Proxy eine Tabelle relevanter Interaktionen, die nach den Anforderungen der Anwendung gruppiert sind, und leitet Nachrichten mit zustandsloser Logik zwischen sich und dem Agenten weiter. Der externe Agent wiederum sollte alle wesentlichen internen und externen Informationen verarbeiten und speichern, die zum Gesamtzustand beitragen.

Auch wenn eine Lockerung dieser Trennung den Überarbeitungsaufwand einer bestehenden Lösung weiter verringern kann, führt eine klare Grenze in der Regel zu robusteren und besser skalierbaren Ergebnissen, wenn das Aufgabenspektrum des Agenten wächst.

Ausblick

Mit der zunehmenden Nutzung sprach- und nicht sprachfähiger Agenten durch Unternehmen erwarten wir, dass sich Muster für die Informationen herausbilden, die diese Agenten benötigen. So können wir die Entwicklung und Verantwortlichkeiten für die in diesem Beitrag beschriebenen Dienste vereinfachen. In der Zwischenzeit entwickeln wir weiterhin für die Anforderungen, die bereits entstanden sind. Unser Forward Deployed Engineering Team arbeitet eng mit Kunden zusammen, um diese neuen Anforderungen in konkrete Produktfunktionen zu übersetzen und sicherzustellen, dass sich unsere Lösungen parallel zu realen Implementierungen weiterentwickeln.

Wenn Sie bereits mit einem bestehenden Agenten arbeiten und mit ElevenLabs Agents Sprache ermöglichen möchten, während Sie die Verantwortung für Ihre LLM-Orchestrierung behalten, testen Sie diesen Ansatz und teilen Sie uns Ihre Meinung mit.