Le framework zymi propose de construire des agents AI comme un projet dbt avec YAML et event sourcing

Sur Habr, il y a eu une analyse de zymi — un framework expérimental pour construire des systèmes multi-agents à l'esprit de dbt. Au lieu d'une orchestration manuelle et d'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 séparé.

Comment fonctionne zymi

L'idée de zymi est née d'une douleur tout à fait pratique. L'auteur est venu au développement d'agents depuis l'ingénierie des données et a tenté d'assembler des modèles typiques sur LangGraph, mais s'est rapidement heurté au problème de l'état mutable partagé : il doit être constamment mis à jour, débogage et analysé à travers les journaux. En réponse, une approche différente a émergé — décrire non comment les agents se déplacent par étapes, mais ce que le système devrait accomplir. C'est une référence directe à dbt, où un développeur déclare des transformations et le moteur les exécute dans le bon ordre.

Dans zymi, un projet de base se divise en entités familières : agents, outils, mémoire, pipelines et un fichier project.yml commun. Dans l'exemple de démonstration, il y a deux agents — un chercheur et un écrivain, et le pipeline lui-même est structuré comme un DAG : une paire d'étapes peut démarrer en parallèle, et les suivantes dépendent de depends_on.

Les outils sont également décrits de manière déclarative, par exemple comme des appels HTTP avec des paramètres et des clés provenant de variables d'environnement. L'auteur soutient que c'est précisément ce qui rend le système plus pratique pour les LLM : les modèles sont beaucoup plus simples pour générer du YAML selon un schéma strict que pour écrire un code d'orchestration fragile.

• Les agents sont décrits par des fichiers YAML
• Les outils peuvent être connectés comme des appels HTTP
• Les pipelines sont assemblés dans un DAG avec des étapes parallèles
• L'exécution et la surveillance se font via CLI

"Générer du yaml selon un json-schema strict pour les modèles est des

ordres de magnitude plus simple".

Pourquoi l'Event Sourcing est Nécessaire

La différence clé de zymi par rapport aux frameworks d'agents plus familiers — non seulement les configurations, mais l'architecture sous le capot. Au lieu d'une mémoire partagée que les agents modifient au cours de leur travail, un bus de données unifié est utilisé. Chaque action est enregistrée comme un événement immuable dans une base de données, complète avec vérification hash-chain.

Le résultat n'est pas seulement un journal, mais un historique d'exécution reproductible : vous pouvez voir quelle étape a démarré, quel outil a été appelé, ce que l'agent a tenté d'écrire en mémoire et où le système a demandé l'approbation d'un humain. Cette approche s'appuie sur le récent article ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering, que l'auteur appelle l'une des principales sources d'inspiration. La logique est la suivante : un agent ne change pas directement l'état, mais exprime d'abord l'intention de faire quelque chose.

Ensuite, cette intention passe par un moniteur, qui peut approuver l'action, la rejeter ou demander l'approbation. Dans l'exemple de l'article, c'est exactement comment la tentative d'écrire le rapport final dans un répertoire en dehors de la liste autorisée est traité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.

Qu'y a-t-il de Prévu pour le Projet

L'auteur affirme directement que zymi est actuellement en alpha et est perçu comme un outil de prototypage et d'expérimentation. En même temps, le projet a déjà un grand backlog : migration vers libsql avec mémoire vectorielle et répliques edge, support de PostgreSQL comme bus de données, connexion déclarative des outils Python, affinement des projections de dialogue pour les redémarrages idempotents et streaming des réponses LLM. Séparément, l'auteur souhaite comparer le même pipeline d'agent sur LangGraph et zymi pour vérifier où moins d'itérations et de tokens seront nécessaires.

Si cette expérience confirme l'hypothèse, zymi pourrait être non seulement un autre « framework pour agents », mais une tentative de apporter la discipline de l'ingénierie des données à l'IA agentive : dépendances explicites, reproductibilité, événements vérifiables et moins de magie manuelle. Pour le moment, c'est plutôt un manifeste d'ingénierie qu'une plateforme mature, mais ces projets établissent souvent un nouveau langage pour discuter de comment les systèmes d'agents fiables devraient ressembler lorsque les expériences commencent à faire la transition vers la production.

Ce Que Cela Signifie

Le marché des agents d'IA s'éloigne progressivement des scripts improvisés vers des systèmes d'orchestration plus rigoureux. zymi est intéressant car il propose de voir les agents comme des pipelines de données : avec assemblage déclaratif, audit des actions et contrôle des opérations dangereuses. Pour les équipes qui valorisent la reproductibilité et l'observabilité, cela pourrait devenir une alternative remarquable aux approches stateful familières.