Décryptage du moteur d’orchestration d’ElevenAgent

ElevenAgents s'appuient sur un moteur d'orchestration à faible latence, conçu pour les conversations en temps réel, qui ajoute moins de 100 ms de surcharge. Cette architecture associe le meilleur de la recherche d'ElevenLabs à des LLM de pointe de fournisseurs tels qu'OpenAI, Google et Anthropic, ainsi qu'à une sélection de modèles open source hébergés par ElevenLabs. En utilisant plusieurs modèles à différentes étapes du pipeline de réponse, l'agent assure des conversations à la fois très réactives et sensibles au contexte. En tirant dynamiquement parti des atouts complémentaires de chaque modèle, nous obtenons des performances fiables et évolutives pour de nombreuses tâches d'entreprise et situations conversationnelles, tout en optimisant l'équilibre entre intelligence, rapidité et coût.

Dans cet article, nous expliquons comment ces modèles fonctionnent ensemble pour fournir les capacités essentielles dont les agents ont besoin dans des environnements complexes, et plus précisément quel modèle voit quels tokens, et à quel moment. Au cœur de cette architecture se trouve la gestion de l'historique des conversations aux différents stades de l'interaction. Nous verrons comment et où cet historique est partagé afin de clarifier son rôle dans l'orchestration des workflows indépendants comme multi-agents.

Agent indépendant 

Commençons par examiner l'agent indépendant et ses composants essentiels. Un agent minimalement utile peut être considéré comme disposant d'un prompt système, d'un accès à plusieurs outils et à une base de connaissances. Les clients devraient privilégier les agents indépendants aux workflows lorsque leur cas d'usage requiert peu de vérifications d'une séquence stricte d'étapes, ou lorsqu'il est important d'éviter les silos de connaissances entre les agents. Ces silos apparaissent lorsque certains outils, documents ou éléments du contexte historique sont accessibles à certains sous-agents, mais pas à d'autres. Ils sont inhérents aux workflows multi-agents et impliquent un compromis entre flexibilité et déterminisme. 

Pour les agents indépendants d'ElevenLabs, il est important de comprendre comment ils :

• Construisent des requêtes de génération efficaces
• Récupèrent et intègrent des documents pertinents
• Génèrent et exécutent des appels d'outils pour éclairer les réponses de l'agent
• Produisent des résultats à des fins d'évaluation et de collecte de données

Construire le contexte conversationnel 

Une conversation entre un client et un agent ElevenLabs se compose d'une série de tours, chacun correspondant à un échange de messages entre les deux parties. Cette liste alternant messages de l'agent et de l'utilisateur constitue le point de départ de la construction du contexte conversationnel. À chaque tour, le LLM sous-jacent reçoit des requêtes de génération contenant une série alternée de messages de l'agent et de l'utilisateur, qui comporte un message de plus qu'au tour précédent. Cette série de messages est naturellement précédée d'un unique message système représentant le prompt système de l'agent.

L'orchestrateur ElevenLabs réduit la latence perçue du LLM en prédisant le moment où un utilisateur a fini de parler. Dans certains cas, cela peut entraîner plusieurs requêtes de génération au LLM avec le même contexte conversationnel au cours d'un même tour.  Si l'orchestration optimise la vitesse de réponse des agents, la qualité des réponses dépend tout autant de la manière dont les connaissances sont accessibles. À mesure que les clients progressent, ils fondent généralement les réponses de leurs agents sur une combinaison de documentation propriétaire et de contenu public. Depuis plusieurs années, la génération augmentée par récupération (RAG) constitue l'approche de référence à cette fin. Bases de connaissances ElevenAgents s'appuient sur le RAG grâce à une architecture optimisée à plusieurs modèles, détaillée dans un article précédent. Cela permet une récupération fiable des documents, même lorsque la dernière intervention de l'utilisateur est une relance, l'acquiescement à une clarification ou ne contient pas de question explicite.

La récupération n'est toutefois qu'une des façons dont les agents interagissent avec des systèmes externes.

Exécuter des actions et récupérer des informations grâce aux outils

Les agents ElevenLabs peuvent effectuer des actions concrètes et récupérer des informations en temps réel au cours d'une conversation grâce à un système d'outils flexible. Cette capacité implique une considération importante de conception : chaque outil activé augmente la taille du prompt sérialisé, car son nom, sa description et son schéma de paramètres s'ajoutent au prompt système et à l'historique de conversation. À mesure que des outils sont ajoutés, la charge de raisonnement imposée au modèle pour appeler la bonne séquence d'outils augmente également. Dans l'Agent Builder, la description de l'outil précise sa fonction et les champs qu'il renvoie. C'est cette information que le modèle de langage utilise pour comprendre le contexte de son utilisation. Une fois l'outil défini, les conditions précises de son appel relèvent du prompt système de l'agent. Par exemple :

• Description de l'outil lookup_order : « Récupère les détails d'une commande client à partir de son ID. Renvoie le statut de la commande, les articles achetés, l'adresse de livraison et le numéro de suivi. »
• Instruction du prompt système : « Après avoir vérifié l'identité du client, appelez l'outil lookup_order pour récupérer les détails de sa commande. »

Cette séparation des responsabilités permet de réutiliser les définitions d'outils entre les agents, tout en laissant le prompt système de chaque agent contrôler le moment précis où un outil est appelé. Pour aider les clients à concevoir efficacement ces prompts système, nous proposons des conseils plus détaillés dans notre Guide de prompting. Dans ce cadre, plusieurs types d'outils peuvent être définis, notamment :

• Des outils webhook qui appellent des API externes.
• Des outils client qui envoient des requêtes d'outils sous forme d'événements via le websocket de conversation.
• Des outils système pour des actions intégrées, telles que les transferts d'appel.
• Des outils MCP qui se connectent à des serveurs Model Context Protocol.

Lorsqu'un agent décide d'utiliser un outil, il extrait de la conversation les informations nécessaires et envoie une requête pour l'exécuter. Une fois que l'outil renvoie un résultat, celui-ci est ajouté à la conversation afin que le modèle puisse naturellement s'y référer dans sa réponse suivante. Si nécessaire, la sortie de l'outil peut également mettre à jour les informations stockées par l'agent sous la forme d'une variable dynamique. Ces informations sont conservées sous forme de paires clé-valeur simples, extraites de la réponse de l'outil à l'aide de mappages prédéfinis. Une fois définies, ces variables peuvent alimenter l'agent via son prompt système, les paramètres de futurs outils et les conditions du workflow. Cette boucle de rétroaction donne aux agents une forme de mémoire de travail qui évolue au fil des interactions.

Si cela décrit comment les outils s'intègrent au raisonnement de l'agent, le moment de leur exécution peut également être configuré. Les outils peuvent s'exécuter selon trois modes, chacun adapté à un besoin conversationnel différent. En mode immédiat, l'outil s'exécute dès que le LLM le demande. C'est le mode par défaut pour les recherches rapides, lorsque les utilisateurs attendent une réponse quasi instantanée, par exemple pour vérifier le statut d'une commande. Associé à la parole avant outil, l'agent génère d'abord un bref accusé de réception, tel que « Je vais vérifier cela pour vous », et le renvoie à l'utilisateur pendant que l'outil s'exécute en parallèle, réduisant ainsi les silences. Pour les outils plus lents, la plateforme allonge automatiquement ces messages d'attente en fonction du temps d'attente prévu. À l'inverse, le mode de parole après outil retarde l'exécution jusqu'à ce que l'agent ait fini de parler. Il est essentiel pour les actions ayant des conséquences concrètes, comme transférer un appel, terminer une session ou soumettre un paiement. L'utilisateur entend le contexte complet, par exemple « Je vais maintenant vous transférer au service de facturation », et peut interrompre l'agent avant que l'action ne soit effectuée. Le mode asynchrone exécute l'outil entièrement en arrière-plan sans interrompre la conversation. Ce mode convient particulièrement aux opérations sans retour, comme l'envoi d'un e-mail, le déclenchement d'un workflow externe ou la journalisation de données, lorsque l'agent n'a pas besoin de mentionner le résultat dans sa réponse.

L'exécution et l'orchestration étant en place, l'étape suivante consiste à comprendre comment mesurer les performances.

Mesurer les performances

Une fois un appel avec un Agent terminé, les clients peuvent vouloir en extraire certains éléments pour les analyser et les stocker, ou déterminer si l'appel a été réussi. C'est là que la collecte de données et les critères d'évaluation interviennent. La collecte de données permet d'extraire des informations structurées d'une transcription d'appel pour les analyser et les agréger ultérieurement. Les clients exportent souvent ces résultats vers leur plateforme de données d'entreprise pour le reporting ou des workflows d'enrichissement. Par exemple, un agent de développement commercial peut extraire automatiquement les informations d'un prospect au cours d'une conversation afin de créer ou mettre à jour un lead dans le système de gestion de la relation client (CRM). Les critères d'évaluation, quant à eux, déterminent si un appel est considéré comme réussi. Si tous les critères configurés sont remplis, l'appel est marqué comme réussi ; dans le cas contraire, il est signalé comme un échec. Cela garantit que les conversations respectent systématiquement des normes définies de qualité et d'intégrité, tout en fournissant un retour rapide. Une fois l'appel terminé et le webhook post-appel déclenché, l'agent traite la transcription finalisée, y compris toute exécution d'outil et les métadonnées, avec un LLM ainsi que tous les points de collecte de données et critères d'évaluation configurés. Le modèle utilise ce prompt combiné pour déterminer si chaque critère d'évaluation est rempli et extraire les points de données spécifiés pour une analyse ultérieure. Comme le LLM interprète directement ces configurations dans son prompt d'entrée, il est important de les formater de façon claire et cohérente afin qu'il puisse les comprendre et les appliquer correctement. Nous recommandons donc les bonnes pratiques suivantes pour rédiger les descriptions des critères d'évaluation et de collecte de données.

Critères d'évaluation

1. Un objectif clair par critère : une phrase ou une puce courte vaut mieux que plusieurs objectifs dans un même critère. 
2. Observable et fondé sur la transcription : formulez l'objectif de sorte que la réussite ou l'échec puisse être déterminé à partir de la transcription (ce qui a été dit, ce que l'agent a fait, ce que l'utilisateur a demandé). Évitez les objectifs nécessitant un contexte externe dont le LLM ne dispose pas.
3. Résultats explicites de réussite, d'échec ou inconnus : le LLM sait déjà que l'objectif doit être atteint pour marquer un résultat comme réussi, ne doit pas l'être pour le marquer comme un échec, et qu'il doit être impossible à déterminer à partir de la transcription pour le marquer comme inconnu. L'objectif doit donc être formulé de manière à clairement distinguer « atteint » de « non atteint » ; s'il est ambigu, le modèle risque de tendre vers des classifications inconnues ou incorrectes.
4. Restez concis : plusieurs critères d'évaluation peuvent parfois être envoyés ensemble. Des critères trop longs peuvent donc ajouter du bruit et provoquer des hallucinations.
5. La langue compte : toute justification fournie par le LLM concernant le respect ou non d'un critère d'évaluation sera rédigée dans la même langue que la description du critère ; il est donc important d'en tenir compte.

Collecte de données

1. Décrivez précisément ce qu'il faut extraire : la description est le principal signal pour le LLM. Indiquez ce que signifie le champ, dans quelle situation il doit être renseigné et quoi faire en cas d'incertitude (par exemple, « Laissez la valeur null si le client n'a jamais indiqué de date préférée »).
2. Respectez le type attendu : la valeur fournie par le LLM correspondra toujours au type de données attribué au point de collecte (par exemple booléen, chaîne de caractères, entier, etc.). La description doit donc s'y aligner. Par exemple, vous pouvez utiliser « Extraire le nombre d'articles demandés » pour un entier et « Oui/non selon que le client a accepté l'offre » pour un booléen.
3. Utilisez des enums lorsque c'est possible : pour le type chaîne de caractères, si l'ensemble des valeurs est fixe, utilisez une enum dans le schéma ; elle contraint le modèle et réduit les sorties non valides.
4. Une cible d'extraction par élément : ne regroupez pas plusieurs faits sans lien dans la description d'un même élément ; répartissez-les dans des éléments distincts afin que chaque appel ait une cible d'extraction unique et claire.
5. Gardez des descriptions courtes : les descriptions peuvent compter quelques phrases ; nul besoin de longs paragraphes. La transcription est déjà présente dans le message utilisateur : le schéma et une brève description suffisent.

Actuellement, le LLM utilisé pour cette étape d'évaluation et d'extraction est fixé à un modèle à faible latence afin d'assurer un traitement rapide. Nous prévoyons prochainement d'introduire des options offrant davantage de flexibilité aux clients. 

Nous nous intéressons maintenant aux cas d'usage qui nécessitent une orchestration structurée, du déterminisme ou une spécialisation entre plusieurs rôles conversationnels, pour lesquels les clients peuvent utiliser les Workflows.

Workflows

Workflows offrent une interface visuelle pour concevoir des flux conversationnels complexes. Ils produisent l'objet logique utilisé par l'orchestrateur pour gérer plusieurs sous-agents, outils et transferts sous l'identifiant d'un agent indépendant. Les Workflows introduisent des composants supplémentaires à considérer, au-delà de ceux déjà décrits pour les agents indépendants, notamment la manière dont :

• Les prompts système et les objectifs conversationnels des sous-agents interagissent.
• Le parcours des différents points de transition du graphe est déterminé.

Objectifs conversationnels spécialisés

Les Workflows réutilisent les fonctionnalités des agents indépendants pour garantir un comportement cohérent tout au long d'une interaction. Cela inclut des éléments partagés, comme le prompt système de base, les outils principaux et les bases de connaissances globales qui doivent toujours être disponibles, quelle que soit la partie active du workflow. Le prompt système global définit généralement le contexte conversationnel général, le ton attendu, les contraintes de sécurité et les instructions propres à la marque ou au produit.

Sur cette base partagée, les Workflows introduisent des sous-agents spécialisés qui opèrent dans un graphe orienté. Chaque sous-agent reçoit un objectif précisément délimité et enrichit la configuration de base avec des instructions de prompt, outils et sources de connaissances supplémentaires, pertinents uniquement pour son rôle. Au lieu de redéfinir toute la configuration conversationnelle, les sous-agents ajoutent leur intention à l'agent de base grâce à la composition de prompts et à une extension sélective du contexte. Si l'historique de conversation est conservé lors des transitions entre sous-agents afin d'assurer la continuité, chaque sous-agent opère avec une vue volontairement restreinte du système. Les bases de connaissances et les outils sont exposés de manière sélective, créant des silos clairs qui évitent les fuites entre responsabilités. Pour renforcer cette isolation, l'objet orchestrateur est reconstruit à chaque transition comme s'il s'agissait d'un agent indépendant. Cela garantit que l'état du prompt, la configuration et les capacités disponibles du sous-agent actif restent entièrement déterministes. Cette conception permet aux Workflows de conserver une cohérence globale tout en prenant en charge la spécialisation locale, pour un comportement prévisible, une séparation claire des responsabilités et un contrôle précis de l'application du contexte, des connaissances et des actions à chaque étape d'une interaction.

L'un des mécanismes essentiels qui rendent ce contrôle possible réside dans la gestion des transitions entre sous-agents.

Piloter les transitions de workflow avec des conditions LLM

Les Workflows progressent en parcourant un graphe orienté de sous-agents, dont les transitions entre nœuds sont contrôlées par des conditions explicites. Ces conditions déterminent quand le contrôle doit passer d'un sous-agent à un autre et permettent aux workflows de répondre aux entrées utilisateur, aux résultats des outils et aux variables dynamiques. Les conditions du graphe peuvent être déterministes ou évaluées par un LLM. Les conditions déterministes, telles que les transitions inconditionnelles, les vérifications fondées sur des expressions de variables dynamiques ou les conditions liées aux résultats d'outils, offrent de solides garanties sur le flux de contrôle et conviennent pour imposer une progression stricte dans un workflow. À l'inverse, les conditions fondées sur un LLM permettent une évaluation sémantique de critères en langage naturel, par exemple pour détecter l'intention de l'utilisateur ou reconnaître la fourniture d'une information précise.

Point important : les conditions LLM sont évaluées en dehors du prompt système de l'agent actif et n'influencent pas son comportement de génération. Elles sont plutôt évaluées en parallèle par l'orchestrateur, en fonction de l'état actuel de la conversation. Cette séparation garantit que la logique de transition ne contamine pas le prompt de l'agent ni n'affecte la génération des réponses, tout en permettant aux workflows de tirer parti du raisonnement des LLM pour un parcours flexible du graphe. En combinant conditions déterministes et conditions évaluées par un LLM, les workflows peuvent concilier prévisibilité et adaptabilité : des transitions déterministes lorsque l'exactitude est critique, et des transitions fondées sur un LLM lorsqu'une interprétation sémantique est requise.

Lorsqu'une conversation progresse vers une nouvelle étape, le système active une version de l'agent spécifiquement adaptée à cette étape. Chaque étape dispose de ses propres instructions ciblées et n'accède qu'aux connaissances et outils pertinents pour sa responsabilité. Par exemple, une étape de gestion des remboursements peut consulter les politiques de remboursement sans hériter d'un contexte sans rapport provenant de l'onboarding ou du triage. Le passage d'une étape à l'autre est régi par des conditions de transition explicites. Elles déterminent le moment où la responsabilité doit changer et permettent aux décisions de routage de se produire naturellement au fil de la conversation. Afin d'assurer la continuité, l'expérience utilisateur reste fluide lors des transitions : chaque étape hérite du contexte conversationnel pertinent sans exposer les mécanismes du transfert. Des garde-fous surveillent également les transitions afin d'éviter les cycles de routage improductifs et de garantir que le workflow reste stable et orienté vers son objectif.

Sécurité et sûreté

Pour les cas nécessitant des contrôles de sécurité et de sûreté renforcés, les clients peuvent s'appuyer sur des composants supplémentaires de l'orchestrateur. 

Garde-fous

Les Agents ElevenLabs mettent en œuvre des garde-fous de sécurité grâce à un système configurable de modération et d'alignement qui évalue les messages des utilisateurs et des agents en temps réel. Les contenus entrants sont classés dans plusieurs catégories de risques, notamment les contenus sexuels, la violence, le harcèlement, la haine et l'automutilation, chacune avec des seuils configurables indépendamment. Lorsqu'un garde-fou se déclenche, la conversation est immédiatement interrompue et le client est informé d'un motif d'échec clair. Les interactions non sûres sont ainsi bloquées tôt et de manière cohérente, sans reposer uniquement sur des mesures d'atténuation fondées sur les prompts. Les garde-fous opèrent hors de la logique de prompt de l'agent et fournissent une couche d'application fiable, qui ne peut être contournée par le comportement du modèle ou les entrées de l'utilisateur. Cette approche permet aux clients d'ajuster la sensibilité de sécurité à leur domaine tout en conservant une application déterministe à l'exécution.

Gestion des données conforme

Les interlocuteurs peuvent parfois communiquer à un agent des informations sensibles soumises à des exigences strictes de stockage et de traitement, comme des données médicales nécessitant un traitement conforme à la norme HIPAA. Pour prendre en charge ces cas d'usage, nous proposons le Zero Retention Mode (ZRM) au niveau de l'Agent ou du Workspace. Lorsqu'il est activé, toutes les données d'appel sont traitées uniquement en mémoire et ne sont jamais écrites dans un stockage persistant. Une fois l'appel et son traitement terminés, aucune information n'est conservée par ElevenLabs. Par conséquent, les transcriptions, enregistrements audio et résultats d'analyse ne sont pas disponibles dans le Dashboard des Agents, et cette politique s'applique aux systèmes destinés aux clients comme aux journaux internes. Bien que les données ne soient pas conservées, elles sont traitées pendant l'appel, et tous les webhooks post-appel configurés recevront les résultats. Les clients peuvent ainsi, si nécessaire, stocker les transcriptions ou résultats d'analyse dans leurs propres systèmes. 

Lorsque le ZRM est actif, nous veillons également à ce que les sous-traitants ne conservent pas les données en limitant les LLM disponibles aux fournisseurs ayant pris des engagements contractuels interdisant l'entraînement sur les données clients ou leur conservation ; cela inclut actuellement certains modèles éligibles. Les clients qui souhaitent utiliser un autre LLM dans le cadre du ZRM peuvent signer leur propre accord avec ce fournisseur et le configurer comme LLM personnalisé à l'aide de clés API couvertes par cet accord. Comme cette approche étend le traitement des données au-delà de notre périmètre de confiance standard, notre équipe Sécurité doit examiner et approuver manuellement le cas d'usage avant son activation. Si le ZRM garantit qu'ElevenLabs et ses sous-traitants ne conservent pas les données d'appel, les clients restent responsables de la conformité des outils externes ou webhooks utilisés par leur Agent avec les exigences applicables de conservation et de réglementation.

Perspectives

Dans cet article, nous avons examiné comment les Agents ElevenLabs gèrent le contexte conversationnel, les outils, l'évaluation et les workflows structurés afin de fournir des expériences fiables et en temps réel à grande échelle. À mesure que les clients déploient des agents dans des environnements toujours plus complexes, nous continuons d'étendre la flexibilité de notre moteur d'orchestration : modèles d'évaluation configurables, contrôles de transition plus riches et observabilité approfondie de la composition des prompts et de l'utilisation des tokens à chaque étape.

Notre équipe Forward Deployed Engineering travaille en étroite collaboration avec les clients pour garantir que ces capacités évoluent au même rythme que les déploiements réels. La prochaine génération d'Agents offrira encore davantage de transparence, de déterminisme et d'adaptabilité, sans compromettre les performances à faible latence qui rendent les conversations en temps réel possibles.