Why ZipperGen

ZipperGen aims to make it easier to turn an agent workflow into a running service. It brings workflow code, saved state, human approvals, and deployment into one Python framework. You can run it on your own machine or server.

From writing to running

You write the workflow and the actions it calls. You configure the models, external services, and approval channels it needs. The CLI then checks the project and deploys it as a service. Once it is running, the same CLI shows its status, logs, and pending approvals.

The runtime saves workflow state so a service can resume after a restart. Calls to external services still need care because a crash can cause an action to run again. The storage guide explains what is saved and how recovery works.

Why one workflow?

The global workflow says who sends what to whom, who calls a model, and who owns each decision. ZipperGen derives the program for each participant from that description. Each program contains only the work and communication that participant needs.

This gives you one place to read and review the coordination. Human decisions and calls to external services are visible in the workflow. You can write it yourself or ask a coding agent to help. Either way, the result is Python code in an ordinary project directory.

Where it comes from

The projection is based on Message Sequence Charts and choreographic programming, adapted to LLM agents, tool calls and human approval. For well-formed workflows covered by the formal model, the generated programs cannot deadlock. The core theorem is machine-checked in Lean 4.

Causal Past Logic (CPL) adds guards that check earlier events and values that are causally visible at a decision. The README explains the scope of the formal results. The code, examples, and tests are also on GitHub.