Skip to main content

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.

A schematic: start node, work nodes, a diamond router splitting the route, a striped gate before the end, over a shared state tape.A schematic graph: a start node, two bounded work nodes, a diamond router that splits the route, and a striped gate before the end, all reading from a shared state tape.FRAMEWORK03.12MAKE THEMAP EXPLICITDRAWINGENG-03.12SUBJECTgraph engineeringSHEET12 OF 26 · AR LABSWORKROUTEWORKGATES T A T E
On this page
  1. The problem it addresses
  2. The model
  3. The rules
  4. How our pipeline maps onto it
  5. What exists today
  6. The checklist

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:

FIG. 01
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"]
  end

The 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

  1. Sequence is not dependency. If B does not read A's output, B should not wait. Cut the edge.
  2. Every node has a contract: one job, explicit input, structured output, a clear failure state. Contracts make nodes replaceable.
  3. Edges are data contracts. Plumbing such as deduplication, filtering and joins is deterministic code, not another model call. Save model calls for judgement.
  4. Fan out independent work and join deliberately, only where the next node needs the complete set.
  5. Routing is inspectable. The model may judge; the graph decides what that judgement is allowed to trigger.
  6. Verification sits on the edge. Never let one agent generate, approve and publish its own work in one context.
  7. 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.
  8. Cycles must converge, with a completion test, a maximum number of rounds, a budget, a record of earlier attempts and an escalation path.
  9. Failure is local. Each node has a policy: retry, fall back, skip, repair, escalate or stop. Checkpoint after expensive nodes and make writes idempotent.
  10. 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.