Décryptage du moteur d’orchestration d’ElevenAgent

ElevenAgents sont propulsés par un moteur d’orchestration à faible latence, conçu spécialement pour les conversations en temps réel, ajoutant moins de 100 ms de latence. Cette architecture combine le meilleur de la recherche ElevenLabs avec des LLM de pointe de fournisseurs comme OpenAI, Google et Anthropic, ainsi que des modèles open source sélectionnés et hébergés par ElevenLabs. En utilisant plusieurs modèles à différentes étapes de la chaîne de réponse, l’agent garantit des conversations à la fois très réactives et pertinentes. En exploitant dynamiquement les points forts de chaque modèle, nous assurons des performances fiables et évolutives sur une large gamme de tâches et de scénarios conversationnels en entreprise, tout en optimisant l’équilibre entre intelligence, rapidité et coût.

Dans cet article, nous expliquons comment ces modèles travaillent ensemble pour fournir les capacités essentielles dont les agents ont besoin dans des environnements complexes, et plus précisément, quels modèles voient quels tokens, et à quel moment. Au cœur de tout cela se trouve la gestion de l’historique de conversation à différents moments de l’interaction. Nous reviendrons sur la façon dont l’historique est partagé pour clarifier son rôle dans l’orchestration, aussi bien pour les workflows indépendants que multi-agents.

Agent indépendant

Commençons par explorer l’agent indépendant et ses composants clés. On peut considérer qu’un agent minimalement utile dispose d’un prompt système, d’un accès à plusieurs outils et d’une base de connaissances. Il est préférable de choisir des agents indépendants plutôt que des workflows lorsque le cas d’usage nécessite peu de vérifications d’une séquence stricte d’étapes ou lorsqu’il est important d’éviter les silos de connaissances entre agents. Les silos apparaissent lorsque certains outils, documents ou contextes historiques sont accessibles à certains sous-agents mais pas à d’autres. C’est inhérent aux workflows multi-agents et cela crée un compromis entre flexibilité et déterminisme.

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

• Formulent des requêtes de génération efficaces
• Récupèrent et intègrent les documents pertinents
• Génèrent et exécutent des appels d’outils pour enrichir les réponses
• Produisent des résultats pour l’évaluation et la collecte de données

Construction du contexte de conversation 

Une conversation entre un client et un agent ElevenLabs se compose d’une série d’échanges, chaque tour étant constitué de messages entre les deux parties. Cette alternance de messages sert de base pour construire le contexte de la conversation. À chaque tour, le LLM sous-jacent reçoit une requête de génération contenant une série de messages alternés agent/utilisateur, avec un message de plus que le tour précédent. Cette série commence toujours par un 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 quand l’utilisateur a fini de parler. Parfois, cela peut entraîner plusieurs requêtes de génération LLM avec le même contexte de conversation au sein d’un même tour. Si l’orchestration optimise la rapidité de réponse, la qualité dépend tout autant de la façon dont la connaissance est accessible. Au fil de leur utilisation, les clients ancrent généralement les réponses de leurs agents dans une combinaison de documentation interne et de contenu public. Depuis plusieurs années, la génération augmentée par récupération (RAG) est la méthode standard pour cela.Les bases de connaissances ElevenAgents s’appuient sur RAG avec une architecture multi-modèles optimisée, détaillée dans un article précédent. Cela permet de retrouver efficacement des documents même si la dernière intervention de l’utilisateur est un suivi, une confirmation ou ne contient pas de question explicite.

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

Prendre des actions et récupérer des informations via des outils

Les agents ElevenLabs peuvent agir dans le monde réel et récupérer des informations en direct pendant la conversation grâce à un système d’outils flexible. Cette puissance implique un point de vigilance : chaque outil activé augmente la taille du prompt sérialisé, car son nom, sa description et son schéma de paramètres sont inclus avec le prompt système et l’historique de conversation. Plus on ajoute d’outils, plus le modèle doit raisonner pour choisir la bonne séquence d’outils. Dans l’Agent Builder, la description de l’outil précise ce qu’il fait et les champs qu’il retourne. C’est cette information que le modèle de langage utilise pour comprendre le contexte d’utilisation. Une fois défini, les conditions spécifiques d’utilisation de l’outil doivent figurer dans le prompt système de l’agent. Par exemple :

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

Cette séparation permet de réutiliser les définitions d’outils entre agents, tout en laissant à chaque prompt système le contrôle du moment d’appel. Pour aider à concevoir ces prompts, nous proposons des conseils détaillés dans notre Guide du Prompt. Dans ce cadre, plusieurs types d’outils peuvent être définis, principalement :

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

Quand un agent décide d’utiliser un outil, il extrait les informations nécessaires de la conversation et envoie une requête pour l’exécuter. Une fois le résultat obtenu, il est ajouté à la conversation pour que le modèle puisse s’y référer naturellement dans sa prochaine réponse. Si besoin, la sortie de l’outil peut aussi mettre à jour les informations stockées par l’agent sous forme de variable dynamique. Ces informations sont stockées sous forme de paires clé-valeur simples, extraites de la réponse de l’outil via des mappings prédéfinis. Une fois définies, ces variables peuvent être réutilisées dans le prompt système, les paramètres d’outils futurs ou les conditions de workflow. Cette boucle de rétroaction donne à l’agent une 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 aussi être configuré. Les outils peuvent fonctionner selon trois modes d’exécution, adaptés à différents besoins conversationnels. En mode immédiat, l’outil s’exécute dès qu’il est demandé par le LLM. C’est le mode par défaut pour les recherches rapides où l’utilisateur attend une réponse quasi instantanée, comme vérifier le statut d’une commande. Avec un pré-message, l’agent génère d’abord une brève confirmation du type « Je vérifie ça pour vous » et l’envoie à l’utilisateur pendant que l’outil tourne en parallèle, limitant les silences. Pour les outils plus lents, la plateforme adapte automatiquement ces messages d’attente. Le mode post-outil, au contraire, retarde l’exécution jusqu’à ce que l’agent ait fini de parler. C’est essentiel pour les actions à conséquences réelles, comme transférer un appel, terminer une session ou valider un paiement. L’utilisateur entend le contexte complet, par exemple « Je vais vous transférer à la facturation », et peut interrompre avant l’action. Le mode asynchrone exécute l’outil entièrement en arrière-plan sans interrompre la conversation. Ce mode convient aux opérations « fire-and-forget » comme envoyer un email, déclencher un workflow externe ou enregistrer des données, où l’agent n’a pas besoin de mentionner le résultat dans sa réponse.

Une fois l’exécution et l’orchestration en place, il faut savoir comment mesurer la performance.

Mesurer la performance

Après un appel avec un Agent, les clients peuvent vouloir extraire certaines parties de l’appel pour analyse ou stockage, 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 entrent en jeu. La collecte de données permet d’extraire des informations structurées à partir de la transcription pour analyse ou agrégation. Les clients exportent souvent ces données vers leur data lakehouse pour le reporting ou l’enrichissement. Par exemple, un Agent commercial peut extraire automatiquement les informations d’un prospect pour créer ou mettre à jour une fiche dans le CRM. Les critères d’évaluation, eux, déterminent si un appel est considéré comme réussi. Si tous les critères sont remplis, l’appel est marqué comme réussi ; sinon, il est signalé comme échec. Cela garantit que les conversations respectent toujours les standards 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 finale, y compris les exécutions d’outils et les métadonnées, via un LLM avec tous les points de collecte et critères d’évaluation configurés. Le modèle utilise ce prompt combiné pour déterminer si chaque critère est rempli et pour extraire les données demandées pour analyse. Comme le LLM interprète ces configurations directement dans son prompt, il est important de les formuler clairement et de façon cohérente pour qu’il les comprenne et les applique correctement. Nous recommandons donc les bonnes pratiques suivantes pour rédiger les critères d’évaluation et les descriptions 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 basé sur la transcription : formulez l’objectif pour que le succès ou l’échec soit 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 que le LLM n’a pas.
3. Succès/échec/inconnu explicites : le LLM sait déjà que pour marquer comme réussi l’objectif doit être atteint, comme échec il ne doit pas l’être, et comme inconnu il ne doit pas pouvoir le déterminer à partir de la transcription. L’objectif doit donc être rédigé pour que « atteint » ou « non atteint » soit bien défini ; si c’est ambigu, le modèle risque de pencher vers inconnu ou une mauvaise classification.
4. Restez concis : parfois, de nombreux critères d’évaluation sont envoyés ensemble. Des critères trop longs ajoutent du bruit et peuvent provoquer des hallucinations.
5. La langue compte : toute explication fournie par le LLM sur la réussite ou non d’un critère sera dans la même langue que la description du critère, il faut donc 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 si ce n’est pas clair (ex : « Laissez vide 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ée assigné au point de collecte (ex : booléen, chaîne, entier, etc.). La description doit donc être alignée. Par exemple : « Extraire le nombre d’articles demandés » pour un entier, et « Oui/non si le client a accepté l’offre » pour un booléen.
3. Utilisez des enums si possible : pour les chaînes, si la liste de valeurs est fixe, utilisez enum dans le schéma ; cela contraint le modèle et réduit les sorties invalides.
4. Un objectif d’extraction par item : Ne regroupez pas plusieurs faits non liés dans la même description ; séparez-les pour que chaque item ait une cible d’extraction claire.
5. Gardez les descriptions courtes : Quelques phrases suffisent ; pas besoin de longs paragraphes. La transcription est déjà dans le message utilisateur, donc le schéma + une courte description suffisent.

Actuellement, le LLM utilisé pour cette étape d’évaluation et d’extraction est un modèle à faible latence pour garantir un traitement rapide. Nous prévoyons prochainement d’offrir plus de flexibilité à ce niveau.

Voyons maintenant les cas d’usage nécessitant une orchestration structurée, du déterminisme ou une spécialisation sur plusieurs rôles conversationnels, où les clients peuvent utiliser les Workflows.

Workflows

Workflows offrent une interface visuelle pour concevoir des parcours conversationnels complexes. Cela produit au final l’objet logique utilisé par l’orchestrateur pour gérer plusieurs sous-agents, outils et transferts sous un identifiant d’agent indépendant. Les Workflows ajoutent des éléments à prendre en compte en plus de ceux des agents indépendants, notamment comment :

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

Objectifs de conversation spécialisés

Les Workflows réutilisent les fonctionnalités des agents indépendants pour garantir un comportement cohérent tout au long de l’interaction. Cela inclut des éléments partagés comme le prompt système de base, les outils principaux et les bases de connaissances globales, toujours disponibles quel que soit l’étape du workflow. Le prompt système principal définit généralement le contexte global, le ton attendu, les contraintes de sécurité et toute instruction liée à la marque ou au produit.

Sur cette base commune, les Workflows introduisent des sous-agents spécialisés opérant dans un graphe orienté. Chaque sous-agent reçoit un objectif précis et enrichit la configuration de base avec des instructions de prompt, des outils et des sources de connaissances spécifiques à son rôle. Plutôt que de redéfinir tout le contexte, les sous-agents ajoutent leur intention via la composition de prompts et l’extension sélective du contexte. L’historique de conversation est conservé lors des transitions pour maintenir la continuité, mais chaque sous-agent fonctionne avec une vue volontairement limitée du système. Les bases de connaissances et outils sont exposés de façon 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 du sous-agent actif restent entièrement déterministes. Ce design permet aux Workflows de maintenir une cohérence globale tout en favorisant la spécialisation locale, pour un comportement prévisible, une séparation claire des responsabilités et un contrôle précis sur le contexte, la connaissance et les actions à chaque étape de l’interaction.

L’un des mécanismes clés qui rend ce contrôle possible est la gestion des transitions entre sous-agents.

Piloter les transitions de workflow avec des conditions LLM

Les Workflows avancent en parcourant un graphe orienté de sous-agents, où les transitions entre nœuds sont contrôlées par des conditions explicites. Ces conditions déterminent quand passer d’un sous-agent à un autre et permettent au workflow de réagir aux entrées utilisateur, aux résultats d’outils et aux variables dynamiques. Les conditions du graphe peuvent être déterministes ou évaluées par LLM. Les conditions déterministes, comme les transitions inconditionnelles, les vérifications sur les variables dynamiques ou les résultats d’outils, offrent de fortes garanties sur le déroulement et sont idéales pour imposer une progression stricte. Les conditions basées sur le LLM permettent, elles, une évaluation sémantique de critères en langage naturel, comme détecter l’intention de l’utilisateur ou reconnaître quand une information a été donnée.

Il est important de noter que les conditions LLM sont évaluées en dehors du prompt système de l’agent actif et n’influencent pas la génération de l’agent. Elles sont évaluées en parallèle par l’orchestrateur sur l’état courant de la conversation. Cette séparation garantit que la logique de transition ne pollue pas le prompt de l’agent ni la génération des réponses, tout en permettant d’exploiter le raisonnement du LLM pour une navigation flexible dans le graphe. En combinant conditions déterministes et évaluées par LLM, les Workflows allient prévisibilité et adaptabilité : transitions déterministes là où la justesse est critique, transitions LLM là où une interprétation sémantique est nécessaire.

Quand une conversation passe à une nouvelle étape, le système active une version de l’agent adaptée à cette étape. Chaque étape fonctionne avec ses propres instructions ciblées et n’a accès qu’aux connaissances et outils pertinents pour sa mission. Par exemple, une étape de gestion de remboursement peut accéder aux politiques de remboursement sans hériter du contexte d’onboarding ou de triage. Le passage d’une étape à l’autre est régi par des conditions de transition explicites. Ces conditions déterminent quand transférer la responsabilité et permettent un routage naturel au fil de la conversation. Pour maintenir la continuité, l’expérience utilisateur reste fluide lors des transitions, chaque étape héritant du contexte pertinent sans exposer la mécanique du passage. Des garde-fous surveillent aussi les transitions pour éviter les boucles improductives, assurant la stabilité et l’orientation du workflow.

Sécurité et protection

Pour les cas nécessitant des contrôles de sécurité renforcés, les clients peuvent s’appuyer sur des fonctionnalités supplémentaires de l’orchestrateur.

Garde-fous

Les Agents ElevenLabs appliquent des garde-fous de sécurité via un système de modération et d’alignement configurable qui évalue en temps réel les messages utilisateur et agent. Les contenus entrants sont classés selon plusieurs catégories de risque (contenu sexuel, violence, harcèlement, haine, auto-mutilation), chacune avec des seuils configurables. Lorsqu’un garde-fou est déclenché, la conversation est immédiatement interrompue et le client reçoit une notification claire du motif d’échec. Cela bloque systématiquement les interactions à risque, sans se limiter à des mitigations dans le prompt. Les garde-fous fonctionnent en dehors de la logique du prompt de l’agent, offrant une couche d’application fiable qui ne peut être contournée par le modèle ou l’utilisateur. Cette approche permet d’ajuster la sensibilité selon le domaine tout en maintenant une application déterministe à l’exécution.

Gestion des données conforme

Il arrive que des intervenants partagent avec un agent des informations sensibles soumises à des exigences strictes de stockage et de traitement, par exemple des données médicales nécessitant une gestion conforme HIPAA. Pour ces cas, nous proposons le mode Zero Retention (ZRM) au niveau de l’Agent ou de l’Espace de travail. Lorsqu’il est activé, toutes les données d’appel sont traitées uniquement en mémoire et jamais stockées de façon persistante. Une fois l’appel et le traitement terminés, aucune information n’est conservée par ElevenLabs. Les transcriptions, enregistrements audio et analyses ne sont donc pas disponibles dans le tableau de bord Agents, et cette politique s’applique aussi bien aux systèmes clients qu’aux logs internes. Même si les données ne sont pas conservées, elles sont traitées pendant l’appel, et tout webhook post-appel configuré recevra les résultats, permettant aux clients de stocker les transcriptions ou analyses dans leurs propres systèmes si besoin.

Quand le ZRM est actif, nous veillons aussi à ce que les sous-traitants ne conservent pas les données en limitant les LLM disponibles à des fournisseurs ayant des engagements contractuels interdisant l’entraînement ou la conservation des données clients ; actuellement, cela inclut les modèles Google Gemini et Anthropic Claude. Les clients souhaitant utiliser un autre LLM sous ZRM peuvent le faire en signant leur propre accord avec ce fournisseur et en le configurant comme LLM personnalisé via des clés API couvertes par cet accord. Comme cela étend la gestion des données au-delà de notre périmètre de confiance standard, notre équipe Sécurité doit examiner et valider le cas d’usage avant activation. Si le ZRM garantit qu’ElevenLabs et ses sous-traitants ne conservent pas les données d’appel, il revient aux clients de s’assurer que tout outil externe ou webhook utilisé par leur Agent respecte les exigences de conservation et de conformité applicables.

Perspectives

Dans cet article, nous avons vu comment les Agents ElevenLabs gèrent le contexte conversationnel, les outils, l’évaluation et les workflows structurés pour offrir des expériences fiables et en temps réel à grande échelle. À mesure que les clients déploient des agents dans des environnements de plus en plus complexes, nous continuons d’élargir la flexibilité de notre moteur d’orchestration, avec des modèles d’évaluation configurables, des contrôles de transition enrichis et une meilleure visibilité sur la composition des prompts et l’utilisation des tokens à chaque étape.

Notre équipe Forward Deployed Engineering travaille en étroite collaboration avec les clients pour faire évoluer ces capacités au rythme des déploiements réels. La prochaine génération d’Agents offrira encore plus de transparence, de déterminisme et d’adaptabilité, sans compromis sur la faible latence qui rend la conversation en temps réel possible.