Je réfléchis à un petit détour sur la bêta x15 de WOVEN pour examiner sérieusement MCP et quelques nouvelles options de montage.
Pour ceux qui débarquent : WOVEN est un système d’agents que je construis depuis décembre. L’idée de base est née de mon propre flux de travail créatif — je voulais des agents capables de s’améliorer avec le temps et d’apprendre de l’expérience.
Il y a eu quelques débats sur les risques d’alignement, mais j’ai l’impression que c’est un problème de développement et d’ergonomie, pas un problème de contrôle pyramidal.
De la mémoire aux outils
x13 était la première version fonctionnelle, avec une mémoire entièrement câblée — mais c’était fragile et trop monolithique pour la tâche. Ça marche encore, pourtant.
x14 a ajouté les outils et a complètement repensé le système de mémoire. Le nouveau design utilise une base de données vectorielle et un système de classement par graphe pour prioriser les souvenirs. J’ai peut-être emprunté quelques idées au fonctionnement du PageRank de Google — mais ici, sans liens, c’est appliqué un peu différemment.
Réussir la partie outils a été un défi en soi — surtout pour les boucles d’agents de longue durée, où on essaie de supporter l’utilisation d’outils en plusieurs étapes sans tomber dans les pièges de répétition récursive qui plombent beaucoup d’autres systèmes.
x15 a introduit une couche de configuration dynamique pour simplifier les intégrations API.
Ça marchait super bien — jusqu’à ce que, juste au moment où je terminais... MCP tombe.
Le compromis MCP
Au début, j’ai résisté. MCP ne me semblait pas être de la bonne ingénierie. Ça faisait brouillon.
Mais plus je regardais, plus j’en voyais le potentiel.
Actuellement, x15 utilise le framework d’outils d’OpenAI. L’avantage, c’est que c’est largement supporté et disponible partout.
J’ai même pondu un système sympa et simple basé sur YAML pour créer des intégrations — mais il faut toujours en écrire une par point de terminaison. C’est mille fois mieux que de tout câbler à la main... mais on est loin de la fluidité de MCP.
Le compromis ?
MCP exige des connexions persistantes toujours actives pour chaque API qu’il gère. Ça introduit une vraie complexité pour les déconnexions, les redémarrages de services, les pipelines CI/CD, et tout le reste. Mais ça simplifie radicalement le streaming et le design d’applications dynamiques.
En gros, on construit une API pour gérer ses API avec une API — mais si ça marche sans aucune configuration ? C’est gagné.
Ça va flinguer mon calendrier totalement arbitraire et auto-imposé.
Je prévoyais de lancer une bêta fermée la semaine prochaine, puis de récolter les retours avant une sortie open source.
Si je pivote vers MCP et que je développe x16, avec cette couche d’outils alternative et cinq nouvelles intégrations de services, je m’expose à trois semaines de retard supplémentaires.
Espérons juste que personne ne redéfinisse radicalement les outils d’IA avant que je sorte le truc.
Je croise les doigts.