Pourquoi nous avons arrêté de construire des orchestrateurs custom (presque).

En 2022, les frameworks pour l'orchestration multi-agents étaient soit trop minces (les premières abstractions d'agents de LangChain), soit trop dogmatiques dans les mauvaises directions. Écrire un runtime custom semblait le choix raisonné : maîtriser son modèle d'exécution, ses modes d'échec, sa surface d'observabilité. Nous l'avons fait quatre fois.

Chaque runtime a été construit pour un besoin précis qui semblait impossible à satisfaire avec les outils disponibles. Chacun a résolu ce besoin. Chacun a aussi accumulé du poids : boilerplate de gestion d'état, logique de retry, patterns de communication inter-agents, formats de sérialisation, à un rythme qui a fini par rendre la chose pour laquelle il avait été conçu plus difficile à modifier, pas plus facile.

Le schéma s'est répété avec suffisamment de régularité pour que nous cessions de parler de coïncidence. Ce que les runtimes custom vous donnent en contrôle, ils le reprennent en surface de maintenance. À la troisième itération, nous maintenions un petit framework qu'environ un développeur et demi comprenaient de bout en bout. Ce n'est pas un atout d'équipe. C'est un bus factor déguisé en infrastructure.

Comment nous en sommes arrivés là

La lecture cynique de « LangGraph est suffisant » est que nous avons capitulé et adopté un framework. La lecture exacte est que les quatre runtimes que nous avons construits nous ont appris, à grands frais, ce que l'exécution de graphes requiert vraiment. Au moment où la version 0.1 de LangGraph est sortie, nous avions construit (et partiellement reconstruit) chaque primitive qu'il offrait. La décision de migrer n'était pas une capitulation. C'était admettre que nous étions devenus, malgré nous, une équipe de framework.

Chaque runtime a résolu le problème qui lui faisait face. Aucun des problèmes n'était le même. C'est précisément ça qui ne se généralisait pas : le coût d'un runtime custom ne réside pas dans son écriture. Il réside dans l'accumulation de cas limites qui doivent être gérés indéfiniment, par des personnes qui n'étaient souvent pas là quand les choix initiaux ont été faits.

Les quatre runtimes, en mémoire

Nous avons abandonné les quatre en l'espace de dix-huit mois. Chacun avait une cause de mort nette. Nous conservons les post-mortems parce que les modes d'échec sont courants, et les nommer à voix haute aide la prochaine équipe à éviter la même trajectoire.

Durée totale : 37 mois d'orchestration custom sur quatre systèmes, avec chevauchements significatifs. Temps consacré à la maintenance spécifique à l'orchestration plutôt qu'aux fonctionnalités produit : estimé à 0,8 à 1,2 ETP équivalent, de façon soutenue. C'est ce chiffre qui a finalement convaincu tout le monde.

Ce que LangGraph fait vraiment bien

LangGraph a résolu les trois problèmes qui ont tué nos runtimes custom, et ces trois problèmes sont véritablement difficiles. La quatrième chose qu'il a résolue (l'observabilité) est celle qui justifie rétrospectivement toutes les autres, parce que le débogage est là où les décisions d'infrastructure sont vraiment payées.

Aucun de ces points n'est une découverte originale. Ce sont des prérequis pour tout système d'exécution de graphes sérieux. Le fait est que LangGraph les a, et que le coût en temps de les construire soi-même est plus élevé qu'il n'y paraît de l'extérieur. Nous avons quatre points de données sur ce coût.

Quand nous construisons encore le nôtre

Le « presque » dans le titre fait un vrai travail. Il existe trois conditions dans lesquelles nous démarrons avec un runtime custom, ou migrons vers l'un d'eux, et elles sont précises. Les traiter comme précises, c'est la discipline qui fait tenir la règle des 80 %.

Notez ce qui n'est pas dans cette liste : « nous avions besoin de plus de contrôle », « l'abstraction ne nous convenait pas », « nous voulions comprendre le runtime ». C'étaient toutes des raisons que nous invoquions pour les runtimes custom dans le passé. Elles ne suffisent pas. Le contrôle gagné est réel ; le coût de maintenance l'est aussi, et ce coût s'accumule alors que le bénéfice du contrôle, lui, ne croît pas.

Comment nous avons migré Relay vers LangGraph

Relay était le plus difficile à migrer parce que c'était le meilleur des quatre. L'équipe y était attachée, l'architecture était défendable, et le cas pour la migration était véritablement serré. Ce qui a rendu la décision gérable, c'est de construire une matrice de décision avant que l'argument émotionnel commence.

Cinq des six dimensions ont favorisé LangGraph au premier passage. La ligne du bus factor a remporté l'argument. Un plafond d'un développeur et demi sur la connaissance institutionnelle n'est pas acceptable pour une infrastructure centrale, quelle que soit la propreté du code.

Ce que quatre runtimes nous ont vraiment appris

La valeur de la construction des runtimes custom n'était pas nulle. Ce serait malhonnête de le prétendre. La compréhension que nous avons construite de l'exécution de graphes, de la gestion d'état et de la coordination inter-agents nous a rendus significativement meilleurs dans l'utilisation de LangGraph que les équipes qui y sont venues sans expérience préalable. On n'a pas besoin de construire la chose pour apprendre ce qui compte ; mais nous l'avons fait, et ça a aidé.

Si vous êtes sur le point de démarrer un orchestrateur custom : lisez cet article, puis relisez-le avec la section sur le coût de maintenance surlignée. Vérifiez ensuite si LangGraph, ou l'un des autres frameworks qui ont mûri ces dix-huit derniers mois, échoue vraiment à satisfaire vos exigences, ou s'il vous est simplement peu familier. Le manque de familiarité est peu coûteux à corriger. Un runtime maison avec un bus factor de 1,5 développeur ne l'est pas.

Si vous souhaitez un deuxième avis sur une décision d'orchestrateur en cours, le formulaire de contact est la voie la plus rapide. Nous faisons des révisions de 30 minutes pour les piles d'agents en production, gratuitement.