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’interagir avec 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 pratiques courantes ont émergé sous le terme générique de ingénierie du contexte, dont l’objectif est d’établir des pratiques cohérentes autour du prompt système d’un agent à mesure que l’interaction progresse. L’intégration de la voix ajoute non seulement une couche d’état supplémentaire pour gérer les composantes de l’interaction vocale, mais permet idéalement aussi de réutiliser les é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 modèles 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 principaux

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 au sein de la conversation transitent de et vers 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 (des 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 la plupart des principaux frameworks de création d’agents (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...). 

Une fois intégrés, ces agents doivent souvent pouvoir lire et mettre à jour leur état interne et externe à tout moment, quel que soit l’orchestrateur vocal utilisé. Une gestion efficace garantit la cohérence avec les agents existants basés uniquement sur le texte. 

Gestion de l’état

Par définition, les données qu’un agent doit suivre pour naviguer efficacement dans son environnement dépendent fortement de sa tâche. Pour les agents ElevenLabs alimentés par un agent externe, il est utile de conserver l’état dans quelques catégories bien définies.

L’état interne régit la dynamique de la conversation. Les éléments suivis dans l’état interne de l’agent comprennent notamment :

• Le déroulement actuel de la conversation, y compris l’activité vocale, les interruptions et l’identification de l’interlocuteur actif.
• Les informations propres à l’application issues de l’analyse de la transcription en temps réel, telles que les intentions, entités ou sentiments détectés.
• La trace de raisonnement, y compris 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 de fonctionnement, tels que ses objectifs actifs, son mode de fonctionnement et les éventuelles contraintes temporaires guidant son comportement pendant l’interaction.

L’état externe, quant à lui, concerne principalement les systèmes et personnes pertinents avec lesquels l’agent interagit ou sur lesquels il exerce une influence. Les éléments suivis dans l’état externe de l’agent comprennent notamment :

• L’état des autres utilisateurs ou systèmes avec lesquels il interagit, notamment leurs objectifs actuels, leur disponibilité ou leurs autorisations.
• Les outils et bases de connaissances, par exemple les API, bases de données ou intégrations susceptibles d’influencer 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 modèle courant permettant de préserver 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 présentons les composants d’architecture et les détails d’implémentation nécessaires pour intégrer avec succès des agents externes complexes. Au cœur de cette approche se trouve la capacité à transmettre, entre tous les services, un identifiant arbitraire mais unique représentant une session. Pour les agents ElevenLabs utilisant des LLM personnalisés, il suffit de transmettre l’identifiant requis en tant que paramètre du LLM dans l’objet extra body transmis dans le cadre des surcharges de conversation lors de l’initialisation de l’appel. L’identifiant peut ainsi circuler de l’utilisateur jusqu’à l’agent externe en passant par l’agent ElevenLabs. 

Remarquez le proxy avec état derrière le LLM personnalisé. Ce service, qui n’est généralement pas présent, permet d’associer des requêtes de génération individuelles à des identifiants arbitraires représentant les connexions avec l’agent externe. Les développeurs de l’agent externe sont responsables de l’implémentation de ce service. Dans sa forme la plus simple, le proxy gère des connexions représentées par des identifiants uniques associés à des conversations ElevenLabs ou à des SID d’appel (pour la téléphonie). Des versions plus avancées peuvent introduire une hiérarchie dans l’association des conversations à des relations clients 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 que chaque identifiant ne représente qu’une conversation ou un SID d’appel, le proxy peut associer un même identifiant à 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 d’assistance sous un même identifiant client logique. Le proxy peut alors acheminer les requêtes vers l’identifiant approprié selon des règles simples, tout en préservant un état unifié derrière le LLM personnalisé. Cela permet à l’agent externe de 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. Lorsque cela est nécessaire, 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, depuis 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 d’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 des 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 arbitraire de la session dans le message. Le proxy avec état doit implémenter une logique d’association des requêtes permettant d’identifier de manière optimale la connexion existante pour la session. 

Ce modèle 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 de base de connaissances qui représentent des opérations sur des systèmes externes. Ces mécanismes sont essentiels aux 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 de tool calling 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 incombe donc entièrement au fournisseur de l’agent externe. Les applications bénéficient néanmoins d’une visibilité sur l’activité des outils, ce qui leur permet d’afficher la progression de l’agent et d’adapter l’expérience utilisateur finale en conséquence.

Pour offrir cette visibilité, l’agent externe émet des messages à chaque appel d’outil, aussi bien pour les requêtes que pour les réponses. Le proxy avec état transmet ces messages aux applications clientes, qui les traitent via une file de messages dédiée. Ce mécanisme reflète celui des événements client d’ElevenLabs Agents et permet aux applications de suivre les moments où l’agent lit ou modifie un système externe.

Ainsi, l’utilisation de ces composants principaux 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 exclusivement son orchestration vocale, tout en conservant la maîtrise de l’ensemble de l’orchestration du LLM. 

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, particulièrement en matière de 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 à l’aide d’une logique sans état. L’agent externe doit quant à lui gérer et stocker toutes les informations internes et externes essentielles qui contribuent à l’état global.

Bien qu’assouplir cette séparation puisse réduire davantage le travail de refonte d’une solution existante, le maintien d’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 modèles liés aux informations requises par ces agents se précisent, ce qui simplifiera le développement et la responsabilité des services décrits dans cet article. En attendant, nous continuons de répondre aux exigences déjà identifiées. Notre équipe Forward Deployed Engineering collabore étroitement avec les clients pour transformer ces besoins émergents en capacités produit concrètes et veiller à ce que nos solutions évoluent au même rythme que les déploiements réels.

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