Graph Engineering: Multi-Agent Workflows, Not Chat Chains
Marc GasserSoftware Entrepreneur · GTM & MarketingConnects AI with revenue operations and builds autonomous GTM systems for predictable growth.
TL;DR
- Graph engineering means connecting several agent loops (nodes) through edges – handoffs, shared state, conditions – into one workflow, instead of pressing everything into a single chat chain.
- Anthropic's own multi-agent system beat a single agent by 90.2 per cent – but used roughly 15 times more tokens. The graph is a cost-value decision, not an end in itself.
- Most tasks don't need a graph. It pays off only once work splits into genuinely independent, parallelisable specialities – for tightly coupled work such as coding, a single loop with good context often wins.
Key findings
- The term conflates two different things: knowledge graphs (how facts connect) and agent graphs (how work moves). Mixing the two is why graph engineering feels vague online.
- The term was triggered by a July 2026 tweet from Peter Steinberger (“are we still talking loops or did we shift to graphs yet?”, over 2.8 million views) – it named a shift already under way: from prompt through context and loop engineering to graph engineering.
- Cognition's counter-evidence: on tightly interdependent tasks such as coding, multi-agent setups fracture because subagents don't share the same context. The graph only pays off where independence is real.
What is graph engineering, exactly?
An agent graph connects several specialised AI agents – nodes, each running its own loop of plan, act, verify – through edges: handoffs, shared state, conditions. The graph defines who exists, what each node owns and how work flows between them – sequentially, in parallel or branching on the result.
Where the term comes from. In July 2026, OpenClaw founder Peter Steinberger posted a single question on X: “Are we still talking loops or did we shift to graphs yet?” The tweet pulled in over 2.8 million views and put a new term on the timeline. It joins a chain that started with prompt engineering in 2023 and moved through context engineering, harness engineering and loop engineering – each stage described how a team gets more out of AI: first the question, then the information around it, then the environment, then the iteration. Graph engineering describes the next stage: how several agents work together as an organisation.1
Two meanings, constantly mixed up. The term carries two meanings that get mixed up constantly online. A knowledge graph connects facts – this customer works at this company, this feature belongs to this team – and helps AI reason across scattered data. An agent graph, by contrast, decides how work moves: a planner assigns researchers, a sceptic checks the findings, a human approves. Frameworks such as LangGraph make this second meaning technically concrete: nodes are functions or agents, edges determine the data flow, and a central state is the source of truth for the whole run.4
Where the real value sits. For product leaders, the second meaning is the relevant one. It answers an old question again: where does the value sit once a model can write the code anyway? The answer stays the same as with context engineering before it: the bottleneck isn't the coding. It's everything before and after it – planning, checking, handoff, approval. A graph makes exactly those steps visible and steerable, instead of hiding them inside a single prompt.
When does a graph pay off – and when is a loop enough?
A loop is enough when a task has one clear goal, genuinely sequential steps and a context window that holds the whole thing. A graph pays off once work splits into independent specialities, parallelism saves real time and different steps need different tools or models. The decision comes down to four questions.
Question one: genuine independence? Does the task split into parts that genuinely run in parallel – customer research alongside competitor analysis, not planning alongside building the same feature?
Question two: different tools? Does one step need a different model, tool or permission set than the next – code access for one node, read-only for another, say?
Question three: is a checking instance needed? Does a result need checking before it counts – ideally by a model that didn't write the work itself? The same model that writes and grades tends to grade itself kindly.
Question four: can the run survive a failure? Should the failure of one step not take down the whole run? The more of these four questions get a yes, the more likely a graph earns its own coordination cost.
The cost is real. Not just conceptually: Anthropic's own engineering write-up describes an orchestrator-worker system – a lead agent breaks down a research task and spins up three to five specialised subagents in parallel. In its internal research eval, that setup beat a single agent by 90.2 per cent – at roughly 15 times the token cost, with token usage alone explaining 80 per cent of the performance difference. The rule of thumb transfers directly: a graph pays off when the value of the task exceeds the extra cost of coordination – not because a graph looks more modern than a loop.2
The graph readiness check
Your task has one clear goal and shared context – a graph would only add coordination cost without benefit. Build one good loop with complete context.
Tick what applies to your next AI task – the result shows whether one loop is enough or a graph pays off.
How do you build your first graph without buying new tools?
Draw the graph before you automate it. One lane per role – planner, researcher, sceptic, human – on a board, run through once by hand, shows more than any framework on day one.
Three maturity levels are enough. Level one: manual, each role its own lane on a whiteboard or in Excalidraw, arrows show the handoffs. Level two: file-based, each step writes its own markdown file – a planner produces `plan.md`, researchers fill their own files, a sceptic writes `review.md` –, leaving a traceable paper trail. Level three: orchestrated, with frameworks such as LangGraph for state management, checkpoints and human-in-the-loop approval, or AutoGen's graph flow for conditional branching. The tool comes after the workflow, not before it – an automated process nobody understood just produces mediocre work faster.4
What stays constant across every level is shared context: every node needs the same view of code, tickets and decisions, or it repeats work or contradicts the previous node. That's exactly what the Context Engine behind Teklens' Live View does – it keeps planning, execution and review agents on the same, versioned project knowledge instead of each node re-deriving its own context.
Where multi-agent graphs break
On tightly coupled work such as coding, the graph often backfires. Cognition, the team behind Devin, published a public write-up in 2025 explaining why their coding agent stayed with a single, well-context-fed agent instead of moving to multiple subagents.3
The core argument. Subagents working in parallel on parts of the same problem don't automatically share the same context. One subagent picks framework A, another picks framework B – and nobody notices the contradiction until the code gets merged. On research tasks that's manageable, because results can be summarised at the end. On code that has to compile and fit together, the same mechanism that gave Anthropic's research system a 90 per cent edge becomes a source of errors.
Both pieces of evidence come from teams actually running graphs in production – and they don't contradict each other, they mark a boundary. Independent, parallelisable work carries a graph. Tightly coupled work with shared state carries better on a loop with good context. The task decides, not the trend.
Frequently asked questions
What is graph engineering?
Graph engineering organises several AI agents as a workflow: each agent is a node running its own loop of planning, acting and verifying; edges define handoffs, shared state and conditions. Instead of pressing a task into one long chat chain, a graph spreads it across specialised roles – planner, researcher, sceptic, human.
What is the difference between a loop and a graph?
A loop is a single agent's behavioural contract with itself: trigger, act, verify, repeat if needed. A graph is the organisational structure of several agents that each run their own loop – the edges between them define how work flows across the group.
What is the difference between a knowledge graph and an agent graph?
A knowledge graph connects facts and relationships – who works where, what belongs to what. An agent graph connects work steps – who does what, when, in which order. The strongest systems use both: knowledge the AI reasons over, and a workflow it follows.
Does my team need a multi-agent graph?
Only if at least one of the four decision questions gets a yes: genuine independence between subtasks, different tools per step, a necessary checking step, or tolerance for individual node failures. On tightly coupled work with shared state – most coding tasks, for instance – a single loop with complete context often wins.
Which tools are suited to graph engineering?
For a start, a board with one lane per role – run through once by hand – is enough. For file-based traceability, each step writes its own markdown file. For orchestrated systems with state, checkpoints and human-in-the-loop approval, frameworks such as LangGraph or AutoGen's graph flow fit.
Recommendations
- Start with a loop, not a graph. First check whether a single loop with complete context is enough. Add nodes only once one of the four decision questions gets a yes.
- Draw the graph before you automate it. Roles, arrows, a board – run through once by hand. Automating a structure nobody understands just produces confusion faster.
- Separate workers from checkers. No model reliably grades its own work. A dedicated checking node is mandatory once a result carries real weight.
- Count the coordination cost. A graph costs real tokens. Justify that with the value of the task – not with how current a graph looks.
- Put the human gate on the most expensive step. Approval where a mistake genuinely costs something – deploy, customer communication, architecture decisions. Not on every intermediate step.
- Let every run leave knowledge behind. Notes, evidence and decisions from every graph run land versioned and reusable – that's the real compounding effect of graph engineering.
Scope & caveats
- The 90.2 per cent figure and the 15-times token cost come from Anthropic's internal research eval with Claude Opus as lead agent and Claude Sonnet as subagents – an industry data point from an in-house benchmark, not an independent study.
- Cognition's counter-position concerns coding agents with tight interdependence between subtasks. For clearly parallelisable research or content work, Anthropic's experience tends to apply instead. Which side fits is decided by the task, not by whichever source argues louder.
Sources
Every external figure and quote in this piece – linked so you can verify it.
- 1.Peter Steinberger (@steipete) auf X (18. Juli 2026) ↗ – “Are we still talking loops or did we shift to graphs yet?” – over 2.8m views, the tweet that triggered the term.
- 2.Anthropic, «How we built our multi-agent research system» (2025) ↗ – Orchestrator-worker system, 90.2% edge, 15x token cost, 80% of the variance explained by tokens.
- 3.Cognition, «Don't Build Multi-Agents» (2025) ↗ – Why Devin's coding agent stayed with a single, well-context-fed agent.
- 4.LangGraph-Dokumentation (LangChain) ↗ – Nodes, edges and state as the building blocks of orchestrated agent graphs.
The takeaway
One tweet with a single question triggered a term – the real shift had been under way for a while: from the chat chain to a visible, checkable workflow. Draw the graph once for a real piece of work, and you leave the chat window behind – managing AI work instead of prompting it.
Keep reading in the PM Lab
Related deep dives – from the same pillar and the adjacent phases.
Matching use cases from the library
From the article straight into practice: these use cases put the concepts to work with Teklens.
No new piece without you.
New articles, new interactive tools, new evidence – in your inbox first. And when you reply, we reply: you write directly with the authors, not with a no-reply.
No spam, no sharing, unsubscribe any time.