Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence
Yuyuan Feng, Zhishang Xiang, Chaobin Yang, Qichao Ma, Zerui Chen, Yujing Zhang, Ke Huang, Chuanjie Wu, Zhaoxu Liu, Yili Wang, Xin He, Jiapu Wang, Zijin Hong, Hao Chen, Yuanchen Bei, Kun Wang, Shengyuan Chen, Ningyu Zhang, Enyan Dai, Linhao Luo, Qingyi Pan, Qi Wang, Wenqi Fan, Guangjing Wang, Na Zou, Yangqiu Song, Xin Wang, Zechao Li, Xia Hu, Qing Li, Xiao Huang, Zhihong Zhang, Jinsong Su, Qinggang Zhang, Yi Chang
cs.IR, cs.AI, cs.ET
2026-08-21
Jilin-led survey names Graph Engineering the layer after prompt, context, harness, and loop: graphs for tasks, teams, and state, not more agents in one loop.
Prompt Engineering shapes how a model is asked to work. Context Engineering decides what information it can see. Harness Engineering attaches tools, memory, and skills outside the weights. Loop Engineering turns perceive-act-feedback into a persistent cycle. That stack moved LLMs from one-shot generation to a single agent that can keep working.
A single loop still cannot hold real work. Log analysis, failure reproduction, and code inspection can run in parallel during software diagnosis, while repair and testing depend on their outputs. Scientific discovery needs heterogeneous expertise and an independent verifier. Stuffing all of that into one context serializes parallel branches, hides the faulty step, and lets the same agent write and grade its own code. The survey names the missing capability System Intelligence: an agent system that organizes specialized components into a coherent whole chasing a shared objective. Adding agents is not the point. The point is explicit structure for work, coordination, and state.
Graph Engineering treats graphs as the organizational substrate of the system, not as a trick to boost one agent skill. Three coupled views do the work.
System Evolution then uses execution evidence to revise those three graphs, via TDAG and EvoFlow for tasks, SwarmAgentic and AgentNet for teams, and distilled traces for reusable state. Ontology Engineering is left as the next layer: graphs can draw relations, but they do not force agents to share a meaning of done, evidence, or authorization.
This is a survey, so there is no new SOTA table. The deliverable is a staged engineering history plus a coverage map against other surveys. Prompt and Context sit under Model Intelligence. Harness and Loop sit under Individual Intelligence. Graph sits under System Intelligence. In the appendix map, most agent surveys cover planning or multi-agent systems and treat harness and loop as secondary. Harness surveys cover runtime without treating graphs as the system substrate. The closest dynamic-graph survey asks how agents evolve through graph transforms. This one asks how system intelligence is organized. The authors mark their own row as covering Harness, Loop, Planning, Workflow, MAS, State, Self-Evolution, and Ontology. That is self-positioning, not a measured result.
The applications chapter walks software engineering, scientific discovery, healthcare, enterprise workflows, general digital agents, and social-economic simulation. The cross-domain claim is specific: work breakdown and team layout are already common, runtime state management is showing up, persistent system-level evolution is still rare. Most systems adapt inside a predefined structure. They do not permanently revise that structure from accumulated evidence. The authors split being graph-structured from being graph-engineered: many systems already execute through explicit work, team, and state objects, yet those objects are usually chosen by hand and frozen before the run.
Evaluation is regrouped by intelligence level. System-level tests are not MMLU-style questions. TaskBench and WorFBench inspect work graphs. MultiAgentBench and VillagerBench inspect coordination. SyncBench and Who & When inspect state and attribution. Three evaluation gaps stay open: system gains are hard to separate from a stronger model, a longer context, or extra retries; work, coordination, state, and evolution benches are fragmented; structural credit assignment and dynamic evaluation remain weak.
It gives agent-product teams a stricter checklist. Shipping subagents, parallel worktrees, and a task board can feel like system intelligence. Under this survey's standard, that is still graph-structured, not graph-engineered, because structural objectives, graph-level observability, controlled mutation, and transfer evidence are usually missing.
The usable part is the three-graph audit. Are parallel dependencies explicit? Are writing and judging split? Can a failure be traced to an agent and a step? Those questions sit closer to the system layer than swapping the backbone. The incremental part is equally clear: this is naming and cataloguing, not a new algorithm. The companion repository collects papers, data, and projects. It does not replace reading the sources.
The authors grant that graphs only make structure explicit. They do not settle shared semantics, goal formation, or value alignment. Open challenges also include capability stores that remain disconnected services, privacy and ethics, and evaluations that cannot tell system contribution from extra compute.
Selection bias is baked into a narrative survey. The story is strong, but "Graph Engineering is the next paradigm" is an organizing claim. The literature has not converged on that name. The coverage table is filled by the authors and marks themselves as the only full set, which is a weak form of evidence. "Evolution is still rare" in applications is a qualitative reading without a countable sample. The Awesome list is useful. The survey itself has no reproducible experiment.