zymi framework builds AI agents like a dbt project, with YAML and event sourcing

A new Habr post breaks down zymi, an experimental framework for building multi-agent systems in the style of dbt. Instead of manual orchestration and shared mutable state, the author proposes declarative YAML configs and an event-sourced bus that records every agent step as a separate event.

How zymi works

zymi grew out of a very practical pain point. The author came to agent development from data engineering and tried to build standard patterns in LangGraph, but quickly ran into the problem of shared mutable state: it has to be constantly updated, debugged, and picked apart through logs. The answer was a different approach: describe what the system should do, not how agents should step through the work. That is a direct nod to dbt, where developers declare transformations and the engine runs them in the right order.

A basic zymi project breaks down into familiar pieces: agents, tools, memory, pipelines, and a shared project.yml file. The demo example has two agents, a researcher and a writer, and the pipeline itself is a DAG: a couple of steps can start in parallel, while later ones depend on depends_on. Tools are also defined declaratively, for example as HTTP calls with parameters and keys pulled from environment variables. The author argues that this is exactly what makes the system friendlier to LLMs: models find it much easier to generate YAML against a strict schema than to write brittle orchestration code.

• Agents are defined in YAML files
• Tools can be plugged in as HTTP calls
• Pipelines are assembled into DAGs with parallel steps
• Runs are launched and monitored through a CLI

"Generating yaml against a strict json schema is an order of magnitude

easier for models."

Why event sourcing

What sets zymi apart from more familiar agent frameworks is not just the configs but the architecture underneath. Instead of shared memory that agents mutate as they work, zymi uses a single data bus. Every action is written to a database as an immutable event, with hash-chain verification. The result is more than a log: it is a reproducible execution history. You can see which step started, which tool was called, what an agent tried to write to memory, and where the system asked a human for confirmation.

The design draws on a recent paper, ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering, which the author cites as one of the key sources of ideas. The logic works like this: an agent does not change state directly. It first expresses an intent to do something. That intent then passes through a monitor, which can allow the action, reject it, or request approval. In the article's example, this is exactly how the system handles an attempt to write the final report to a directory outside the allowlist. This approach makes agent behavior far more transparent: the team sees not only the result but the reason behind each step.

What's next for the project

The author states plainly that zymi is still in alpha and should be seen as a tool for prototyping and experimentation. Even so, the project already has a sizable backlog: a move to libsql with vector memory and edge replicas, support for PostgreSQL as a data bus, declarative wiring of Python tools, improved conversation projections for idempotent restarts, and streaming of LLM responses. Separately, the author wants to compare the same agent pipeline built in LangGraph and in zymi to see which one needs fewer iterations and tokens.

If that experiment confirms the hypothesis, zymi may turn out to be more than yet another "agent framework." It would be an attempt to bring data engineering discipline into agentic AI: explicit dependencies, reproducibility, verifiable events, and less hand-rolled magic. For now it reads more like an engineering manifesto than a mature platform, but projects like this often set the vocabulary for discussing what reliable agent systems should look like as experiments start moving into production.

What it means

The AI agent market is gradually moving away from improvised scripts toward stricter orchestration systems. zymi is interesting because it treats agents as data pipelines, with declarative assembly, action auditing, and control over risky operations. For teams that care about reproducibility and observability, it could become a notable alternative to the usual stateful approaches.