This is a survey. It argues that as LLM agents grow past what a single agent loop can coordinate, the next engineering layer is Graph Engineering: making tasks, agents, and runtime state into explicit graphs that the system schedules, coordinates, and recovers on, instead of leaving that structure implicit in one agent’s context window.
You’re building a customer-support automation product. Today it’s one ReAct-style agent with tools: it reads the ticket, calls APIs, writes a reply. It works for simple tickets. Then product asks for tickets that need billing lookups, refund policy checks, a legal-approved response template, and a manager sign-off, all with an audit trail. You try to cram this into one agent loop and it degrades: the model serializes work that could run in parallel, forgets which step failed, and re-does clean work when one API errors.
The survey’s framing: this is the same wall other teams have hit. The dominant baseline is individual intelligence, one agent extended with Harness Engineering (tools, memory, skills) and a Loop Engineering control loop. That baseline breaks on tasks that want heterogeneous specialists, parallel branches, and durable state. The proposed frame is to stop scaling the single loop and start engineering the graph of tasks, agents, and state around it.
The survey organizes the multi-agent design space around three graph views that a system-level agent architecture should make explicit.
•
Task Organization graph. Nodes are subgoals or operators (LLM calls, tools, verifiers). Edges are dependencies. This is what lets a scheduler run independent branches in parallel and re-plan the tail when an intermediate result changes. Representative work: LLMCompiler compiles a plan into a dataflow DAG, AFlow searches over workflow code as the optimization target.
•
Agent Coordination graph. Nodes are agents, roles, tools, skills; edges are capability ownership, delegation, review, and communication. Splits into three sub-questions: who is capable, how the team is wired (chain, router, fan-out/fan-in), and which communication edges actually help vs. add noise.
•
Runtime State graph. The append-only, queryable record of what actually happened: committed state transitions, provenance, evidence for each claim, failure attribution. This is what lets the system localize a fault to a specific step and resume from a validated checkpoint instead of restarting.
On top of these three, the survey adds System Evolution: turning execution traces into persistent edits of the task, agent, and state graphs across runs, with validation and rollback so a bad edit doesn’t stick. It also proposes Ontology Engineering as the semantic layer: shared, machine-checkable definitions of goals, evidence, capabilities so different agents agree on what “done” means.
There’s no algorithm to pseudo-code here. The load-bearing move is conceptual: promote the graph from a diagram in a slide to an operational object the runtime schedules on, checkpoints, and can mutate.
The prevailing assumption is that a stronger agent is the answer: bigger model, longer context, more tools, more retries in the loop. This survey argues the opposite. Once tasks require parallel work, specialized verification, and durable state, the bottleneck is the organization around the agents, not the agents themselves, and that organization should be an explicit, versioned, queryable graph of tasks, agents, and runtime state. The evidence the survey leans on is the pattern across dozens of recent systems (coding agents like Claude Code and OpenHands, scientific systems like AI Co-Scientist, enterprise RAG) where the visible progress is graph-structured scheduling, dependency tracking, and state provenance, not a new prompting trick.
This is a survey, so “findings” are cross-cutting patterns rather than a headline number.
•
Work Organization and Agent Team structure are already common in shipped systems. Coding agents now expose subagents, isolated worktrees, and shared task boards (Claude Code, Cline, Codex). Scientific systems assign literature review, hypothesis generation, critique, and experiment design to different agents. Enterprise RAG splits planning, retrieval, sufficiency-check, and synthesis.
•
Runtime State Management is the least mature of the three. Most frameworks reconstruct “what executed” from logs, but few capture typed causal links between observations, decisions, state mutations, failures, and recovery actions. Work like Magentic-One’s Task/Progress Ledgers and event-sourced designs points at what’s missing.
•
Persistent System Evolution is rare. Systems adapt within a predefined structure (conditional routing, dynamic replanning) but rarely commit structural changes that persist across runs. GPTSwarm is one of the few that treats graph topology itself as an optimization variable.
•
Benchmarks fragment along the same three axes. Work-oriented (WorFBench, TPS-Bench), coordination (MultiAgentBench, Collab-Overcooked), and state (SyncBench, MAST, Who&When) benchmarks exist, but rarely in combination, and cross-run evolution is barely evaluated.
•
Additional agents don’t produce system intelligence on their own. The survey is explicit: more agents without explicit work decomposition, role boundaries, and state management just moves the coordination problem, it doesn’t solve it.
Reach for this framing when you’re the second engineer on an agent product that has outgrown a single ReAct loop, and you’re deciding whether to make the loop smarter or split it. The survey’s answer is to make three things explicit before adding more agents: the task DAG your scheduler will actually run on, the capability-to-agent map (with permissions), and the runtime state store that can answer “which step produced this artifact and is it still valid.” The concrete lift is that fault localization and partial recovery become tractable, because you have somewhere to point when something breaks.
The artifact is a curated resource list at Awesome-Graph-Engineering. The survey itself catalogs benchmarks (Table 1), open-source frameworks including LangGraph, Microsoft Agent Framework, Google ADK, CrewAI, CAMEL, and GPTSwarm (Table 2), and application systems across coding, science, healthcare, enterprise, and simulation (Table 3). Useful as a shopping list when picking a multi-agent framework or benchmark, less useful as a recipe.
When one agent loop stops scaling, the fix isn’t a smarter agent. It’s making the graph of work, actors, and state something your runtime can see, schedule, and roll back. More agents without that structure just relocates the mess.
•
This is a taxonomy paper, not an empirical one. It doesn’t measure whether graph-structured systems beat monolithic agents on matched compute; the survey itself flags this as an open evaluation gap.
•
The three-graph decomposition (task, agent, state) is a useful lens, not a proven architecture. Most cited systems implement one view well and the others informally, so the coupled-graphs vision is largely aspirational.
•
“System Evolution” and “Ontology Engineering” are pitched as future directions with few worked examples. If your product needs cross-run structural learning today, the survey names the problem more clearly than it names a solution.