Lifecycle stage — Build
Presque personne n'a livré un système multi-agent à l'échelle production. La distance entre une démo LangGraph qui fonctionne dans un notebook et un système qui tourne pour des clients payants est l'endroit où toutes les autres équipes calent — et elles calent pour des raisons qui ne sont pas évidentes tant que vous n'en avez pas construit un. Il s'agit des phases ENGINEER et PILOT de la DEPLOY Method, condensées en une mission embedded de 12 semaines pour les équipes qui ont déjà un prototype d'agent avec de vrais utilisateurs et doivent l'industrialiser. J'ai architecturé Auralink — 1,7 million de lignes de code en production, environ 20 agents autonomes qui résolvent 78 % des incidents sans intervention humaine, peer-reviewed sur arXiv. Aucun système multi-agent comparable n'existe en production aujourd'hui. Le travail que je ferai avec votre équipe est le même que celui que j'ai fait avec la mienne, adapté à votre codebase, vos agents et vos contraintes opérationnelles. J'ai livré huit ventures IA en production. Je sais quelles décisions peuvent être différées et lesquelles vous reviendront dans la figure six semaines après le lancement si vous les sautez maintenant.
Chaque démo d'agent fonctionne dans un notebook et s'effondre sous le trafic concurrent de production. Le tutoriel utilise des appels synchrones, une seule trajectoire happy-path et des outils mockés. La production fait tourner des dizaines de sessions d'agents en parallèle, chacune effectuant de vrais tool calls avec de vrais modes de défaillance, et le pattern d'orchestration naïf qui semblait propre dans la démo devient une thundering herd de retries, deadlocks et états à moitié commités. Votre équipe sait que c'est un problème et n'a pas l'architecture de référence pour le résoudre.
Votre stratégie d'évaluation pour les appels LLM single-turn ne s'étend pas aux trajectoires d'agents multi-étapes. Vous pouvez évaluer un prompt. Vous ne pouvez pas encore évaluer un plan de 14 étapes où la cinquième étape a choisi le mauvais outil, la neuvième a passé le mauvais argument, et la réponse finale était quand même techniquement correcte. Les modes de défaillance dans les trajectoires d'agents se composent à travers les étapes et la méthodologie d'évaluation du travail single-turn produit des scores trompeurs. Sans évaluation au niveau de la trajectoire, vous ne pouvez pas dire si une mise à jour de modèle a amélioré ou régressé le système, et vous ne pouvez pas livrer avec confiance.
Le coût par tâche explose de façon imprévisible parce que chaque étape d'agent multiplie la consommation de tokens. Une seule requête utilisateur déclenche un plan, qui déclenche des tool calls, qui déclenchent des sous-agents, qui déclenchent plus de tool calls. Votre compte de tokens par session est maintenant 40x celui d'un appel LLM classique et votre CFO veut un modèle qui explique pourquoi un power user a coûté 18 € en tokens mardi dernier. Vous n'avez pas l'instrumentation pour répondre à cela — pas de comptabilité de tokens par étape, pas de routing qui choisit des modèles moins chers pour les étapes plus faciles, pas de plafonds de budget qui échouent gracieusement quand une session part en vrille.
Quand un agent fait quelque chose de mal en production, vous n'avez pas de stack d'observabilité qui vous dit quelle étape, quel prompt, quel tool call l'a causé. L'utilisateur se plaint que « l'agent a donné une réponse bizarre ». Vos logs montrent la réponse finale et rien d'autre. Vous ne pouvez pas reproduire la trajectoire parce que l'agent est non-déterministe. Vous ne pouvez pas dire si le bug est dans le planner, le tool router, la couche retrieval ou un template de prompt spécifique. Chaque incident devient un exercice de forensique de plusieurs jours et votre équipe perd confiance dans le système plus vite que les utilisateurs.
La mission se déroule en quatre phases de trois semaines. Je travaille en embedded avec votre équipe ingénierie — vos ingénieurs construisent, j'apporte les décisions de topologie, la méthodologie d'évaluation et les patterns d'observabilité d'Auralink. Aucun travail ne se fait sur un slide de consultant. À la fin de la semaine douze, votre équipe opère le système sans moi.
Je plonge en profondeur dans votre prototype actuel — le graphe d'agents, l'inventaire des outils, la gestion d'état, les modes de défaillance que vous avez déjà rencontrés. Je produis une conception de topologie écrite : quels agents, quelles responsabilités, quels patterns de communication, quelles frontières d'état, quelles zones d'isolation des défaillances. La conception est spécifique à votre domaine et à votre codebase, pas une architecture de référence copiée-collée d'un article de blog. À la fin de la semaine trois, votre équipe a un blueprint qu'elle peut défendre face à un reviewer senior et un chemin de migration depuis le prototype actuel qui n'exige pas de réécriture.
Vos ingénieurs implémentent la topologie. Je travaille à leurs côtés sur les décisions plus difficiles — les primitives d'orchestration, la stratégie de concurrence, la machine à états pour les sessions longue durée, la logique de retry et de compensation pour les défaillances d'outils. Nous livrons de façon incrémentale contre le trafic réel à partir de la semaine cinq, pas une bascule big-bang en semaine sept. À la fin de la semaine sept, la nouvelle topologie sert du trafic de production et l'ancien prototype a été mis hors service.
Évaluation au niveau de la trajectoire construite sur les patterns que j'ai développés pour Auralink — évaluation par étape, trajectoires ground-truth pour les tests de régression, LLM-as-judge avec prompts calibrés, et la méthodologie statistique qui vous permet de dire « cette mise à jour de modèle a amélioré le système de 4,2 % avec p < 0,01 » plutôt que « la nouvelle version semble meilleure ». Comptabilité de tokens par étape et dashboards coût-par-tâche pour que votre CFO puisse répondre aux questions qui arriveront. Votre équipe fait tourner l'évaluation sur chaque changement à partir de la semaine neuf.
La stack d'observabilité que votre ingénieur d'astreinte utilisera quand le pager sonne à 3h du matin — traces de trajectoires liées aux sessions utilisateur, prompts et complétions par étape, entrées et sorties de tool calls, comptabilité de tokens, décompositions de latence, attribution des coûts. Runbooks pour les 10 types d'incidents les plus fréquents que votre système produira. Sessions de travail avec votre équipe SRE pour qu'elle soit propriétaire des seuils d'alerting, des dashboards et des playbooks de réponse aux incidents. Quand je pars, votre équipe opère le système. Pas de retainer, pas de dépendance continue.
Organisations technologiques d'entreprise et startups Series-B+ avec un prototype d'agent qui a de vrais utilisateurs, un budget pour une mission embedded de 12 semaines, et une équipe ingénierie avec la capacité de détenir le système après le handoff. Équipes produit où le CTO ou VP Engineering a déjà heurté le mur entre « la démo d'agent fonctionne » et « le système d'agents opère » et sait que l'écart est un problème de topologie, un problème d'évaluation et un problème d'observabilité — pas un problème de prompt engineering. Ceci n'est pas pour les équipes sans expérience LLM en production — elles ont besoin du Readiness Audit ou du Strategy Sprint d'abord. Ce n'est pas non plus pour les équipes sans codebase existante ; la mission suppose un prototype à industrialiser, pas une construction greenfield.
Pas beaucoup. Le framework d'orchestration est un véhicule — les décisions qui comptent sont la topologie, la gestion d'état, la méthodologie d'évaluation et l'observabilité. J'ai travaillé à travers les principaux frameworks et à travers du code d'orchestration custom. En semaine une, j'évalue si votre framework actuel est le bon véhicule pour là où vous allez ; parfois la réponse est oui et nous construisons dessus, parfois la réponse est qu'un goulot d'étranglement spécifique plaide pour une migration. Je prends cette décision avec des preuves, pas en fonction du framework qui a le meilleur marketing.
Un senior AI engineer que vous embauchez en 2026 n'a probablement pas livré de système multi-agent en production parce que presque personne ne l'a fait. Je l'ai fait une fois, à 1,7 million de lignes de code et 78 % de résolution autonome. La reconnaissance de patterns n'est pas encore disponible sur le marché des prestataires. Vos ingénieurs font l'implémentation ; j'apporte les décisions de topologie, la méthodologie d'évaluation et les patterns d'observabilité qui leur prendraient autrement trois itérations et douze mois à apprendre. Quand je pars, votre équipe détient tout et n'a plus besoin de moi.
Non. La topologie d'agents, le harnais d'évaluation et l'observabilité sont chacun des problèmes de trois semaines bien faits et chacun des problèmes d'une semaine mal faits. La version compressée produit un système qui tourne jusqu'à ce qu'il ne tourne plus, et le coût de debugging au mois quatre dépasse les économies de consulting au mois un. Si vous n'avez pas douze semaines, la bonne mission est le service Pilot-to-Production Hardening, qui couvre le travail de production-readiness sans la refonte complète de la topologie. Je le recommanderai honnêtement si c'est le bon fit.
Presque jamais. Dans les missions que j'ai menées, la conception de topologie préserve 60-80 % du code existant et change la couche d'orchestration, les frontières d'état et les patterns d'isolation des défaillances. La logique métier que votre équipe a écrite va généralement bien ; ce qui doit changer est la façon dont les agents se coordonnent, dont l'état est géré et dont les défaillances sont traitées. Les réécritures complètes sont le signe d'un consultant qui ne veut pas lire votre code. Je lis votre code.
C'est un chiffre mesuré issu du système de production d'Auralink, rapporté dans le papier arXiv. 78 % des incidents assignés au pool d'agents sont résolus sans humain dans la boucle — ce qui inclut les cas où un agent escalade correctement, pas seulement les cas où il résout de bout en bout. La méthodologie pour le mesurer fait partie de ce que j'apporte dans votre mission. Chaque équipe avec laquelle j'ai travaillé finit avec un chiffre différent parce que son profil de tâches est différent ; le but n'est pas de répliquer 78 %, c'est de construire l'infrastructure de mesure qui vous dit quel est votre vrai chiffre.
Decouvrez d'autres services qui completent cette offre
30 minutes. Je diagnostique votre situation, je vous dis honnêtement si ce service convient — et sinon, lequel conviendrait.