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 de fonctionner avec l'ensemble des outils d'entreprise. Cela nécessite une gestion rigoureuse de l'application, de la conversation et de l'état du système. Pour les modalités autres que la voix, des modèles communs ont émergé sous le terme générique de ingénierie contextuelle, qui vise à établir des pratiques cohérentes autour de l'invite système d'un agent au fur et à mesure que l'interaction progresse. L'intégration de la voix introduit non seulement une couche supplémentaire d'état pour gérer les composants de l'interaction vocale, mais permet idéalement aussi la réutilisation d'artefacts issus de travaux antérieurs sur d'autres modalités.

Dans cet article, nous expliquons comment les Agents ElevenLabs soutiennent les agents externes et les modèles qui permettent un contrôle précis de leur intégration. Ces mécanismes permettent aux clients de tirer parti de l'orchestration vocale de pointe d'ElevenLabs tout en conservant la pleine propriété de leur orchestration globale.

Composants principaux

Agents ElevenLabs

Dans sa forme la plus simple, un Agent ElevenLabs est accessible via un client Websocket. Les informations représentant les événements serveur et client dans la conversation passent vers et depuis l'agent sous forme d'objets JSON. Lorsque l'agent transcrit la parole de l'utilisateur, il déclenche avidement une demande de génération. Nous prenons en charge la plupart des principaux fournisseurs de modèles et permettons aux clients d'apporter leur propre LLM personnalisé. Lorsqu'un orchestrateur plus complexe (agents) est utilisé pour répondre aux demandes de génération derrière le LLM personnalisé, les clients doivent s'assurer qu'il prend en charge soit les API Chat Completions soit Responses d'OpenAI. Heureusement, cette spécification de formatage 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 nécessitent souvent la capacité de lire et de mettre à jour leur état interne et externe à tout moment, quel que soit l'orchestrateur vocal derrière lequel ils se trouvent. Gérer cela efficacement assure la cohérence avec les agents uniquement textuels existants.

Gestion des états

Par définition, les données qu'un agent doit suivre pour naviguer efficacement dans son environnement sont très spécifiques à la tâche. Pour les Agents ElevenLabs alimentés par un agent externe, il est utile de maintenir l'état dans quelques catégories bien définies.

L'état interne régit la dynamique de la conversation. Exemples d'éléments suivis dans le cadre de l'état interne de l'agent :

• Flux conversationnel actuel, y compris l'activité vocale, les interruptions et l'identification de l'interlocuteur actif.
• Informations spécifiques à l'application dérivées de l'analyse des transcriptions en temps réel, telles que les intentions détectées, les entités ou le sentiment.
• Trace de raisonnement, y compris les pensées intermédiaires, les hypothèses et les tentatives antérieures de génération de solution.
• Paramètres de configuration et opérationnels, tels que ses objectifs actifs, son mode de fonctionnement et toute contrainte temporaire guidant son comportement pendant l'interaction.

L'état externe, quant à lui, se concentre principalement sur les systèmes et les individus pertinents avec lesquels l'agent interagit ou qu'il influence. Exemples d'éléments suivis dans le cadre de l'état externe de l'agent :

• Statut des autres utilisateurs ou systèmes avec lesquels il interagit, tels que leurs objectifs actuels, leur disponibilité ou leurs autorisations.
• Outils et bases de connaissances, par exemple les API, les bases de données ou les intégrations qui peuvent affecter la capacité de l'agent à agir.
• Tâches en cours et dépendances impliquant des acteurs ou systèmes externes qui influencent les prochaines étapes de l'agent.

Nous décrivons un modèle commun pour maintenir de manière fiable ces informations tout au long du cycle de vie de la relation d'un agent avec un utilisateur.

Composants de la solution

Vue d'ensemble

Dans cette section, nous couvrons les composants d'architecture et les détails de mise en œuvre nécessaires pour intégrer avec succès des agents externes complexes. Au cœur de cette approche se trouve la capacité de proxy un identifiant arbitraire mais unique représentant une session à travers tous les services. Pour les Agents ElevenLabs utilisant des LLM personnalisés, cela peut être fait simplement en passant l'identifiant requis comme paramètre LLM dans l'objet corps supplémentaire passé dans le cadre des surcharges de conversation lors de l'initiation de l'appel. Cela permet à l'identifiant de circuler à travers l'Agent ElevenLabs de l'utilisateur jusqu'à l'agent externe.

Remarquez le proxy à état derrière le LLM personnalisé. Ce service, qui n'est généralement pas présent, nous permet de mapper des demandes de génération individuelles à des identifiants arbitraires représentant des connexions avec l'agent externe. La mise en œuvre de ce service est entre les mains des développeurs d'agents externes. Dans sa forme la plus simple, le proxy gère les connexions représentées par des identifiants uniques mappant aux conversations ElevenLabs ou aux SID d'appel (pour la téléphonie). Tandis que des versions plus avancées peuvent introduire une hiérarchie dans le mappage des conversations à des relations clients plus complexes qui s'étendent sur plusieurs interactions.

Dans ces configurations plus avancées, le proxy maintient des identifiants supplémentaires qui vont au-delà d'une seule demande liée à une seule session en aval. Au lieu que chaque identifiant représente uniquement une conversation ou un SID d'appel, le proxy peut associer un seul identifiant à plusieurs interactions connexes. Cela permet au système de suivre les parcours clients qui se déplacent à travers les canaux, de réutiliser le contexte historique et de coordonner plusieurs interactions à la fois. Par exemple, un seul mappage peut regrouper plusieurs sessions de chat web, un appel vocal de suivi et un flux de travail de support interne sous le même identifiant client logique. Le proxy peut alors acheminer les demandes vers le bon identifiant en fonction de règles simples tout en préservant un état unifié derrière le LLM personnalisé. Cela permet des interactions multi-étapes plus flexibles et persistantes gérées par l'agent externe.

Passage de messages

Au-delà du mappage réussi des demandes de génération à des entités de niveau supérieur, le proxy à état peut prendre en charge le passage bidirectionnel de messages vers des sources externes telles que le frontend de l'application ou un service de routage séparé via des requêtes API. Dans les applications où cela est nécessaire, les Agents ElevenLabs n'ont pas besoin d'être conscients que des messages sont transmis à d'autres services.

Par exemple, il est souvent utile pour les agents externes d'avoir une visibilité sur l'activité vocale en cours, afin qu'ils puissent déterminer si l'utilisateur parle, pendant combien de temps et s'ils doivent prendre des mesures de manière préventive. Ces informations peuvent être directement dérivées et mises en action en passant les scores de détection d'activité vocale (VAD) traités fournis par les Agents ElevenLabs comme événements client reçus via le websocket de conversation. Lors de la réception de scores d'ElevenLabs, l'application cliente peut transmettre les événements client VAD au proxy à état en fonction des exigences de l'application, en s'assurant qu'elle inclut l'identifiant de session arbitraire dans le message. Il est nécessaire que le proxy à état implémente une logique de mappage des requêtes qui identifie de manière optimale la connexion existante pour la session.

Ce modèle peut être étendu pour accueillir tout événement provenant du client, à condition qu'il puisse être exprimé sous forme de bloc JSON. Cependant, il est également utile d'exposer des événements qui proviennent de l'agent lui-même. Un exemple courant implique le cycle de vie des appels d'outils ou des requêtes de bases de connaissances qui représentent des opérations sur des systèmes externes. Ces mécanismes sont fondamentaux pour les agents que les entreprises construisent aujourd'hui.

Lors de l'intégration d'agents externes via un LLM personnalisé, les fonctionnalités d'appel d'outils et de génération augmentée par récupération (RAG) d'ElevenLabs sont souvent contournées au profit de la propre mise en œuvre de l'agent externe. En conséquence, la propriété de ces composants appartient entièrement au fournisseur de l'agent externe. Les applications bénéficient toujours de la visibilité sur l'activité des outils, car cela leur permet de faire apparaître les progrès de l'agent et de mettre à jour l'expérience utilisateur en conséquence.

Pour fournir cette visibilité, l'agent externe émet des messages chaque fois que des outils sont invoqués, à la fois pour les demandes et les réponses. Ces messages sont transmis par le proxy à état aux applications clientes, qui les gèrent via une file de messages dédiée. Cela reflète les mécanismes utilisés par les événements client des Agents ElevenLabs et garantit que les applications peuvent suivre quand l'agent lit ou modifie un système externe.

Ainsi, en utilisant ces composants principaux et en permettant le passage bidirectionnel de messages entre le proxy et l'application cliente, les clients peuvent intégrer des agents externes au sein des Agents ElevenLabs pour utiliser strictement l'orchestration vocale qu'ils fournissent tout en conservant la propriété de toutes les parties de l'orchestration LLM.

Lien avec l'état

Soutenir efficacement des agents externes complexes nécessite une division claire des responsabilités entre le proxy et l'agent, en particulier en ce qui concerne la gestion des états. Dans ce modèle, le proxy est responsable 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 en utilisant une logique qui reste sans état. En retour, l'agent externe doit gérer et stocker toutes les informations internes et externes substantielles qui contribuent à l'état global.

Bien que relâcher cette séparation puisse réduire davantage le retravail d'une solution existante, maintenir une frontière stricte conduit généralement à des résultats plus robustes et évolutifs à mesure que l'ensemble des tâches de l'agent s'accroît.

Regard vers l'avenir

À mesure que les organisations mûrissent dans leur adoption d'agents activés par la voix et non vocaux, nous nous attendons à ce que les modèles pour les informations requises par ces agents se cristallisent, nous permettant de simplifier le développement et la propriété des services décrits dans cet article. En attendant, nous continuons à construire pour les exigences qui ont déjà émergé. Notre équipe d'ingénierie déployée en avance collabore étroitement avec les clients pour traduire ces besoins émergents en capacités de produit concrètes et garantir que nos solutions évoluent en phase avec les déploiements réels.

Si vous travaillez déjà avec un agent existant et souhaitez activer la voix avec les Agents ElevenLabs tout en conservant la propriété de votre orchestration LLM, essayez cette approche et faites-nous part de vos impressions !