El framework zymi propone construir agentes de IA como un proyecto dbt, con YAML y event sourcing

Habr ha publicado un análisis de zymi, un framework experimental para construir sistemas multiagente al estilo de dbt. En lugar de la orquestación manual y de un estado mutable compartido, el autor propone configuraciones YAML declarativas y un bus event-sourced en el que cada paso del agente queda registrado como un evento independiente.

Cómo funciona zymi

La idea de zymi nació de un problema muy práctico. El autor llegó al desarrollo de agentes desde la ingeniería de datos e intentó montar esquemas típicos con LangGraph, pero pronto chocó con el problema del estado mutable compartido: hay que actualizarlo constantemente, depurarlo y analizarlo a través de los logs. Como respuesta surgió otro enfoque: describir no cómo deben avanzar los agentes paso a paso, sino qué debe hacer el sistema. Es una referencia directa a dbt, donde el desarrollador declara las transformaciones y el motor se encarga de ejecutarlas en el orden correcto.

En zymi, un proyecto básico se organiza en entidades conocidas: agentes, herramientas, memoria, pipelines y un archivo común project.yml. El ejemplo de demostración incluye dos agentes, un investigador y un redactor, y el pipeline se define como un DAG: un par de pasos pueden arrancar en paralelo, mientras que los siguientes dependen de depends_on. Las herramientas también se describen de forma declarativa, por ejemplo como llamadas HTTP con parámetros y claves tomadas de variables de entorno. Según el autor, esto es precisamente lo que hace el sistema más cómodo para los LLM: a los modelos les resulta mucho más fácil generar YAML siguiendo un esquema estricto que escribir código de orquestación frágil.

• Los agentes se describen en archivos YAML
• Las herramientas pueden conectarse como llamadas HTTP
• Los pipelines se construyen como DAG con pasos en paralelo
• La ejecución y la monitorización se hacen desde la CLI

«Para los modelos, generar yaml a partir de un esquema json estricto

es un orden de magnitud más sencillo».

Para qué sirve el event sourcing

La principal diferencia de zymi frente a los frameworks de agentes más habituales no está solo en las configuraciones, sino también en la arquitectura interna. En lugar de una memoria compartida que los agentes modifican sobre la marcha, utiliza un bus de datos único. Cada acción se guarda en la base de datos como un evento inmutable, con verificación mediante hash-chain. El resultado no es un simple log, sino un historial de ejecución reproducible: se puede ver qué paso se inició, qué herramienta se llamó, qué intentó escribir el agente en memoria y en qué punto el sistema pidió confirmación a una persona.

Este esquema se basa en el reciente trabajo ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering, que el autor considera una de sus principales fuentes de inspiración. La lógica es la siguiente: el agente no modifica el estado directamente, sino que primero expresa su intención de hacer algo. Después, esa intención pasa por un monitor que puede permitir la acción, rechazarla o solicitar un approval. En el ejemplo del artículo, así se gestiona un intento de escribir el informe final en un directorio que no figura en la lista de permitidos. Este enfoque hace mucho más transparente el comportamiento de los agentes: el equipo ve no solo el resultado, sino también el motivo de cada paso.

Próximos pasos del proyecto

El autor reconoce abiertamente que zymi sigue en fase alfa y que lo concibe como una herramienta para prototipos y experimentos. Aun así, el proyecto ya tiene un backlog considerable: migración a libsql con memoria vectorial y réplicas edge, soporte de PostgreSQL como bus de datos, conexión declarativa de herramientas en Python, mejoras en las proyecciones de diálogos para permitir reinicios idempotentes y streaming de las respuestas de los LLM. Además, el autor quiere comparar un mismo pipeline de agentes en LangGraph y en zymi para comprobar con cuál hacen falta menos iteraciones y tokens.

Si el experimento confirma la hipótesis, zymi podría ser algo más que otro «framework para agentes»: un intento de trasladar al agentic AI la disciplina de la ingeniería de datos, con dependencias explícitas, reproducibilidad, eventos verificables y menos magia manual. Por ahora se parece más a un manifiesto de ingeniería que a una plataforma madura, pero son precisamente este tipo de proyectos los que suelen fijar un nuevo lenguaje para debatir cómo deben ser los sistemas de agentes fiables cuando los experimentos empiezan a llegar a producción.

Qué significa

El mercado de agentes de IA está pasando poco a poco de los scripts improvisados a sistemas de orquestación más rigurosos. Lo interesante de zymi es que propone tratar a los agentes como pipelines de datos: con construcción declarativa, auditoría de acciones y control de las operaciones peligrosas. Para los equipos que priorizan la reproducibilidad y la observabilidad, puede convertirse en una alternativa notable a los enfoques stateful habituales.