03.13Framework
Graph engineering for multi-agent systems
Graph engineering for AI agent orchestration as AR Labs applies it: nodes, edges, state, routers and gates, and how our coding pipeline follows them.
On this page
Graph engineering treats an agent workflow as an explicit map of bounded units of work and the real dependencies between them, instead of a straight line of steps hidden inside one model's loop. AR Labs adopted the model from an August 2026 article by the writer rari as the reference specification for its multi-agent orchestration framework, which is built from the Beads task graph and the coding pipeline. Adopt it when one agent's loop has grown too long to follow, or when steps wait on each other for no reason.
The problem it addresses
Most agent systems are built as a line: research, write, review, ship. Each step waits on the last even when it never needed the previous result. The line does not branch, run in parallel or recover; it feeds one context window until the agent is slow, confused or expensive. In the article's words, the problem is no longer the prompt but the shape of the work.
The model
| Term | Meaning |
|---|---|
| Node | One bounded unit of work: an agent, a tool call, a deterministic function, a verifier or a human approval |
| Edge | A real dependency: node A produced data that node B consumes |
| State | The data that survives between nodes |
| Router | The rule that selects the next edge |
| Gate | The check that decides whether work may continue |
Four shapes cover almost every graph. The two that are easiest to get wrong are drawn here:
flowchart LR
subgraph Diamond
S["Split"] --> X["Branch 1"]
S --> Y["Branch 2"]
X --> J["Join"]
Y --> J
end
subgraph Cycle
W["Work"] --> V{"Verify"}
V -->|"feedback, capped"| W
V -->|"pass"| Done["Continue"]
endThe chain runs A, B, C when each step needs the last. The diamond fans independent branches out and merges them, and is the workhorse for research and review. The router classifies the task and takes only the path it needs, so small work stays cheap and risky work gets a deeper graph. The controlled cycle runs work, verify, feedback, with a hard stop, a budget and a convergence rule.
The rules
- Sequence is not dependency. If B does not read A's output, B should not wait. Cut the edge.
- Every node has a contract: one job, explicit input, structured output, a clear failure state. Contracts make nodes replaceable.
- Edges are data contracts. Plumbing such as deduplication, filtering and joins is deterministic code, not another model call. Save model calls for judgement.
- Fan out independent work and join deliberately, only where the next node needs the complete set.
- Routing is inspectable. The model may judge; the graph decides what that judgement is allowed to trigger.
- Verification sits on the edge. Never let one agent generate, approve and publish its own work in one context.
- State is what diagrams hide. A real graph records the task, its current node, completed nodes, artefacts, decisions, evidence, budgets, retries and approvals, and passes references to artefacts rather than transcripts.
- Cycles must converge, with a completion test, a maximum number of rounds, a budget, a record of earlier attempts and an escalation path.
- Failure is local. Each node has a policy: retry, fall back, skip, repair, escalate or stop. Checkpoint after expensive nodes and make writes idempotent.
- Topology is the cost model. Spend coordination only where parallelism, specialisation or independent verification earns it.
The article's own test: keep one agent in one loop when the task is short, fits one context, has no independent branches and fails cheaply. "Start with one loop. Draw a graph only when the dependencies force you to."
How our pipeline maps onto it
The coding pipeline was largely built before the article, and the article gave us a vocabulary to check it against. The correspondences are direct:
| Graph concept | In our pipeline |
|---|---|
| Node | A bead: a lone task, a container or a leaf |
| Edge | A blocking edge in Beads; a bead starts only when its blockers close |
| State | Namespaced metadata on each bead, written by one transition script; a crashed session loses nothing |
| Router | The task-or-campaign decision, and the leaf-or-compound classification at the spec step |
| Gate | Floors (scripted proofs) and human gates on each step |
| Verification on the edge | Cross-model review in a fresh context before code may land |
| Converging cycle | One automatic fix round after a failed review, then the task rests for a person; three failed attempts park it |
| Failure policy | Refuse (work is owed) versus escalate (the machinery cannot answer) |
What exists today
The pipeline described on its own page runs today. The broader orchestration framework built on the same model is in design, with the article as its reference specification.
The checklist
The article closes with a checklist we use when reviewing a workflow design:
[ ] Does every edge carry real data or authority?
[ ] Does every node have one bounded job?
[ ] Are inputs and outputs structured?
[ ] Can independent nodes run in parallel?
[ ] Are joins placed only where the full set is required?
[ ] Are important results verified before moving downstream?
[ ] Can failures be retried without duplicating side effects?
[ ] Can the graph resume from a checkpoint?
[ ] Does every cycle have a hard stop and budget?
[ ] Can a human interrupt high-risk paths?
[ ] Can you explain why every route was selected?
[ ] Is the graph simpler than the problem it solves?If the answer to the last question is no, delete nodes.
Referenced by 07
- ProjectsVOX OS: personal AI operating system architecturelinks here in its text
- ConceptsThe harness paradoxlinks here in its text
- ConceptsThe intelligence is in the orderinglinks here in its text
- EngineeringHow AR Labs engineers software with AI coding agentslinks here in its text
- EngineeringTask graphs for AI coding agents with Beadslists this as related
- SkillsSVG diagrams: Claude Code skill for architecture diagramslists this as related
- ResearchAI agent orchestration driver: reconciliation loops versus eventslists this as related