Ce que la création d’un agent en 10 minutes révèle sur l’architecture réelle

Ce que le travail avec LangGraph, Deep Agents et TrueForge a révélé sur l’abstraction, le contrôle et le comportement réel des agents.

Lors de la création de DEVIN, une grande partie des efforts a été consacrée à des tâches qui ne sont jamais visibles lorsque quelqu’un utilise simplement un agent IA.

Mise en place de Deep Agents.

Configuration de Daytona en tant qu’environnement sandbox.

Utilisation de Ingest pour gérer le streaming et l’exécution en arrière-plan.

Faire coopérer tous ces éléments.

Les progrès étaient lents.

Mais au fil de cet effort acharné, une image plus claire est apparue de ce qui constitue réellement un système d’agents.

Pas seulement le modèle lui-même.

Tout ce qui l’entoure.

L’environnement de exécution.

Les outils.

Le sandbox.

La couche d’orchestration.

La manière dont les agents communiquent entre eux et se transmettent du travail.

Puis un hackathon est apparu, accompagné de TrueForge.

Presque immédiatement, il est devenu évident que une grande partie de l’infrastructure assemblée avec tant de soin à la main pouvait être confiée à une plateforme.

Mettre en place un agent fonctionnel ne prenait pas plus de dix minutes : connecter les MCP pertinents, ajouter les outils nécessaires, rédiger un fichier SKILL.md décrivant son comportement, puis simplement l’exécuter.

Après tout le temps passé à construire l’infrastructure de zéro, c’était presque trop simple.

Et honnêtement, c’était impressionnant.

C’est exactement ce que devrait être une bonne abstraction.

Mais le compromis caché derrière cette facilité n’était pas encore évident.

L’agent en 10 minutes

La première réaction fut une admiration pure face à la facilité avec laquelle le processus s’effectuait.

TrueForge s’est occupé de l’infrastructure environnante, laissant à la définition des compétences la tâche principale de décrire ce que l’agent devait réellement faire.

C’est une abstraction véritablement solide.

Les MCP ajoutés étaient visibles.

Les outils étaient visibles.

Le fichier SKILL.md était visible.

Tout semblait lisible et facile à comprendre.

Ainsi, l’habitude de s’y référer s’est ancrée.

C’est seulement avec une utilisation continue qu’un problème plus subtil est apparu, un problème qui n’avait pas été remarqué pendant le hackathon lui-même.

La préoccupation n’était pas ce qui pouvait être inspecté.

La préoccupation était où résidait réellement l’architecture.

Une compétence seule n’est pas une architecture

L’agent principal lit le fichier de compétences et l’utilise pour déterminer comment appliquer les capacités qui lui ont été confiées, y compris la manière et le moment de créer des sous-agents.

Cela signifie qu’un seul fichier SKILL.md peut finir par définir, de manière discrète, une grande partie de la structure comportementale de l’agent.

Imaginez que vous souhaitiez construire quelque chose comme ceci :

                    Root Agent
                   /          \
                  /            \
            Researcher        Coder
                /                \
               /                  \
          Searcher              Tester

Se contenter de dire à l’agent principal quelque chose comme : « Voici vos outils, créez les sous-agents dont vous avez besoin et gérez la situation », ce n’est pas pareil que de concevoir le système.

Ce qui compte vraiment, c’est de définir directement l’architecture :

• quels agents existent
• de quoi chacun est responsable
• quels outils sont attribués à chaque agent
• quel contexte chaque agent reçoit
• quand la délégation doit avoir lieu
• comment se déroule le processus de récupération en cas d’échec

C’est cette distinction qui a commencé à se démarquer.

Avec l’approche Deep Agents, l’architecture est quelque chose que l’on construit délibérément.

Avec TrueForge, la partie infrastructure est bien plus simple, mais l’architecture comportementale dépend finalement du fait que l’agent principal interprète la compétence comme vous le souhaitez.

Cette dépendance lie le comportement de tout le système beaucoup plus étroitement au modèle sous-jacent.

Un modèle plus performant peut interpréter la compétence exactement comme prévu.

Un modèle moins performant peut emprunter une voie complètement différente avec les mêmes instructions.

Même fichier de compétence.

Mêmes outils.

Comportement résultant différent.

L’architecture théorique n’a pas changé.

Seule l’interprétation de cette architecture par le modèle a changé.

C’est ce manque qui a rendu cette approche plus difficile à considérer comme fiable.

Le travail sur AEGIS a renforcé cette préoccupation

Lors de la création d’AEGIS, l’équipe est tombée sur un problème simple mais révélateur.

L’agent devait enquêter sur les cas de blocage du cycle d’événements de Node.js.

Il devait examiner le code, reproduire le problème, mesurer le comportement en temps réel, diagnostiquer la cause racine, proposer une correction et confirmer que cette correction fonctionnait réellement.

Débutalement, l’étape de vérification se limitait principalement à une instruction indiquant au modèle ce qu’il devait faire, à peu près comme ceci :

Exécuter l’expérience, comparer les métriques obtenues et déterminer si la correction a vraiment résolu le problème.

Pourtant, laisser un LLM décider lui-même si sa propre correction a réussi ne constitue pas vraiment une vérification.

Ainsi, la partie déterministe de cette logique a été intégrée dans le code plutôt que dans le texte d’instruction.

Le modèle effectue le raisonnement.

Le système réalise la mesure.

Le vérificateur effectue l’appel.

Cette expérience a donné naissance à un principe qui s’applique aujourd’hui largement à la conception des agents :

Si quelque chose ne peut pas être observé, il ne peut pas être correctement testé. S’il ne peut pas être testé, il ne peut pas être évalué. Et s’il ne peut pas être évalué, il ne peut pas être amélioré de manière fiable.

C’est précisément pour cette raison que l’architecture est importante.

Non pas parce qu’un diagramme avec plus de cases et de flèches serait intrinsèquement supérieur.

Mais parce qu’il est nécessaire d’avoir une explication claire de ce qui a engendré le comportement que l’on cherche à améliorer.

« Ça marche » versus « Je comprends pourquoi ça marche »

Deux agents différents peuvent tous deux réussir techniquement.

Ils peuvent tous deux accomplir la tâche assignée.

Ils peuvent tous deux se montrer excellents lors d’une démonstration en direct.

La véritable épreuve survient lorsque quelque chose ne fonctionne pas.

Avec un type d’agent, il est possible de tracer le chemin d’exécution exact :

Root Agent
    ↓
Researcher
    ↓
Search Tool
    ↓
Result
    ↓
Root Agent
    ↓
Coder
    ↓
Sandbox

Chaque point de décision peut être examiné et remis en question :

Pourquoi cette étape particulière a-t-elle eu lieu ?

Avec un autre type d’agent, il n’y a qu’une compétence décrivant le résultat souhaité, tandis que le modèle trouve lui-même le chemin à suivre.

Lorsque cela fonctionne, c’est remarquablement simple.

Lorsque cela échoue, la question de débogage devient beaucoup plus difficile à répondre :

La panne est-elle causée par le modèle, les instructions, la logique de délégation, le contexte fourni, ou bien l’architecture que le modèle a improvisée de lui-même ?

Ce deuxième scénario représente un problème bien plus difficile à résoudre.

C’est ce que TrueForge a enseigné

Au début, avant de travailler avec cette plateforme, on suppose naturellement que la partie la plus difficile dans la création d’agents réside entièrement dans la couche d’infrastructure.

Travailler avec elle change cette vision : l’infrastructure n’est en réalité que la moitié du défi.

L’infrastructure est quelque chose que l’on peut abstraire.

Le comportement résiste à l’abstraction.

Une plateforme peut fournir un environnement de test isolé.

Elle peut fournir MCP.

Elle peut fournir des fonctionnalités de streaming.

Elle peut fournir l’ensemble du environnement d’exécution.

Pourtant, si vous développez un agent dont les actions ont vraiment de l’importance, vous devez encore répondre à certaines questions par vous-même :

Quel composant prend quelle décision ?

Que peut faire chacun ?

Où a lieu exactement la délégation ?

Quelle visibilité avez-vous sur le processus ?

Que pouvez-vous vraiment mesurer ou évaluer ?

Quels leviers existent pour corriger les problèmes lorsqu’ils surviennent ?

Ces éléments sont ceux que personne ne devrait confier sans y réfléchir à deux fois.

Combien de temps faut-il pour comprendre pourquoi cela a échoué ?

Assembler un agent en dix minutes est véritablement une prouesse impressionnante.

Mais une question plus utile devient plus importante que cette vitesse :

Combien de temps faut-il pour comprendre pourquoi cela a échoué ?

Les environnements de production ne récompensent pas une première démonstration réussie.

Ce qu’elles pénalisent, c’est la dixième défaillance.

Le outil qui fournit des résultats inattendus.

Le modèle de base moins performant.

L’agent qui transfère le travail alors qu’il ne le devrait pas.

L’agent qui échoue à transférer le travail lorsqu’il le devrait.

L’agent qui annonce « Terminé »,

pourtant rien n’a réellement été accompli.

C’est précisément là que l’architecture trouve son utilité.

Qu’a vraiment été appris

En réfléchissant au projet DEVIN, la véritable leçon n’a pas été de maîtriser Deep Agents, Daytona ou Ingest en tant qu’outils indépendants.

C’était plutôt de comprendre comment les composants d’un système d’agents se connectent entre eux.

TrueForge a ensuite montré à quel point ces mêmes composants peuvent être abstraits pour ne plus être visibles.

L’utilisation de cet outil a révélé l’autre face de cette commodité :

L’infrastructure peut disparaître d’un flux de travail sans que le comportement ne disparaisse avec elle.

Quelqu’un doit toujours gérer ce comportement.

Quelqu’un doit encore le voir en action.

Quelqu’un doit encore évaluer s’il fonctionne bien.

Et quelqu’un doit encore décider ce qui sera modifié en cas d’échec.

C’est une responsabilité qu’il vaut mieux conserver en interne, plutôt que de l’externaliser.

Où va l’architecture des agents

Cette expérience redéfinit également la manière dont on peut comprendre plus globalement l’évolution des systèmes agents.

Le domaine a progressé à travers plusieurs étapes :

modèles → outils → MCP → agents → agents avancés

et à chaque étape, l’infrastructure nécessaire devient de plus en plus facile à obtenir.

Dans cette perspective, la couche la plus importante à l’avenir est le framework entourant le modèle.

Il ne s’agit pas seulement des capacités brutes du modèle, mais aussi du système qui lui fournit :

contexte, outils, exécution, permissions, orchestration, mémoire, observabilité, évaluation et contrôle.

Au fur et à mesure que les modèles s’améliorent, la qualité brute du modèle ne sera plus le seul facteur décisif.

La question d’ingénierie à se poser sera de plus en plus la suivante :

Quel environnement a été créé autour du modèle, et quel degré de contrôle existe sur son comportement ?

C’est sans doute la leçon principale tirée de la création de DEVIN puis du montage d’un agent en dix minutes.

Plus il devient simple de créer un agent, plus il devient essentiel de comprendre tout ce qui l’entoure.

Lectures complémentaires