Bon, maintenant que le projet d’agent de codage teste et valide avec succès chaque exécution, et que la plupart des pépins techniques sont réglés, il est temps de réfléchir à la couche d’orchestration.
L’appli, en plus gros.
Retour à la cité des petits agents heureux qui fonctionnent.
Étudier Paperclip a été salutaire. Surtout parce que c’est minimal comparé à la base de code de Busy39. J’aime cette discipline. Le focus. Le refus de bâtir une cathédrale quand un bon atelier suffit.
L’empreinte est plus petite que celle de Busy39.
Et ce qui est intéressant, c’est que Paperclip externalise en quelque sorte le travail d’agent proprement dit à des agents MCP de codage, plutôt que de tenter de maîtriser toute la pile.
En regardant ça, je pense que c’est globalement la bonne approche.
Je pense que Busy39 s’est effondré parce qu’il essayait de gérer tout le runtime dans un seul système monolithique. Compartimenté ou non, c’était toujours un monolithe, et la surface de test était énorme.
En pratique, ça m’intéresse moins de bâtir un autre runtime d’agent à partir de zéro, et davantage de brancher une appli comme celle-ci à des agents tiers comme Codex et Openclaw, surtout qu’ils ne sont pas conçus pour tourner sur le long terme.
Cette appli a besoin de solveurs à long horizon avec des fonctionnalités qui n’existent tout simplement pas dans la plupart des frameworks d’agents modernes.
Mais j’aime bien le modèle multi-sociétés de Paperclip. Même si, honnêtement, si un système comme celui-ci atteignait une vraie échelle, je pense que cette structure deviendrait accessoire. En pratique, on le détournerait probablement pour des divisions, des départements, des équipes ou des projets, puis on lierait les couches ensemble plutôt que de prétendre qu’elles doivent rester totalement isolées.
Deux bugs d’ambition différents
Comme Busy, Paperclip a aussi un bug d’ambition.
Si on essaie d’en configurer trop, le système plante.
Mais pour des raisons différentes.
Busy39 a échoué parce qu’il a voulu trop posséder du runtime.
Le point faible de Paperclip, c’est la configuration manuelle. Il part du principe qu’une certaine orchestration existe déjà autour de lui.
Il n’est pas polymorphe ou auto-évolutif comme pourraient l’être une appli comme Busy39, ou quelque chose comme Hermes Agent.
Et je reconnais cet état d’esprit.
Je comprends pourquoi il existe.
Comprendre ça a été vraiment utile.
Parce qu’en attaquant Busy41, la forme du problème semble plus claire maintenant :
Ne maîtrisez pas toute la pile.
Maîtrisez la continuité.
Plus de détails là-dessus bientôt.