Intégration d'agents externes avec l'orchestration vocale des Agents ElevenLabs

Les orchestrateurs d’agents de pointe sont de plus en plus capables de gérer des tâches complexes et d’opérer sur l’ensemble des outils d’entreprise. Cela exige une gestion rigoureuse de l’état de l’application, de la conversation et du système. Pour les modalités autres que la voix, des schémas courants ont émergé sous l’appellation ingénierie du contexte, qui vise à établir des pratiques cohérentes autour du prompt système d’un agent au fil d’une interaction. L’intégration de la voix ajoute non seulement une couche d’état supplémentaire pour gérer les composants de l’interaction vocale, mais permet aussi, idéalement, de réutiliser des éléments issus de travaux antérieurs sur d’autres modalités. 

Dans cet article, nous expliquons comment ElevenLabs Agents prend en charge les agents externes et les schémas permettant un contrôle précis de leur intégration. Ces mécanismes permettent aux clients de tirer parti de l’orchestration vocale d’ElevenLabs tout en conservant la pleine maîtrise de leur orchestration globale.

Composants clés

ElevenLabs Agents

Dans sa forme la plus simple, un agent ElevenLabs est accessible via un client WebSocket. Les informations représentant les événements du serveur et du client dans la conversation transitent vers et depuis l’agent sous forme d’objets JSON. Lorsque l’agent transcrit la parole de l’utilisateur, il déclenche immédiatement une requête de génération. Nous prenons en charge la plupart des principaux fournisseurs de modèles et permettons aux clients d’utiliser leur propre LLM personnalisé. Lorsqu’ils utilisent un orchestrateur plus complexe, composé d’agents, pour répondre aux requêtes de génération derrière le LLM personnalisé, les clients doivent s’assurer qu’il prend en charge l’API Chat Completions ou Responses d’OpenAI. Heureusement, cette spécification de format d’API est facilement prise en charge par les principaux frameworks de création d’agents, notamment CrewAI, LangChain, LangGraph, HayStack et LlamaIndex. 

Une fois intégrés, ces agents doivent souvent pouvoir lire et mettre à jour leur état interne et externe à tout moment, indépendamment de l’orchestrateur vocal qui les sous-tend. Une gestion efficace garantit la cohérence avec les agents existants uniquement textuels. 

Gestion de l’état

Par définition, les données qu’un agent doit suivre pour évoluer efficacement dans son environnement dépendent fortement de la tâche. Pour les agents ElevenLabs alimentés par un agent externe, il est utile de maintenir l’état dans რამდენიმე catégories clairement définies.

L’état interne régit la dynamique de la conversation. Parmi les éléments suivis dans le cadre de l’état interne de l’agent figurent :

• Le flux conversationnel en cours, y compris l’activité vocale, les interruptions et l’identification de l’interlocuteur actif.
• Des informations propres à l’application issues de l’analyse des transcriptions en temps réel, telles que les intentions, entités ou sentiments détectés.
• La trace de raisonnement, incluant les réflexions intermédiaires, les hypothèses et les tentatives précédentes de génération d’une solution.
• Les paramètres de configuration et d’exploitation, tels que ses objectifs actifs, son mode de fonctionnement et toute contrainte temporaire guidant son comportement pendant l’interaction.

L’état externe, quant à lui, porte principalement sur les systèmes et les personnes pertinents avec lesquels l’agent interagit ou sur lesquels il exerce une influence. Parmi les éléments suivis dans le cadre de l’état externe de l’agent figurent :

• L’état des autres utilisateurs ou systèmes avec lesquels il interagit, comme leurs objectifs actuels, leur disponibilité ou leurs autorisations.
• Les outils et bases de connaissances, par exemple les API, les bases de données ou les intégrations susceptibles d’influer sur la capacité d’action de l’agent.
• Les tâches en cours et les dépendances impliquant des acteurs ou systèmes externes qui influencent les prochaines étapes de l’agent.

Nous présentons un schéma courant pour maintenir ces informations de manière fiable tout au long de la relation entre un agent et un utilisateur.

Composants de la solution

Vue d’ensemble 

Dans cette section, nous abordons les composants d’architecture et les détails d’implémentation nécessaires à l’intégration réussie d’agents externes complexes. Au cœur de cette approche se trouve la capacité à transmettre un identifiant arbitraire, mais unique, représentant une session entre tous les services. Pour les agents ElevenLabs utilisant des LLM personnalisés, il suffit de transmettre l’identifiant requis en tant que paramètre LLM dans l’objet extra body transmis dans le cadre des remplacements de conversation lors de l’initialisation de l’appel. L’identifiant peut ainsi circuler depuis l’utilisateur, à travers l’agent ElevenLabs, jusqu’à l’agent externe. 

Remarquez le proxy avec état derrière le LLM personnalisé. Ce service, qui n’est généralement pas présent, permet d’associer les requêtes de génération individuelles à des identifiants arbitraires représentant des connexions avec l’agent externe. La responsabilité de l’implémentation de ce service incombe aux développeurs de l’agent externe. Dans sa forme la plus simple, le proxy gère les connexions représentées par des identifiants uniques associés aux conversations ElevenLabs ou aux SID d’appels, pour la téléphonie. Les versions plus avancées peuvent introduire une hiérarchie dans l’association des conversations avec des relations client plus complexes couvrant plusieurs interactions.

Dans ces configurations plus avancées, le proxy conserve des identifiants supplémentaires qui vont au-delà d’une requête unique liée à une seule session en aval. Au lieu de représenter une seule conversation ou un seul SID d’appel, chaque identifiant peut être associé à plusieurs interactions liées. Le système peut ainsi suivre des parcours clients sur plusieurs canaux, réutiliser le contexte historique et coordonner plusieurs interactions simultanément. Par exemple, une même association peut regrouper plusieurs sessions de chat web, un appel vocal de suivi et un processus interne de support sous un même identifiant client logique. Le proxy peut alors acheminer les requêtes vers le bon identifiant selon des règles simples, tout en préservant un état unifié derrière le LLM personnalisé. L’agent externe peut ainsi gérer des interactions en plusieurs étapes, plus flexibles et persistantes.

Transmission de messages

Au-delà de l’association des requêtes de génération à des entités de niveau supérieur, le proxy avec état peut prendre en charge la transmission bidirectionnelle de messages vers des sources externes, telles que le frontend de l’application ou un service de routage distinct, via des requêtes API. Dans les applications qui l’exigent, les agents ElevenLabs n’ont pas besoin de savoir que des messages sont transmis à d’autres services.  

Par exemple, il est souvent utile que les agents externes aient une visibilité sur l’activité vocale en cours afin de déterminer si l’utilisateur parle, pendant combien de temps et s’ils doivent agir de manière préventive. Ces informations peuvent être directement obtenues et exploitées en transmettant les scores traités de détection de l’activité vocale (VAD) fournis par ElevenLabs Agents sous forme d’événements client reçus via le WebSocket de la conversation. Lorsqu’elle reçoit les scores d’ElevenLabs, l’application cliente peut transmettre les événements client VAD au proxy avec état selon les besoins de l’application, en veillant à inclure l’identifiant de session arbitraire dans le message. Le proxy avec état doit implémenter une logique de correspondance des requêtes capable d’identifier de façon optimale la connexion existante pour la session. 

Ce schéma peut être étendu pour prendre en charge tout événement provenant du client, à condition qu’il puisse être exprimé sous forme de bloc JSON. Il est toutefois également utile d’exposer les événements provenant de l’agent lui-même. Un exemple courant concerne le cycle de vie des appels d’outils ou des requêtes vers une base de connaissances, qui représentent des opérations sur des systèmes externes. Ces mécanismes sont fondamentaux pour les agents que les entreprises développent aujourd’hui.

Lors de l’intégration d’agents externes via un LLM personnalisé, les fonctionnalités d’ElevenLabs d’appel d’outils et de génération augmentée par récupération (RAG) sont souvent contournées au profit de l’implémentation propre à l’agent externe. La responsabilité de ces composants revient donc entièrement au fournisseur de l’agent externe. Les applications bénéficient toujours d’une visibilité sur l’activité des outils, ce qui leur permet de présenter la progression de l’agent et d’adapter l’expérience de l’utilisateur final en conséquence.

Pour offrir cette visibilité, l’agent externe émet des messages chaque fois que des outils sont appelés, tant pour les requêtes que pour les réponses. Ces messages sont transmis par le proxy avec état aux applications clientes, qui les traitent via une file d’attente de messages dédiée. Ce mécanisme reprend celui des événements client d’ElevenLabs Agents et permet aux applications de suivre les moments où l’agent lit un système externe ou le modifie.

Ainsi, l’utilisation de ces composants clés et l’activation de la transmission bidirectionnelle de messages entre le proxy et l’application cliente permettent aux clients d’intégrer des agents externes à ElevenLabs Agents afin d’utiliser strictement son orchestration vocale, tout en conservant la maîtrise de toutes les composantes de l’orchestration du LLM. 

Le lien avec l’état

La prise en charge efficace d’agents externes complexes exige une répartition claire des responsabilités entre le proxy et l’agent, en particulier pour la gestion de l’état. Dans ce modèle, le proxy est chargé de maintenir une table des interactions pertinentes, regroupées selon les besoins de l’application, et d’acheminer les messages entre lui-même et l’agent au moyen d’une logique sans état. L’agent externe doit, quant à lui, gérer et stocker toutes les informations internes et externes substantielles qui contribuent à l’état global.

Si assouplir cette séparation peut réduire davantage le travail de reprise d’une solution existante, maintenir une frontière stricte produit généralement des résultats plus robustes et évolutifs à mesure que l’ensemble des tâches de l’agent s’élargit.

Perspectives

À mesure que les organisations gagnent en maturité dans l’adoption d’agents vocaux et non vocaux, nous nous attendons à ce que les schémas relatifs aux informations dont ces agents ont besoin se précisent, afin de simplifier le développement et la responsabilité des services décrits dans cet article. Entre-temps, nous continuons à répondre aux exigences déjà apparues. Notre équipe Forward Deployed Engineering travaille en étroite collaboration avec les clients pour transformer ces besoins émergents en capacités produit concrètes et garantir que nos solutions évoluent au rythme des déploiements réels.

Si vous travaillez déjà avec un agent existant et cherchez à activer la voix avec ElevenLabs Agents tout en conservant la maîtrise de l’orchestration de votre LLM, essayez cette approche et partagez-nous votre avis.