zymi framework proposes building AI agents like a dbt project with YAML and event sourcing

On Habr, there was a review of zymi — an experimental framework for building multi-agent systems in the spirit of dbt. Instead of manual orchestration and shared mutable state, the author proposes declarative YAML configs and an event-sourced bus, where each step of an agent is recorded as a separate event.

How zymi Works

The idea of zymi grew out of a quite practical pain point. The author came to agent development from data engineering and tried to assemble typical patterns on LangGraph, but quickly ran into the problem of shared mutable state: it needs to be constantly updated, debugged, and parsed through logs. In response, a different approach emerged — describe not how agents move through steps, but what the system should accomplish. This is a direct reference to dbt, where a developer declares transformations and the engine executes them in the correct order.

In zymi, a basic project breaks down into familiar entities: agents, tools, memory, pipelines, and a common project.yml file. In the demonstration example, there are two agents — a researcher and a writer, and the pipeline itself is structured as a DAG: a pair of steps can start in parallel, and subsequent ones depend on depends_on. Tools are also described declaratively, for example as HTTP calls with parameters and keys from environment variables. The author argues that this is precisely what makes the system more convenient for LLMs: models are significantly simpler to generate YAML according to a strict schema than to write fragile orchestration code.

• Agents are described by YAML files
• Tools can be plugged in as HTTP calls
• Pipelines are assembled into a DAG with parallel steps
• Execution and monitoring happen via CLI

"Generating yaml according to a strict json-schema for models is

orders of magnitude simpler".

Why Event Sourcing Is Needed

The key difference of zymi from more familiar agent frameworks — not just configs, but the architecture under the hood. Instead of shared memory that agents mutate as they work, a unified data bus is used. Each action is recorded as an immutable event in a database, complete with hash-chain verification.

The result is not just a log, but a reproducible execution history: you can see which step started, which tool was called, what the agent attempted to write to memory, and where the system requested approval from a human. This approach is grounded in the recent paper ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering, which the author calls one of the key sources of inspiration. The logic is this: an agent doesn't change state directly, but first expresses an intention to do something.

Then this intention passes through a monitor, which can approve the action, reject it, or request approval. In the example from the article, this is exactly how the attempt to write the final report to a directory outside the permitted list is handled. This approach makes agent behavior much more transparent: the team sees not only the result, but the reason for each step.

What's Next for the Project

The author directly states that zymi is currently in alpha and is perceived as a tool for prototyping and experimentation. At the same time, the project already has a large backlog: migration to libsql with vector memory and edge replicas, PostgreSQL support as the data bus, declarative connection of Python tools, refinement of dialog projections for idempotent restarts, and streaming LLM responses. Separately, the author wants to compare the same agent pipeline on LangGraph and zymi to check where fewer iterations and tokens will be needed.

If this experiment confirms the hypothesis, zymi could be not just another "agent framework", but an attempt to bring the discipline of data engineering to agentic AI: explicit dependencies, reproducibility, verifiable events, and less manual magic. For now, this is more of an engineering manifesto than a mature platform, but such projects often set a new language for discussing how reliable agent systems should look when experiments start transitioning to production.

What This Means

The AI-agent market is gradually moving away from improvised scripts toward stricter orchestration systems. zymi is interesting because it proposes viewing agents as data pipelines: with declarative assembly, action auditing, and control of dangerous operations. For teams that value reproducibility and observability, this could become a notable alternative to familiar stateful approaches.