Graph engineering is the practice of designing the organisation of many AI agents as an explicit, programmable structure — nodes, typed edges and shared state — instead of programming one agent’s behaviour cycle. Where a loop controls what a single agent does, a graph controls how many agents divide work, pass it between each other, and converge.
The term began circulating in July 2026, roughly a month after “loop engineering” entered the vocabulary. Both describe the same shift: as agents became able to run unattended for hours, the bottleneck stopped being model capability and became the design of the system around the model.
Three layers, not three techniques
Prompt, loop and graph are often discussed as if one replaces the last. They stack: each is a different unit of control, and a graph is made of loops the way a loop is made of prompts.
Each is a different unit of control, and none of them replaces the one inside it. A graph is made of loops the way a loop is made of prompts — teams tend to adopt them in that order, and hit the limits of each in that order too.
01Prompt engineering
One model response
What do I say?
A single call. Structure, context, and the instruction itself.
02Loop engineering
One agent’s behaviour cycle
What system finds the work, does it, verifies it, and remembers it?
A trigger, a verifiable goal, the available actions, a verification step, and memory that survives iterations. The cycle is the easy part — the stop condition is not.
03Graph engineering
The organisation of many agents
How does work split, move between agents, and come back together?
Declared nodes and typed edges over shared state. Context does not cross a node boundary unless an edge carries it, and parallel branches need defined convergence points.
What a graph is made of
Five parts, each of which is where a multi-agent system usually breaks first. Two of them are structures that run at the same time and are easy to conflate:
Conflating the two is the common failure: a system built only on the org graph cannot re-plan, and one built only on the work graph has no stable roles to hold accountable.
An org graph, and a work graph
Two structures run at once and are easy to conflate. The org graph is stable — long-lived agents in named roles, one per service or domain. The work graph is ephemeral — task nodes that split, merge and disappear as evidence arrives. Confusing them produces a system that either cannot re-plan or cannot be reasoned about.
Edges that carry context deliberately
The defining constraint is that context does not cross a node boundary unless an edge carries it. That is what makes a graph auditable rather than a group chat: every piece of information one agent gave another is a recorded, replayable transfer rather than an implicit shared history.
Convergence points
Parallel branches have to meet. Without an explicit barrier, agents build against a contract that is still being negotiated on another branch — and the failure surfaces late, as a merge conflict or a broken integration, rather than early as a wait.
A stop condition that is mechanical
Inherited from loop engineering and made worse by parallelism. A run that ends when tokens run out is not finished, it is abandoned. Completion needs a check the system performs — tests, a review step, an explicit human decision — not a model’s opinion that it is done.
Durable state
Multi-agent work spans hours or days and crosses human decisions. The structure has to survive a restart, a retry, and a person going home for the weekend without repeating a step that already had side effects.
How PlatformSmith implements it
The vocabulary is new; the problems are not. Each row is a part of the graph above and the mechanism that carries it.
Org graph
A playbook declares its participant roster up front — one agent per service, each running the coding agent that team already uses.
Work graph
Work items carry their own dependency graph, so a decomposition is a structure the system can traverse rather than a checklist a person maintains.
Typed edges
Agents do not talk peer to peer. Every message between them is routed through the platform, which is what makes the conversation a record you can replay afterwards.
Convergence
Barriers hold the group until the contract between services is agreed, so nobody builds against a shape that is about to change.
Stop condition
Approval gates are explicit nodes. A run parks at one for up to seven days without losing its place, and resumes where it stopped.
Durability
Sequencing runs on a durable workflow engine with retries and exactly-once execution, so a flaky step never becomes a duplicate change.
Common questions
What is graph engineering?
Graph engineering is the practice of designing the organisation of many AI agents as an explicit, programmable structure — nodes, typed edges and shared state — instead of programming one agent’s behaviour cycle. Where a loop controls what a single agent does, a graph controls how many agents divide work, pass it between each other, and converge.
What is the difference between loop engineering and graph engineering?
A loop controls one agent’s behaviour cycle — how it finds work, does it, verifies it and remembers it. A graph controls how many agents are organised: which nodes exist, which edges carry context between them, and where parallel branches converge. They stack rather than compete; a graph is made of loops.
Why is orchestrating multiple coding agents hard?
Three reasons that only appear at more than one agent. Context does not cross between agents unless something deliberately carries it. Parallel branches need explicit convergence points or they build against contracts that are still changing. And a run that spans a human decision has to survive hours or days without repeating steps that already had side effects.
Do I need a framework for graph engineering?
A framework gives you the graph primitives — nodes, edges, state. What most teams find missing is everything around them: durable execution across a human decision, an audit trail of what each agent did, and running against real services rather than a clean-room sandbox. Those are platform concerns rather than framework concerns.
Which coding agents does PlatformSmith orchestrate?
Claude Code and Codex today. You can mix them across teams — one service’s agent can be Claude Code while another’s is Codex, inside the same run.
Where does the code run?
Inside your own cloud or data centre. Agents work in your own container image against the real service, rather than in a reconstruction of it, and one outbound connection is the whole network requirement.
See a graph run across five services.
Thirty minutes, a real multi-service change, nothing pre-recorded.