Le framework zymi propose de construire des agents IA comme un projet dbt, avec du YAML et de l'event sourcing

Un article publié sur Habr décortique zymi, un framework expérimental qui permet d'assembler des systèmes multi-agents dans l'esprit de dbt. Plutôt qu'une orchestration manuelle et un état mutable partagé, l'auteur propose des configurations YAML déclaratives et un bus event-sourced, où chaque étape d'un agent est enregistrée comme un événement distinct.

Comment fonctionne zymi

zymi est né d'un problème très concret. Venu du data engineering, l'auteur s'est lancé dans le développement d'agents et a tenté de monter des architectures classiques avec LangGraph. Il s'est vite heurté à l'état partagé et mutable : il faut sans cesse le mettre à jour, le déboguer et l'analyser à travers les logs. D'où une autre approche : décrire non pas la manière dont les agents enchaînent les étapes, mais ce que le système doit accomplir. La référence à dbt est directe : le développeur y déclare des transformations, et le moteur les exécute lui-même dans le bon ordre.

Un projet zymi de base se décompose en entités familières : agents, outils, mémoire, pipelines et un fichier commun project.yml. L'exemple de démonstration met en scène deux agents, un chercheur et un rédacteur, et le pipeline prend la forme d'un DAG : deux étapes peuvent démarrer en parallèle, tandis que les suivantes dépendent de depends_on. Les outils sont eux aussi décrits de façon déclarative, par exemple sous forme d'appels HTTP avec des paramètres et des clés tirées des variables d'environnement. Selon l'auteur, c'est précisément ce qui rend le système plus adapté aux LLM : il est nettement plus simple pour un modèle de générer du YAML conforme à un schéma strict que d'écrire un code d'orchestration fragile.

• Les agents sont décrits dans des fichiers YAML
• Les outils peuvent être branchés sous forme d'appels HTTP
• Les pipelines s'assemblent en DAG avec des étapes parallèles
• Le lancement et l'observation passent par la CLI

«

Pour les modèles, générer du yaml selon un json-schema strict est un ordre de grandeur plus simple ».

Pourquoi l'event sourcing

Ce qui distingue avant tout zymi des frameworks d'agents plus courants, ce ne sont pas seulement les configurations, mais l'architecture sous le capot. Au lieu d'une mémoire partagée que les agents modifient au fil de l'exécution, zymi utilise un bus de données unique. Chaque action est inscrite en base de données sous forme d'événement immuable, avec une vérification par hash-chain. Le résultat n'est pas un simple log, mais un historique d'exécution reproductible : on peut voir quelle étape a démarré, quel outil a été appelé, ce que l'agent a tenté d'écrire en mémoire et à quel moment le système a exigé une validation humaine.

Cette architecture s'appuie sur un travail récent, ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering, que l'auteur cite parmi ses principales sources d'inspiration. Le principe : l'agent ne modifie pas l'état directement, il exprime d'abord une intention d'agir. Cette intention passe ensuite par un moniteur, qui peut autoriser l'action, la rejeter ou demander une approval. Dans l'exemple de l'article, c'est ainsi qu'est traitée une tentative d'écrire le rapport final dans un répertoire absent de la liste autorisée. Cette approche rend le comportement des agents beaucoup plus transparent : l'équipe voit non seulement le résultat, mais aussi la raison de chaque étape.

Quelle suite pour le projet

L'auteur l'écrit sans détour : zymi est encore en alpha et se conçoit comme un outil de prototypage et d'expérimentation. Le projet affiche pourtant déjà un backlog conséquent : migration vers libsql avec mémoire vectorielle et répliques edge, prise en charge de PostgreSQL comme bus de données, branchement déclaratif d'outils Python, amélioration des projections de dialogues pour des relances idempotentes et streaming des réponses des LLM. L'auteur veut aussi comparer un même pipeline d'agents sous LangGraph et sous zymi, afin de vérifier lequel exige le moins d'itérations et de tokens.

Si cette expérience confirme l'hypothèse, zymi pourrait s'avérer non pas un énième « framework pour agents », mais une tentative d'importer dans l'agentic AI la discipline du data engineering : dépendances explicites, reproductibilité, événements vérifiables et moins de magie manuelle. Pour l'heure, il s'agit davantage d'un manifeste d'ingénieur que d'une plateforme mature. Mais ce sont souvent ce type de projets qui fixent un nouveau vocabulaire pour penser des systèmes agentiques fiables, au moment où les expérimentations commencent à passer en production.

Ce que cela signifie

Le marché des agents IA délaisse progressivement les scripts improvisés au profit de systèmes d'orchestration plus rigoureux. L'intérêt de zymi est de proposer d'envisager les agents comme des pipelines de données : assemblage déclaratif, audit des actions et contrôle des opérations dangereuses. Pour les équipes qui tiennent à la reproductibilité et à l'observabilité, il pourrait constituer une alternative notable aux approches stateful habituelles.