Graph Engineering: Coordinating Specialized Agents
When one agent is not enough, the question becomes who does what, in what order, and what happens when a step fails. Graph engineering is how that gets specified.
Verdeshell Team · 6 min read · Last reviewed
Each agent is a node with a defined role. You specify the order work moves in and how agents hand results to each other — including the feedback edges for when a step fails.
What it is
Graph engineering describes several specialized agents coordinating as a graph. Each agent is a node with one defined role. Each edge defines where work moves next and how results hand off.
The feedback edge is what distinguishes this from a pipeline. Failing work loops back to an earlier node rather than falling out of the end, which means the structure encodes recovery and not just the happy path.
The classic three-node example
A product agent grooms and structures the tasks. An engineering agent implements each one. A QA agent tests the implementation.
When QA fails a task, it does not report to a human — it routes back to the engineering agent with the failure attached. That single edge converts three sequential steps into a system that can correct itself.
The mapping to a human team is deliberate and useful: the roles you would assign to people are usually a reasonable first cut at the roles you assign to agents.
What the graph actually governs
Who — which agent owns which role, and therefore which context and tools it needs.
What — the specific work each node performs, narrow enough that success is checkable at the node level.
When — the order and the dependencies between nodes.
Recovery — explicit paths for failure, not only for success. A graph with no feedback edges is a pipeline that will stall the first time reality disagrees with it.
Where it fits alongside loops
The graph is the overall map of specialized agents. Each node, though, typically runs its own internal loop — the engineering agent iterates until its tests pass before handing anything to QA.
So the two patterns are not alternatives. In practice you are building a graph of loops, and confusing the two levels is the most common source of muddled architecture discussions.
When it is the wrong tool
Multi-agent structure has real costs: more moving parts, more places for context to be lost at a handoff, and a much harder debugging story when something goes wrong three nodes deep.
If one well-built loop with good tool access can do the job, that is the better system. Reach for a graph when the roles genuinely differ in the context, tools or judgement they need — not because multiple agents sound more capable than one.
1. Groom — The product agent turns a raw request into a task with acceptance criteria the other agents can act on.
Read this walkthrough as text
- 1.Groom — The product agent turns a raw request into a task with acceptance criteria the other agents can act on.
- 2.Hand off — The groomed task moves along an edge. The edge is the design decision: it says where work goes next.
- 3.Implement — The engineering agent implements it, running its own internal loop until its own tests pass.
- 4.Fail — QA rejects it. The failure routes back to engineering along a feedback edge — no human is woken up.
- 5.Fix — Engineering picks the task back up with the failure attached and corrects it. This edge is what makes it a graph rather than a pipeline.
- 6.Ship — Second time through, QA passes it and the task ships. The system corrected itself.
Want this built properly?
We design and run these systems for clients. Tell us the problem and we will tell you whether an agent is the right shape for it.