What is graph engineering?

Graph engineering is the practice of designing how many AI agents are organised, as an explicit structure of nodes, typed edges and shared state, instead of programming one agent’s behaviour cycle. A loop controls what a single agent does. A graph controls how many agents divide the work, pass it between them and come back together.

Where the term came from

The name is a few months old. In mid-2026 Peter Steinberger asked on X whether people were “still talking loops or did we shift to graphs yet?”, and Hamel Husain answered with an article called Loop Engineering Is Dead. Enter Graph Engineering. It set off the usual round of rebuttals, explainers and videos.

The idea itself is older. LangChain’s own write-up, from July, calls graph engineering “the latest term to come out of X’s AI content factory” and points out that LangGraph has been building agents as graphs for three years. AutoGen and Google’s ADK work the same way, and most of the underlying patterns (chaining, routing, parallel work, orchestrator and workers) were laid out in Anthropic’s Building Effective Agents. So what arrived in July was mostly a word. It caught on because agents had started running unattended for hours, and the hard part had moved from what the model can do to how the system around it is designed.

Three layers, not three rivals

Prompt, loop and graph get talked about as if each replaces the last. They don’t. They stack, and each one controls a different unit of work.

	Controls	The question it answers
Prompt engineering	One model response	What do I say?
Loop engineering	One agent’s cycle	What finds the work, does it, checks it and remembers it?
Graph engineering	How many agents are organised	How does work split up, move between agents and come back together?

A loop has a trigger, a goal it can check, the actions available to it, a verification step, and memory that carries between attempts. Running the cycle is easy. Knowing when to stop is the hard part. A graph adds declared nodes and typed edges over shared state, with one rule that matters more than the rest: context doesn’t cross from one node to another unless an edge carries it.

What a graph is actually made of

Five parts, and each is a place where multi-agent systems tend to break first.

An org graph and a work graph

Two structures run at the same time, and they’re easy to confuse. The org graph is stable: agents in named roles that stick around, usually one per service or domain. The work graph is short-lived: tasks that split, merge and disappear as the agents learn more.

Edges that carry context on purpose

Because context only moves along an edge, every piece of information one agent gave another is a recorded transfer you can replay later. That’s what makes a graph auditable. Without it you have a group chat with a shared history nobody can reconstruct.

Places where branches meet

Parallel branches have to meet somewhere. Without an explicit barrier, one agent builds against a contract another branch is still negotiating, and the problem turns up late as a merge conflict or a broken integration. With a barrier it turns up early, as a wait.

A stop condition the system checks

This one comes from loop engineering and gets worse with more agents. A run that stops because it ran out of tokens didn’t finish, it gave up. Finishing needs a check the system performs, such as tests, a review step or a person’s decision. A model saying it’s done doesn’t count.

State that lasts

Multi-agent work runs for hours or days and waits on people. The structure has to survive a restart, a retry and someone going home for the weekend, without repeating a step that already changed something.

Why coding agents make this harder

Coding agents raise the stakes on all five. Their work touches real repositories, and a change to one service often forces changes to three others. A duplicated step can mean a duplicated migration. And the human decision in the middle of a run is usually a sign-off that someone will be asked about later.

That’s why a framework is usually not enough by itself. It gives you nodes, edges and state. What teams end up building around it is durable execution across a human decision, a record of what each agent did, and somewhere realistic for the agents to run. Those are platform problems more than framework problems.

How PlatformSmith runs a graph

Each part of a graph maps to something that ships in PlatformSmith today:

Part of the graph	How PlatformSmith does it
Org graph	A playbook names its participants up front: one agent per service, each running the coding agent that team already uses (Claude Code or Codex).
Work graph	Work items carry their own dependency graph, so the breakdown of a change is a structure the system can follow instead of a checklist someone keeps up to date.
Edges	Agents never talk to each other directly. Every message goes through the platform, which is what makes the conversation something you can replay afterwards.
Meeting points	Barriers hold the group until the services agree on their contract, so nobody builds against a shape that’s about to change.
Stop condition	Approval gates are explicit steps. A run waits at one for up to seven days and carries on from where it stopped.
Lasting state	The order of work runs on a durable workflow engine with retries and exactly-once steps, so a flaky step never turns into a duplicate change.

The agents themselves run inside your own container image, against the real service in your environment, on your infrastructure.

If you’re thinking about graphs because you want a whole delivery system built out of agents, we wrote about that separately in What is an agentic software factory? A factory is what you get when you point a graph like this at the entire software lifecycle.