2026-07-22
The simplest agent graph is a pipeline Why I built axi-factorio: graphs are complicated, pipelines are useful, and each step has a prompt I can keep tweaking.
In agent software, a loop lets a model act and repeat; a graph adds branches between possible steps. Both can get complicated quickly. A pipeline is the simple case: work goes through a fixed sequence.
loops was hot, now graphs is hot, graphs is hard, here's the simplest graph - a pipeline. looks just like CI deployment pipeline extended to dev
CI/CD already moves code through a pipeline from build to test to deployment. axi-factorio extends that shape further left: define the work, research it, implement it, review it, merge it, and test what landed. The model handles one step at a time; the pipeline determines what happens next.
i built it because i need a pipeline view of things i'm working on.
they go thru the same s--- generally every time, and i want to be able to tweak the prompt to get it good, and track some metrics
Each row is a piece of work. Each column is a step it passes through. Every step has its own Markdown prompt and keeps a receipt of what happened. If the result is bad, tweak that prompt and run the step again. Keep doing that until it is good.
this also is needed for eg content i want to xform and republish, but also for dev stuff, which i need always done in the same way fixing the same problems and quirks of the llm
The item can be code, an article, an interview, or a video. The prompts and artifacts change, but the conveyor does not: accept an input, perform a bounded transformation, inspect the result, then advance, retry, or stop.
Beads solves an adjacent issue-tracking problem; axi-factorio makes the production line itself the thing you see and tune.
The AXI part makes the CLI compact and deterministic for agents. The Workbench runs controlled scenarios through the real conveyor so the machinery can be debugged. The next step is comparison: prompt revisions, retries, time, token use, human corrections, and whether changing one station improves every future item that passes through it.
A day after this post's original draft, Uncle Bob described the same trust model from the other end : surround agents with “extreme constraints” such as tests, QA procedures, metrics, mutation testing, and coverage. Those constraints are much easier to trust when they are visible stages with durable receipts rather than instructions buried inside one long agent loop.
Why not Beads?
beads i just couldn't figure out how to fix this mould, because the visual is critical - a pipeline, with s--- going in, and steps i can debug
This was not a drive-by comparison. The first design tried to build axi-factorio on Beads : keep Beads and Dolt as the only durable store, compile pipelines to formulas, add an event-driven runner, and hide Beads' formulas, molecules, step beads, and data beads behind a simpler Factorio vocabulary.
A separate proof ran the same eight-pip pipeline two ways. Eager formula expansion created nine records as soon as one item started; lazy materialisation created two. Beads supplied durable issues and events, IDs, dependency edges, ready queries, graph instantiation, and restart recovery. Factorio still had to supply prompt and pipeline versions, receipts and provenance, human feedback and approval loops, candidate fan-in, deployment policy, supervision, metrics, and the entire pipeline view.
So the problem was not that Beads could not be made to run the pipeline. It was that the simplified format and the visible, debuggable conveyor were another substantial system built over it. For mostly sequential work, TypeScript and SQLite left the production line as the model instead of translating it through an issue graph first.
