Graph engineering: the missing graph is the one that remembers
In two lines: you will learn what execution and task graphs solve, what they leave out, and how a third graph keeps state, decisions and lessons. You will also see how the loom is organised and how it fits into ordinary work.
The two fashionable graphs
The execution graph splits a large job into pieces, runs them in parallel and has reviewers who did not see the work check each piece. It is fast and useful while the job is running. When it ends, however, the graph disappears: it keeps no record of what was decided, why, or what failed.
The task graph expresses dependencies, several metrics and a checklist with a human step before something counts as finished. It is a good plan. It does not keep what was learned once the plan is no longer needed.
The problem that put these techniques into circulation was concrete: someone spending about a million dollars a month on tokens found that parallel agents were working from stale information and getting in each other’s way. Drawing the graph better does not solve that. Shared memory does.
The third graph: the loom
I call it the loom because everything is woven on it. It is an ordinary MySQL database with five node types and seven relation types, plus a one-file CLI to read and write it. No vectors, frameworks or resident process.
The five node types cover the pieces a job needs:
- Work item: something to do, with a lifecycle (pending → open → blocked → closed) and a dated log.
- Resource: a machine, application, account or panel, with lines for access, usage and state.
- Procedure: a repeatable task described step by step and ending in a check.
- Rule: a criterion that must always hold, such as never closing a listing by silence or moving anything to production without approval.
- Person: who is who, what they operate and how to reach them.
The relations say, for example, that a work item uses a server, follows a procedure or is blocked by a person or another work item. When the blocker closes, the blocked item is released automatically.
Log lines have a type: order, action, result, decision and verification. That detail lets you answer “why was this done?” weeks later with a dated line marked decision.
Three pieces complete the design: a guard that requires an active work item and its loaded rules; an encrypted vault for passwords and keys, requested by name; and a monthly pruning of what no longer serves.
How it is used on an ordinary day
- Start. The AI opens a session and asks for the queue: pending work items, urgent ones first, and reminders due that day.
- Reserve. One command takes the work item until 17:00 and writes that fact into the work item itself. It then gathers the order, last action, resources and their access details, the procedure and applicable rules.
- Work by writing. Every relevant step leaves a line such as “action: checked X” or “decision: doing Y because Z”. If a procedure is missing or wrong, it is created or corrected then. A work item is not closed until the knowledge it produced is in the loom.
- Close. The mandatory result is written and the work item is closed. The next session will find what was learned there.
Execution graphs live inside step 3: when a job is large, you can set up a temporary graph with batches, a cheap model, a validator and reviewers to generate the contents of a guide at scale. When it ends, it is discarded; the loom keeps the result and the lesson.
Three failures the loom recorded
Two AIs opened the same work item. Since then, reserving it marks it as occupied and another session cannot enter. The important protection is that the notice lives beside the task and cannot become stale.
A deployment started from an old snapshot. Between the snapshot and the push, another AI touched the same area. A last-second check stopped it: “is what I am about to push still what is there?” That day the check became mandatory in the deployment procedure.
A metric counted bots. Server hits looked high, but half were bots. Three signals are now checked together, and that decision is written as a rule.
All three cases have the same shape: parallelism with stale information or trust in a single number; then the lesson is written where the next execution will read it.
What the loom takes from the trend
- Mechanical reviewers alongside AI reviewers. A model can be soft on another model; a minimum score computed by a script is harder and cheaper.
- Several metrics by default. What was once done for one thing became a general rule.
In short
| Graph | What it organises | What it keeps when it ends |
|---|---|---|
| Execution | how a job is done | nothing |
| Tasks | what has to be done and in what order | the plan |
| State (the loom) | what is known: decisions, failures, rules, access | everything, with date and reason |
A graph erased at the end is a tool. A graph that remembers is a system: the difference is that today’s knowledge appears tomorrow where the work is done.
— an old programmer · 64 · rss