Multi-agent systems need explicit graphs, not smarter agents

When one agent is not enough

Over the past year the industry has picked up an odd habit: when an agent fails a task, you give it more tools, more memory, a bigger context window and another try. Sometimes that works. But only up to the point where the task stops looking like a conversation with a smart model and starts looking like the work of a small team.

Fixing a bug in a large repository, say. Or assembling a research pipeline. Or running a long business procedure with checks, approvals and rollbacks. On tasks like these a single AI agent hits a ceiling fast. It has to hold everything in one head: the plan, intermediate results, errors, verification, tool calls, and a memory of what has already happened.

The authors of a broad new paper propose a different framing. The next step for AI agents is a system of several specialized agents with an explicit structure linking tasks, roles and states. For this they introduce the term graph engineering.

The idea is practical: if you want an agentic system to hold up on long, complex tasks, you have to describe explicitly:

🟠 what exactly needs to be done

🟠 who exactly is doing it

🟠 what state the whole system is in right now

That, in the authors' view, is what separates a mere pile of agents from system intelligence.

The move from model intelligence to system intelligence: from prompts and context to scaffolding, loops and graph engineering.

From model to agent, from agent to system

The paper's argument is built as a ladder.

First comes model intelligence. These are the base capabilities of an LLM: understanding text, answering, writing code, reasoning. They come out of pretraining and fine-tuning, and at inference time they are amplified by prompts and context.

Then comes individual intelligence. This is no longer a bare model call but an agent with scaffolding: access to tools, memory, skills and an action loop. It can plan, run commands, look at the result, correct itself and keep going.

On long tasks, that still is not enough.

A single agent almost always runs in one main loop. Branches that could run in parallel collapse into a sequential chain. Roles blur. The work is often checked by the same agent that produced it. And the state of the task is smeared across the context window, the logs and stray notes.

The authors put it bluntly: many real tasks architecturally do not fit inside one agent. The problem is no longer that the agent is one tool or a slightly larger context window short. What it lacks is organization.

In short, the problem looks like this:

🟣 complex tasks are made of interdependent subtasks

🟣 some of the steps have to run in parallel

🟣 different steps call for different specializations

🟣 results need to be verified independently

🟣 state has to outlive a single agent loop

Hence the paper's central move: from individual intelligence to system intelligence.

How a model's capabilities turn into an agent: prompts, context, scaffolding and execution loops.

What graph engineering is

By graph engineering the authors mean more than using graphs as a data structure. The point is to make graphs the working control layer of an agentic system.

In this scheme there are three main graphs, or three main kinds of structure.

1. Task organization

The first question: what to do.

A large goal has to be broken down into subtasks, dependencies, branches, checks and an executable pipeline. As long as all of that lives only in the text of a prompt, the system is fragile. Once the structure is explicit, you can manage it: run independent steps in parallel, rebuild the plan, insert checks, roll back the branches that failed.

This shows up most clearly in coding tasks, research pipelines and business processes. A single linear trajectory is rare there. Usually there is a tree or a directed graph: gather data, test a hypothesis, run a test, compare results, back up if the check does not pass.

The authors name two key mechanisms:

🟠 goal decomposition — splitting the overall task into subtasks with dependencies

🟠 pipeline optimization — turning those subtasks into an executable scheme with agents, tools and checks

Here the survey pulls together a lot of recent work: from systems that explicitly break a task into sub-stages to methods that search for the best agentic pipeline outright, treating the pipeline itself as the thing being optimized.

The deeper point: the task stops being a chain of thought inside the model's head and becomes an external structure you can work with.

Task organization: how a goal decomposes into subgoals, dependencies and an executable pipeline.

2. Agent coordination

The second question: who does the work.

Having several agents is not enough on its own. You need an explicit model of capabilities, roles and communication channels. Otherwise you get a crowd, not a system.

The authors split coordination into three layers:

🟣 the capability graph — who can do what, which tools they can reach, where they are reliable

🟣 the team graph — which roles are assigned, who delegates to whom, who checks whom

🟣 the communication graph — who exchanges information with whom, and when

The distinction matters. One agent may be good at reading logs but wrong for writing the fix. Another writes excellent code but cannot reliably check for regressions. A third is not there to generate anything at all — it is there to verify.

In an ordinary single agent all of this blurs together. In a multi-agent system these differences have to be stated explicitly.

The authors give plenty of examples of such structures:

🟠 role chains, where the output of one stage passes to the next

🟠 routing, where a dispatcher sends subtasks to the right specialists

🟠 fan-out schemes, where several agents work in parallel and their answers are then aggregated

🟠 dynamic topologies that rewire themselves as the task goes on

One observation here: more links between agents is not always better. Extra communication buys noise, cost and the spread of errors. So the communication graph has to be designed too, not left to form on its own.

Agent coordination: capabilities, team structure and the message flows between agents.

3. Runtime state management

The third question: what is happening right now.

This is probably the most underrated part of the paper. People who build agentic systems like to talk about planning and roles; they talk far less about execution state.

If a system runs for a long time, in parallel, with external tools, a log is not enough. It needs a legible, checkable state layer:

🟣 which steps are already finished

🟣 which results have been confirmed

🟣 which changes are still only proposed

🟣 where exactly the failure happened

🟣 which known-good state it can recover from

The authors call this runtime state management. It holds three jobs:

🟠 recording state

🟠 localizing failures

🟠 recovering from failures

This is already very close to how ordinary reliable systems are built: transactions, version control, rollbacks, invariant checks, replaying history. Only now all of it has to be carried over into the world of AI agents.

And it matters, because long agentic tasks do not fail only from bad reasoning. They fail because the system does not know where it went wrong, which piece of the work is still valid, and what can be reused in recovery.

Runtime state management: recording history, finding failures and restoring the system.

Why this matters now

The value of the paper is not the new name. It is that it describes a shift in the industry accurately.

For the past year and a half everyone has been building ever more elaborate scaffolding around LLMs: memory, tools, browsers, shells, coding agents, long loops with self-checking. But the harder the task, the clearer one thing becomes: the problem is no longer the individual model call.

The problem is the system.

You can see it across several areas at once:

🟠 in coding you have to run parallel branches, tests, reviews and rollbacks

🟠 in scientific work you have to separate hypothesis generation, critique, data analysis and verification

🟠 in enterprise processes you need roles, access rights, approvals and a change log

🟠 in medicine you need a long history, a source for every conclusion and a clear chain of accountability

In all of these cases, one very smart agent is simply an awkward unit to build with.

One more point: the paper says outright that being multi-agent guarantees nothing by itself. You can add five agents and end up with a system that is more chaotic than before. System intelligence appears only where the work is explicitly organized, the roles are coordinated and the state is managed.

How the authors map the field

This is not an experimental paper with one new model and a table of results. It is a broad survey of the field.

The authors walk the whole chain:

🟣 base models and fine-tuning

🟣 prompts and context

🟣 agent scaffolding: tools, memory, skills

🟣 execution loops and feedback

🟣 the limits of a single agent

🟣 graph engineering as the next level

🟣 benchmarks, libraries and applied cases

🟣 open problems: privacy, evaluation, semantics, infrastructure

It helps that they do not stop at theory. The paper includes a large cross-section of applied systems: software engineering, research, medicine, enterprise pipelines, personal agents, social simulations. What comes through is that many working teams are already moving toward system-level organization, even if they do not call it graph engineering.

Evaluation is another layer. The authors show that current benchmarks usually measure either the capabilities of a model or the success of a single agent, and do a much worse job on the properties of the whole system: whether the decomposition was correct, how good the coordination was, how stable the state stayed, how well the system recovered from an error, whether improvements carry from one run to the next.

What comes next

At the end the authors look a step past graph engineering and raise one more layer — ontology engineering. The idea is simple: drawing a graph of tasks and roles is not enough, you also have to agree on what the nodes and edges mean.

What counts as a task being finished? What is confirmed evidence? Who has the right to change state? Which actions are permitted? When are two different subsystems saying the same thing in different words?

Without shared semantics, even a well-organized system starts to get lost in its own structures.

This starts to look like future infrastructure for agentic systems: not just pipelines and orchestrators but something closer to an operating system for agents, where tasks, capabilities, state and rules are first-class objects.

The takeaway

The dividing line now is not between a model and an agent. It runs between a single agent and a system of agents.

Building long, complex agentic pipelines without explicit structure is getting harder. The work, the roles and the state each need a description of their own. Failures have to be localizable, and recovery has to be possible without a full restart. And you have to know which organizational choices improve the system and which only add noise.

The paper's main claim, briefly:

🟠 complex tasks require distributed intelligence

🟠 distributed intelligence requires explicit structure

🟠 graphs are becoming the way to specify that structure

🟠 the next step is learning not just to execute such structures but to improve them safely over time

For anyone building AI agents, this is a shift of focus: less thinking about prompt magic, more about designing the system.