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

En Habr apareció un análisis de zymi — un framework experimental para construir sistemas multi-agente al estilo de dbt. En lugar de orquestación manual y estado mutable compartido, el autor propone configuraciones YAML declarativas y un bus event-sourced, donde cada paso de un agente se registra como un evento separado.

Cómo Funciona zymi

La idea de zymi surgió de un dolor bastante práctico. El autor llegó al desarrollo de agentes desde data engineering e intentó ensamblar patrones típicos en LangGraph, pero rápidamente se topó con el problema del estado mutable compartido: necesita ser constantemente actualizado, depurado y analizado a través de registros. En respuesta, surgió un enfoque diferente — describir no cómo los agentes se mueven por pasos, sino qué debería lograr el sistema. Esta es una referencia directa a dbt, donde un desarrollador declara transformaciones y el motor las ejecuta en el orden correcto.

En zymi, un proyecto básico se divide en entidades familiares: agentes, herramientas, memoria, pipelines y un archivo project.yml común. En el ejemplo de demostración, hay dos agentes — un investigador y un escritor, y el pipeline en sí está estructurado como un DAG: un par de pasos pueden comenzar en paralelo, y los posteriores dependen de depends_on. Las herramientas también se describen declarativamente, por ejemplo como llamadas HTTP con parámetros y claves de variables de entorno. El autor argumenta que esto es precisamente lo que hace el sistema más conveniente para LLMs: los modelos son significativamente más simples para generar YAML según un esquema estricto que para escribir código de orquestración frágil.

• Los agentes se describen mediante archivos YAML
• Las herramientas se pueden conectar como llamadas HTTP
• Los pipelines se ensamblan en un DAG con pasos paralelos
• La ejecución y el monitoreo ocurren a través de CLI

"Generar yaml según un json-schema estricto para modelos es órdenes de

magnitud más simple".

Por Qué se Necesita Event Sourcing

La diferencia clave de zymi respecto a frameworks de agentes más familiares — no solo configuraciones, sino la arquitectura bajo el capó. En lugar de memoria compartida que los agentes mutan mientras trabajan, se utiliza un bus de datos unificado. Cada acción se registra como un evento inmutable en una base de datos, completo con verificación hash-chain.

El resultado no es solo un registro, sino un historial de ejecución reproducible: puedes ver qué paso comenzó, qué herramienta fue llamada, qué intentó escribir el agente en la memoria y dónde el sistema solicitó aprobación de un humano. Este enfoque se basa en el artículo reciente ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering, que el autor llama una de las principales fuentes de inspiración. La lógica es la siguiente: un agente no cambia el estado directamente, sino que primero expresa una intención de hacer algo.

Luego esta intención pasa por un monitor, que puede aprobar la acción, rechazarla o solicitar aprobación. En el ejemplo del artículo, así es exactamente cómo se maneja el intento de escribir el informe final en un directorio fuera de la lista permitida. Este enfoque hace el comportamiento del agente mucho más transparente: el equipo ve no solo el resultado, sino la razón de cada paso.

Qué Sigue para el Proyecto

El autor afirma directamente que zymi está actualmente en alfa y se percibe como una herramienta para prototipado y experimentación. Al mismo tiempo, el proyecto ya tiene un gran backlog: migración a libsql con memoria vectorial y réplicas edge, soporte de PostgreSQL como bus de datos, conexión declarativa de herramientas Python, refinamiento de proyecciones de diálogo para reinicializaciones idempotentes y streaming de respuestas LLM. Por separado, el autor quiere comparar el mismo pipeline de agentes en LangGraph y zymi para verificar dónde se necesitarán menos iteraciones y tokens.

Si este experimento confirma la hipótesis, zymi podría ser no solo otro "framework de agentes", sino un intento de llevar la disciplina de data engineering a la IA agéntica: dependencias explícitas, reproducibilidad, eventos verificables y menos magia manual. Por ahora, esto es más un manifiesto de ingeniería que una plataforma madura, pero tales proyectos a menudo establecen un nuevo lenguaje para discutir cómo deberían verse los sistemas de agentes confiables cuando los experimentos comienzan la transición a producción.

Lo Que Esto Significa

El mercado de agentes de IA se está alejando gradualmente de scripts improvisados hacia sistemas de orquestación más rigurosos. zymi es interesante porque propone ver los agentes como pipelines de datos: con ensamblaje declarativo, auditoría de acciones y control de operaciones peligrosas. Para equipos que valoran la reproducibilidad y la observabilidad, esto podría convertirse en una alternativa notable para los enfoques stateful familiares.