ElevenLabs confie la routine à des agents internes et économise 1200 heures par mois

ElevenLabs a publié un retour d'expérience sur le fonctionnement de ses propres agents, construits sur la plateforme ElevenAgents, au sein de l'entreprise. Les chiffres : plus de 1 200 heures économisées par mois, plus de 5 000 réponses aux questions des employés, des dizaines de démos personnalisées pour les clients et plus de 150 tickets créés par les agents au cours du dernier mois. Ces 1 200 heures représentent environ sept à huit équivalents temps plein. L'auteur du billet, Jake Tennant, responsable produit et croissance d'ElevenAgents (il a auparavant passé quatre ans comme PM chez Coinbase), décrit sans fard les résultats comme les techniques d'ingénierie qui y ont mené.

Tout a commencé modestement. Les agents dans Slack aidaient à retrouver plus vite des informations internes : données de rétention des utilisateurs, documentation utile, historique d'un compte. Puis ils ont appris à agir. Un employé pose une question, signale un bug ou demande une démo, et l'agent répond ou exécute la demande.

Qui fait quoi dans Slack

Les agents sont rattachés à des équipes précises :

• GTM bot (ventes) répond aux questions sur les clients. Exemples de requêtes : « Quels sont nos principaux clients dont nous avons le droit d'utiliser le logo au Royaume-Uni, en France et en Allemagne ? » ou « Quels sont nos principaux cas d'usage de l'API ? »
• FDE bot (Forward Deployed Engineer, ventes et préventes) répond aux questions produit, par exemple quelles intégrations il faut à un client qui veut un AI SDR sortant pour planifier des rendez-vous à la place des account managers. À partir d'un simple message, il assemble aussi un agent fonctionnel adapté au scénario d'un prospect donné.
• Triage bot (support et ingénierie) transforme les retours et les rapports de bugs en tickets. En un mois, il a créé 150 tickets, un travail qui relevait auparavant de deux équipes, à la main.
• Les agents pour le produit et le marketing produit répondent aux questions sur les données dans des canaux thématiques. Exemple : comment, en six mois, a évolué la conversion du forfait gratuit vers le forfait payant chez les abonnés self-serve d'ElevenCreative aux États-Unis, et quels facteurs jouent sur elle. L'analyse arrive dans un fil de discussion, où l'on peut poser des questions complémentaires.

Un ticket dont on n'a pas à rougir

Le bot de triage dispose de Procedures distinctes pour les feature requests et pour les bugs. Avant de créer un ticket, il cherche du contexte dans Slack, le compare aux tickets existants pour éviter les doublons et vérifie que les détails suffisent pour établir un diagnostic. Ce n'est qu'ensuite qu'il ouvre un ticket dans Linear avec la priorité adéquate. Pour déterminer l'équipe responsable, le bot s'appuie sur un document décrivant les zones de responsabilité, chargé dans la base de connaissances de l'agent.

Une fois le ticket créé, une étape supplémentaire se déclenche : l'agent vérifie que les champs sont correctement remplis et que le ticket a bien été attribué à la bonne équipe. Selon l'auteur, cela a réduit les cas d'hallucinations et d'erreurs d'attribution.

Tailler le schéma, pas polir le prompt

Le cœur technique du billet tient en quatre techniques que l'équipe a tirées de l'exploitation :

• Le travail sur le schéma compte plus que le prompt engineering. Pour les agents de retrieval, le plus gros gain de qualité est venu de la suppression de champs, pas du réglage du prompt système. Chaque colonne ou champ d'objet en trop est un point de plus où le modèle peut deviner à tort. Réduire le schéma à un ensemble limité de champs critiques a amélioré la précision plus que n'importe quelle retouche du prompt. L'effet secondaire est évident : schéma plus court, moins de contexte consommé par requête.
• Typage des picklists. Les champs Salesforce comme l'étape d'une affaire ou le type de compte ont un ensemble fixe de valeurs. Sans contrainte, le modèle peut produire une valeur plausible mais inexistante. Désormais, les valeurs autorisées sont récupérées au démarrage et injectées dans les définitions de types de l'outil MCP, si bien que le modèle ne choisit que parmi des options réelles.
• Élagage des procédures. À mesure que le nombre de Procedures d'un agent augmente, elles se mettent à se chevaucher. L'outil Architect d'ElevenAgents peut les réorganiser pour que les conditions de déclenchement soient univoques et que la logique n'entre pas en conflit.
• Vérification des tâches. Contrôle des champs et de l'équipe après la création d'un ticket dans Linear, décrit plus haut.

Autre observation, sur l'adoption : pour des agents internes, la précision est indispensable dès le premier jour, faute de quoi l'équipe cesse de leur faire confiance et de les utiliser. Dans un canal partagé, les erreurs se remarquent davantage, mais les succès aussi, ce qui, selon l'auteur, a favorisé le déploiement.

Ce qu'il faut mettre en pratique

Si vous construisez des agents internes au-dessus d'un CRM, d'un outil de suivi et d'une messagerie d'entreprise, voici la marche à suivre qui ressort de ce cas. D'abord, réduisez le schéma de données au minimum de champs sans lesquels aucune réponse n'est possible. Ensuite, limitez les types de valeurs aux énumérations réelles de la source, par exemple via les définitions d'outils MCP. Puis séparez les procédures par type de tâche et nettoyez-les régulièrement de leurs recouvrements. Enfin, ajoutez une étape d'auto-vérification après chaque action d'écriture. Il vaut mieux lancer les agents dans des canaux partagés : les erreurs y sont visibles immédiatement, et l'utilité de l'agent saute aux yeux de tous.

Ce billet est paru deux semaines après un autre retour d'expérience d'ElevenLabs, où l'entreprise expliquait comment elle traite 22 000 demandes de support par mois grâce à ElevenAgents. Le même produit est cette fois présenté comme un outil interne de l'entreprise.