Externe agents integreren met de stemorchestratie van ElevenLabs Agents

Toonaangevende agentorchestrators kunnen steeds beter complexe taken uitvoeren en werken met allerlei bedrijfstools. Dit vereist zorgvuldig beheer van de status van de applicatie, het gesprek en het systeem. Voor andere modaliteiten dan spraak zijn er gemeenschappelijke patronen ontstaan onder de verzamelterm context engineering, die als doel heeft consistente werkwijzen op te bouwen rond de systeemprompt van een agent naarmate een interactie vordert. Het toevoegen van spraak introduceert niet alleen een extra statuslaag voor het beheren van onderdelen van de spraakinteractie, maar maakt idealiter ook hergebruik mogelijk van artefacten uit eerder werk met andere modaliteiten. 

In dit artikel beschrijven we hoe ElevenLabs Agents externe agents ondersteunen en welke patronen gedetailleerde controle over hun integratie mogelijk maken. Met deze mechanismen kunnen klanten gebruikmaken van de hoogwaardige spraakorchestratie van ElevenLabs, terwijl ze volledig eigenaar blijven van hun bredere orchestratie.

Kerncomponenten

ElevenLabs Agents

In de eenvoudigste vorm is een ElevenLabs Agent toegankelijk via een Websocket-client. Informatie over server- en clientevents in het gesprek gaat als JSON-objecten van en naar de agent. Wanneer de agent spraak van een gebruiker transcribeert, start deze direct een generatieverzoek. We ondersteunen de meeste grote modelproviders en klanten kunnen hun eigen Custom LLM meebrengen. Wanneer klanten een complexere orchestrator (agents) inzetten om generatieverzoeken achter de Custom LLM te beantwoorden, moeten ze ervoor zorgen dat deze OpenAI's Chat Completions API of Responses API ondersteunt. Gelukkig wordt deze API-opmaakspecificatie eenvoudig ondersteund door de meeste grote frameworks voor het bouwen van agents (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...). 

Na integratie moeten deze agents vaak op elk moment hun interne en externe status kunnen lezen en bijwerken, ongeacht de spraakorchestrator waarachter ze zich bevinden. Dit effectief beheren zorgt voor consistentie met bestaande agents die alleen tekst gebruiken. 

Statusbeheer

De gegevens die een agent moet bijhouden om efficiënt door zijn omgeving te navigeren, zijn per definitie sterk taakspecifiek. Voor ElevenLabs Agents die worden aangestuurd door een externe agent, is het nuttig om de status in enkele duidelijk afgebakende categorieën bij te houden.

De interne status bepaalt de dynamiek van het gesprek. Voorbeelden van elementen die worden bijgehouden als onderdeel van de interne status van de agent zijn:

• Huidige gespreksverloop, waaronder spraakactiviteit, onderbrekingen en identificatie van de actieve spreker.
• Applicatiespecifieke inzichten uit realtime-analyse van transcripties, zoals gedetecteerde intenties, entiteiten of sentiment.
• Redeneerspoor, waaronder tussenliggende gedachten, hypothesen en eerdere pogingen om een oplossing te genereren.
• Configuratie- en operationele parameters, zoals actieve doelen, werkmodus en tijdelijke beperkingen die het gedrag tijdens de interactie sturen.

Externe status richt zich daarentegen voornamelijk op relevante systemen en personen waarmee de agent communiceert of die deze beïnvloedt. Voorbeelden van elementen die worden bijgehouden als onderdeel van de externe status van de agent zijn:

• Status van andere gebruikers of systemen waarmee de agent communiceert, zoals hun huidige doelen, beschikbaarheid of rechten.
• Tools en kennisbanken, zoals API's, databases of integraties die van invloed kunnen zijn op het vermogen van de agent om te handelen.
• Lopende taken en afhankelijkheden waarbij externe partijen of systemen betrokken zijn en die de volgende stappen van de agent beïnvloeden.

We beschrijven een veelvoorkomend patroon om deze informatie gedurende de hele levenscyclus van de relatie tussen een agent en een gebruiker betrouwbaar te onderhouden.

Oplossingscomponenten

Overzicht 

In deze sectie behandelen we de architectuurcomponenten en implementatiedetails die nodig zijn om complexe externe agents succesvol te integreren. De kern van deze aanpak is de mogelijkheid om een willekeurige, maar unieke identifier die een sessie vertegenwoordigt, via alle services te proxien. Voor ElevenLabs Agents die aangepaste LLM's gebruiken, kun je dit eenvoudig doen door de vereiste identifier door te geven als een LLM-parameter in het extra body-object dat wordt doorgegeven als onderdeel van de conversation overrides bij het starten van het gesprek. Hierdoor kan de identifier via de ElevenLabs Agent van de gebruiker naar de externe agent stromen. 

Let op de stateful proxy achter de aangepaste LLM. Deze service, die doorgaans niet aanwezig is, stelt ons in staat individuele generatieverzoeken te koppelen aan willekeurige identifiers die verbindingen met de externe agent vertegenwoordigen. De externe agentontwikkelaars zijn eigenaar van de implementatie van deze service. In de eenvoudigste vorm beheert de proxy verbindingen die worden vertegenwoordigd door unieke identifiers die zijn gekoppeld aan ElevenLabs-gesprekken of call SID's (voor telefonie). Geavanceerdere versies kunnen echter een hiërarchie toevoegen aan de koppeling van gesprekken met complexere klantrelaties die meerdere interacties omvatten.

In deze geavanceerdere configuraties beheert de proxy aanvullende identifiers die verder gaan dan één verzoek dat aan één downstreamsessie is gekoppeld. In plaats van dat elke identifier slechts één gesprek of call SID vertegenwoordigt, kan de proxy één identifier koppelen aan meerdere gerelateerde interacties. Hierdoor kan het systeem klantreizen volgen die verschillende kanalen doorlopen, historische context hergebruiken en meerdere interacties tegelijk coördineren. Eén koppeling kan bijvoorbeeld meerdere webchatsessies, een vervolgtelefoongesprek en een interne supportworkflow groeperen onder dezelfde logische klantidentifier. De proxy kan verzoeken vervolgens op basis van eenvoudige regels naar de juiste identifier leiden, terwijl een uniforme status achter de aangepaste LLM behouden blijft. Dit maakt flexibelere en blijvende interacties in meerdere stappen mogelijk die door de externe agent worden beheerd.

Berichtuitwisseling

Naast het succesvol koppelen van generatieverzoeken aan entiteiten van een hogere orde, kan de stateful proxy via API-verzoeken bidirectionele berichtuitwisseling ondersteunen met externe bronnen, zoals de applicatiefrontend of een aparte routerservice. In applicaties waar dit nodig is, hoeven ElevenLabs Agents niet te weten dat berichten worden doorgegeven aan andere services.  

Het is bijvoorbeeld vaak nuttig dat externe agents zicht hebben op lopende spraakactiviteit, zodat ze kunnen bepalen of de gebruiker spreekt, hoe lang al en of ze preventief actie moeten ondernemen. Deze inzichten kunnen rechtstreeks worden afgeleid en benut door verwerkte scores voor voice activity detection (VAD), die ElevenLabs Agents leveren als client events die via de websocket van het gesprek worden ontvangen, door te geven. Wanneer de clientapplicatie scores van ElevenLabs ontvangt, kan deze VAD-clientevents op basis van de vereisten van de applicatie doorsturen naar de stateful proxy, waarbij de willekeurige sessieidentifier in het bericht wordt opgenomen. De stateful proxy moet logica voor het koppelen van verzoeken implementeren die de bestaande verbinding voor de sessie optimaal identificeert. 

Dit patroon kan worden uitgebreid voor elk event van de client, zolang dit als een JSON-blok kan worden uitgedrukt. Het is echter ook nuttig om events beschikbaar te maken die van de agent zelf afkomstig zijn. Een veelvoorkomend voorbeeld is de levenscyclus van tool calls of kennisbankquery's die bewerkingen op externe systemen vertegenwoordigen. Deze mechanismen zijn fundamenteel voor de agents die organisaties tegenwoordig bouwen.

Wanneer externe agents via een aangepaste LLM worden geïntegreerd, worden de functies van ElevenLabs voor tool calling en retrieval augmented generation (RAG) vaak omzeild ten gunste van de eigen implementatie van de externe agent. Daardoor ligt het eigenaarschap van deze componenten volledig bij de externe agentprovider. Applicaties profiteren nog steeds van inzicht in toolactiviteit, omdat ze daarmee de voortgang van de agent kunnen tonen en de ervaring van de eindgebruiker daarop kunnen aanpassen.

Om dit inzicht te bieden, verstuurt de externe agent berichten wanneer tools worden aangeroepen, zowel voor verzoeken als reacties. De stateful proxy stuurt deze berichten door naar clientapplicaties, die ze via een speciale berichtenwachtrij verwerken. Dit weerspiegelt de mechanismen die worden gebruikt door de client events van ElevenLabs Agents en zorgt ervoor dat applicaties kunnen bijhouden wanneer de agent gegevens uit een extern systeem leest of dit wijzigt.

Door deze kerncomponenten te gebruiken en bidirectionele berichtuitwisseling tussen de proxy en de clientapplicatie mogelijk te maken, kunnen klanten externe agents integreren in ElevenLabs Agents om uitsluitend de geboden spraakorchestratie te gebruiken, terwijl ze eigenaar blijven van alle onderdelen van de LLM-orchestratie. 

De koppeling met status

Om complexe externe agents effectief te ondersteunen, is een duidelijke verdeling van verantwoordelijkheden tussen de proxy en de agent nodig, vooral als het gaat om statusbeheer. In dit model is de proxy verantwoordelijk voor het bijhouden van een tabel met relevante interacties, gegroepeerd volgens de behoeften van de applicatie, en voor het routeren van berichten tussen zichzelf en de agent met logica die stateless blijft. De externe agent moet op zijn beurt alle essentiële interne en externe gegevens verwerken en opslaan die bijdragen aan de algehele status.

Hoewel het versoepelen van deze scheiding het herwerk van een bestaande oplossing verder kan verminderen, leidt het aanhouden van een strikte grens doorgaans tot robuustere en beter schaalbare resultaten naarmate de verzameling taken van de agent groeit.

Vooruitblik

Naarmate organisaties meer ervaring opdoen met het gebruik van agents met en zonder spraak, verwachten we dat patronen voor de informatie die deze agents nodig hebben, duidelijker worden. Zo kunnen we de ontwikkeling en het eigenaarschap van de in dit artikel beschreven services vereenvoudigen. Ondertussen blijven we bouwen voor de vereisten die al naar voren zijn gekomen. Ons Forward Deployed Engineering-team werkt nauw samen met klanten om deze opkomende behoeften te vertalen naar concrete productmogelijkheden en ervoor te zorgen dat onze oplossingen gelijke tred houden met implementaties in de praktijk.

Werk je al met een bestaande agent en wil je spraak inschakelen met ElevenLabs Agents terwijl je eigenaar blijft van je LLM-orchestratie? Probeer dan deze aanpak en laat ons weten wat je ervan vindt!