Back to posts Aug 8, 2026
The simplest agent graph is a pipeline Why I built axi-factorio to see repeated work, debug each step, tune its prompts, and track whether the process improves.
ai agents developer tools workflows
Agent software is currently explained through two fashionable shapes. A loop gives a model a goal and tools, lets it act, inspects the new state, then repeats until it is done. A graph is the flowchart version: several possible steps, with lines describing what may run next.
Most of that is familiar software wearing new language. The useful part is deciding where the model should stop improvising. Work is already a loop: research produces notes, development produces patches, publishing produces drafts. Each pass emits some blob. Once it exists, that blob should usually move through a deterministic pipeline with named stages, bounded model calls, explicit gates, and receipts you can inspect.
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
A pipeline is the smallest useful graph. CI/CD already moves code through build, test, staging, and deployment. axi-factorio extends the same shape further left: define the work, research it, build a review surface, implement it, review it, merge it, and test what actually landed. The model can work inside a stage; ordinary code owns the route between stages.
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 stage it must pass through. A step is defined by ordinary Markdown prompts in Git, and every attempt leaves a receipt tied to the exact instructions that produced it. If unrelated items keep failing at one stage, the view shows one broken machine instead of several disconnected task histories.
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.
