What Is Graph Engineering? Designing Multi-Agent Systems as Graphs (2026)

One well-built agent loop can do a lot. Once several agents share the work — one looking after security, one after the database, one after the API — the hard questions change. They are no longer about how one agent reasons, but about who talks to whom, who owns which decision, and who is allowed to stop the others. Graph engineering is the name that has emerged for designing those answers deliberately. This article draws on TrueFoundry's enterprise guide, Eigent's essay on moving beyond single feedback loops, and the LangGraph documentation.

What graph engineering is

Per TrueFoundry, graph engineering is designing the topology of a multi-agent system as an explicit, versionable artifact: which nodes exist (agents, deterministic functions, routers, joins, tools and human checkpoints), which transitions between them are permitted, and how runtime work graphs form and mutate. Loop engineering, by contrast, designs how each agentic node executes. The graph is the org chart and the routing; the loop is how each member does its job.

Where the term came from

This is an emerging framing, not a settled standard, and its provenance is still debated. According to Eigent, it gained traction in mid-July 2026 after developer Peter Steinberger asked whether the field had shifted from loops to graphs, an idea Carlos E. Perez and others then expanded. TrueFoundry credits an explainx.ai article by Yash Thakker (July 18, 2026) with synthesizing the discussion. Treat it as useful working vocabulary rather than a formal discipline.

The ladder: prompt → context → loop → graph

TrueFoundry stresses that the layers compose rather than replace each other: "A graph whose nodes have unengineered loops is an org chart of unreliable employees."

In ByteVancer's framing, the harness is what makes each node's loop reliable — the tools, rules, tests and feedback around a single agent. We cover that layer in What Is Harness Engineering? Graph engineering starts where that article stops: wiring many harnessed agents together.

Anatomy of a graph: nodes and edges

Edges are the permitted transitions: who may hand work to whom, and who may delegate. Eigent observes that the industry has moved away from open-ended multi-agent chat toward explicit workflow graphs modeled as state machines, where nodes are tool calls or LLM invocations and edges are permitted transitions. The point of making the graph explicit is that you can review it, version it and reason about it before anything runs.

Org graph vs work graph

TrueFoundry separates two graphs. The org graph is the standing structure: which agents exist and what each one owns. The work graph is what actually happens at runtime for one task — which nodes ran, in what order, and what they spawned. Its ownership example splits a software system across four agents, with the orchestrator as the source of truth for topology and the recorder of the actual runtime work graph:

An old idea with a new name

TrueFoundry traces a long lineage behind the term:

• Dataflow architectures, compiler dependency graphs, MapReduce, Airflow DAGs and deep-learning computation graphs.
• The actor model (Hewitt et al., 1973) and the Contract Net Protocol (Smith, 1980).
• Organisational tools: org charts, RACI matrices and BPMN.
• Agent frameworks such as LangGraph, AutoGen and CrewAI, and Google's A2A protocol (2025).

Why single loops break

Eigent describes a loop in control terms: a variable, a reference or target, a measurement of the gap, and an action — a thermostat, a PID controller or a plan-do-check-act cycle. One loop on its own fails in four predictable ways:

Graph engineering, in Eigent's words, asks which loops feed which, which own the targets, which can veto or roll back, and which measurements stay frozen. The answer is a graph of loops whose edges encode trust, authority and cadence.

Design principles

• Metrics never travel alone. Pair every optimization metric with a counter-metric and an anchor metric.
• References have owners. Slower loops own the targets that faster loops chase.
• Speeds are separated. Fast loops escalate; they cannot override slow ones.
• Some loops are frozen on purpose. Held-out test sets, hard safety and legal constraints, and ground truth stay out of reach of the machinery.

Those frozen pieces are what Eigent calls anchors: external, fixed nodes the system cannot rewrite. Without them, Eigent warns, "a graph without anchors is just a more elaborate echo chamber". Eigent also separates work or task graphs, which describe what the agents do, from improvement graphs, which describe how the system changes itself.

Loop layers

Eigent names four layers of loops. The one-line descriptions are our reading of how they stack:

Running a graph in production

Multiple agents multiply the governance problems. TrueFoundry's concerns are practical: every independently governed caller needs a resolved identity, because "the graph did it" is not an audit answer; tools should be scoped per node; guardrails do not eliminate cross-agent prompt-injection risk; and fan-out, retries and spawned subtasks multiply calls, so budgets must be explicit. Its seven-point checklist, paraphrased:

1. Every caller has a resolved identity.
2. Model and tool calls carry stable graph, run and node ids (graph_id, run_id, node_id).
3. The orchestrator records the actual runtime work graph.
4. Traces are correlated with cost, policy and latency.
5. Budgets are set per node.
6. Sensitive actions pass an approval checkpoint.
7. Model changes are isolated behind routing.

A minimal LangGraph example

LangGraph describes itself as "a low-level orchestration framework and runtime" for long-running, stateful agents. It mixes deterministic and LLM-driven steps in one graph, persists state so runs can resume after failures, lets a human inspect or modify state at any point, and supports short- and long-term memory, with LangSmith for debugging. Its design is inspired by Pregel and Apache Beam, its interface by NetworkX, and it can be used without LangChain. Install it with:

pip install -U langgraph

The documentation's hello-world graph:

from langgraph.graph import StateGraph, MessagesState, START, END

def mock_llm(state: MessagesState):
    return {"messages": [{"role": "ai", "content": "hello world"}]}

graph = StateGraph(MessagesState)
graph.add_node(mock_llm)
graph.add_edge(START, "mock_llm")
graph.add_edge("mock_llm", END)
graph = graph.compile()

graph.invoke({"messages": [{"role": "user", "content": "hi!"}]})

• StateGraph(MessagesState) declares the graph and the shape of the state that flows through it — here, a list of messages.
• add_node(mock_llm) registers a node. This one is a stand-in for a model call; in a real graph it could be an agent, a tool or plain code.
• add_edge(START, "mock_llm") and add_edge("mock_llm", END) are the permitted transitions: in at the start, out at the end.
• compile() turns the definition into something runnable, and invoke runs it with an initial state.

Everything in the rest of this article — routers, joins, human checkpoints, per-node budgets — is added the same way: as more nodes and more explicit edges.

When you don't need a graph

Our rule of thumb follows the ladder: stay on the lowest rung that does the job. If the task is a single response, prompt and context engineering are enough. If one agent with a good harness can finish it, engineer that loop well. Reach for a graph when you have separate owners, mandates that must not blur, or loops that need to check and veto each other — that is when an explicit topology pays for the structure it adds.

And whatever the graph looks like, each node is still only as good as its own loop. Start with the harness around each agent, then wire them together. For a hands-on version, our post on Claude Code agent teams and the loops-and-graphs playbook sketches a team lead, teammates and a deterministic gate wired as a graph.