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

Graph Engineering uses explicit graph structures to organize tasks, agents, and state for scalable system-level intelligence.

How can we transition from individual LLM agents to coordinated "System Intelligence" using structured graph-based engineering?

Individual agents struggle with complex, long-horizon tasks because they force heterogeneous subtasks and persistent states into a single, serial execution loop. Graph Engineering addresses this by using explicit, dynamic graph structures to represent and govern the relationships between tasks, agents, and execution states. This paradigm shifts agent systems from monolithic loops to distributed, coordinated architectures capable of parallel execution, independent verification, and robust state recovery.

Paper Primer

Graph Engineering treats the system as a set of interconnected nodes and edges rather than a single agent loop. It organizes work through three pillars: Task Organization (decomposing objectives into dependencies), Agent Coordination (mapping tasks to specialized roles), and Runtime State Management (tracking provenance and enabling recovery).

Graph-based abstractions resolve the structural bottlenecks of individual agent loops.

By externalizing task dependencies and state transitions into graph structures, the system enables parallel execution and independent failure isolation that serial loops cannot support. This transition allows for the scaling of agent systems beyond the organizational capacity of any single agent.

Why is simply adding more agents to a system insufficient for achieving System Intelligence?

A multi-agent system without explicit organization lacks clear responsibility boundaries, coordination protocols, and consistent state management, often resulting in role confusion and inefficient serial bottlenecks.

How does Graph Engineering differ from traditional Prompt or Context Engineering?

While Prompt and Context Engineering optimize the behavior of a single model call, Graph Engineering provides a system-level substrate to organize multiple agents, persistent resources, and long-horizon execution states.

Researchers and builders should move toward graph-native architectures to manage the complexity of multi-agent systems, treating the graph structure itself as the primary operational mechanism for system governance.

Introduction to Agent Intelligence

We motivate Graph Engineering as the path to System Intelligence beyond single‑model agents.

Large language models have progressed from text generators to autonomous agents, but single‑agent loops cannot scale to the heterogeneous, long‑horizon tasks of real‑world applications.

Distributing intelligence across multiple specialized agents and explicitly structuring their collaboration is required to overcome the capacity and coordination limits of any single LLM.

This image displays a collection of logos representing various universities and research institutions involved in the project.

**Figure 1 : Overview From Model Intelligence to System Intelligence.** Prompt and Context Engineering elicit and condition the access of foundation models to realize model intelligence. Harness and Loop Engineering extend and orchestrate agentic capabilities to enable Individual Intelligence. Graph Engineering builds on the foundation of individual agents through Task Organization, Agent Coordination, and Runtime State Management, empowering System Intelligence.

The key shift is moving from single‑model inference to coordinated multi‑agent systems.

Defining Intelligence Levels

We map the surveyed techniques onto four intelligence camps and expose the missing link between them.

The survey shows a dense landscape of Individual‑Intelligence tricks, yet coordinated System‑Intelligence approaches remain sparse.

Model Intelligence is what a single LLM can accomplish on its own, without any external orchestration.

Individual Intelligence augments a single LLM with a harness that supplies perception, memory, tools, and runtime governance.

System Intelligence treats a collection of agents as a coordinated whole, managing shared resources and joint state.

**Figure 2.** A Taxonomy of Evolving Techniques in the Era of LLM Agents.

Parameterized Training groups pre‑training and post‑training regimes that shape the base capabilities of LLM agents. Pre‑training on massive corpora (e.g., GPT‑3, PaLM, LLaMA) establishes a universal language backbone, while post‑training fine‑tunes models for specific domains or tasks. The survey highlights scaling‑law studies (Chinchilla, Switch Transformer) that reveal compute‑optimal model sizes, and data‑centric efforts (Deduplication, FineWeb) that improve data quality.

Model Intelligence comprises inference‑time augmentations that enhance a single LLM’s output without altering its internal weights. Prompt Engineering supplies structured prompts (Chain‑of‑Thought, Self‑Consistency, Tree of Thoughts) to steer reasoning. Context Engineering enriches the retrieval backbone (RAG, FiD, GraphRAG) to provide up‑to‑date factual grounding. Tool Integration equips the model with external APIs (MRKL, ReAct, Toolformer) so it can execute actions beyond text generation.

Individual Intelligence focuses on augmenting a single agent’s internal machinery. Memory Management methods (MemGPT, Generative Agents) provide long‑term storage and retrieval. Harness Engineering splits into Skill Composition (Voyager, SAGE) that assembles reusable capabilities, Runtime Orchestration frameworks (A2E, Harness‑Bench) that schedule and monitor execution, Loop Architecture designs (StateFlow, AIOS) that structure the perception‑reason‑act cycle, and Loop Engineering paradigms (Interaction Paradigm, Environment Feedback) that define how agents interact with each other and their surroundings.

System Intelligence aggregates multiple agents into a coordinated graph. Graph Engineering specifies task organization (e.g., Plan‑over‑Graph, Flow), agent coordination (e.g., DyLAN, MetaGPT), and state management (e.g., LangGraph, AutoGen). System Evolution tracks how the graph adapts over time (e.g., QueenBee Planner, EvoFlow). Ontology Engineering adds semantic schemas (OntoExtend, Agentology) that standardize knowledge representation across agents.

Individual Agent Capabilities

This section maps the evolution from model to individual intelligence via four engineering camps.

Across the surveyed studies, intelligence progresses from static, parameter‑level capabilities to dynamic, persistent agents that plan, act, and adapt.

Large‑scale pre‑training creates a broad knowledge and reasoning base encoded in model parameters; post‑training refines this base toward controllable behaviors. Scaling laws guide the joint growth of model size, data, and compute, while dense and mixture‑of‑experts architectures expand capacity under practical constraints. High‑quality curated data further improves acquisition efficiency.

Prompt Engineering defines task specifications, reasoning structures, and automatic optimization of control signals, while Context Engineering acquires, processes, and manages task‑relevant information. Together they adapt static model capabilities at inference time, selecting which abilities to invoke, how to organize reasoning (e.g., chain‑of‑thought, self‑consistency), and how to maintain a relevant information window through retrieval, compression, and hierarchical management.

Harness Engineering surrounds the model with a runtime layer that supplies external tools, persistent memory, reusable skills, and a governed execution environment. Tool Integration connects APIs, code, browsers, and shells; Memory Management offers long‑term storage and retrieval; Skill Composition builds hierarchical, optimizable procedural libraries; Runtime Orchestration governs security, configuration, verification, and continuous improvement of the harness itself.

Loop Engineering structures the iterative interaction between the model, harness, and environment. Loop Architecture defines goals, state, planning, verification, and termination criteria. Interaction Paradigm specifies how intents, observations, and supervisory signals are exchanged each iteration. Environment Feedback incorporates external outcomes as evidence that guides subsequent loop decisions, ensuring bounded, goal‑directed execution.

**Figure 3.** From model intelligence to individual intelligence. Foundation-model capability is progressively transformed through task conditioning, persistent execution support, and feedback-controlled interaction into a capable, persistent, and goal-directed agent. The limitations of individual intelligence motivate the subsequent transition toward system intelligence.

The Graph Engineering Framework

Graph Engineering structures system‑level intelligence by explicitly modeling tasks, agents, and runtime state.

Across the surveyed literature, graph‑based approaches dominate the move from individual to system intelligence. They agree that explicit graph structures are essential for decomposing objectives, coordinating heterogeneous agents, and managing execution state.

Graph Engineering treats the whole LLM‑agent system as a set of interconnected graphs that encode what to do, who does it, and how the execution state is tracked.

How does Graph Engineering differ from simply logging task dependencies?

Logging captures a linear history, whereas Graph Engineering makes the dependencies explicit, mutable, and queryable, enabling parallel scheduling, capability‑aware routing, and systematic recovery.

Task Organization turns a high‑level goal into a concrete, schedulable graph of subtasks and their dependencies.

Why not just let an LLM plan a linear sequence of actions?

A linear plan cannot express parallelism or conditional branches; a graph makes those structures visible and optimizable.

Agent Coordination uses graphs to match heterogeneous agents to tasks, define team topologies, and orchestrate communication.

How is Agent Coordination different from a simple routing table?

A routing table maps a request to a single handler, while Agent Coordination graphs capture many‑to‑many relationships, role hierarchies, and dynamic re‑configuration.

Runtime State Management records, diagnoses, and recovers from execution state using dedicated graphs.

Why not just store a flat log of events?

A flat log lacks the relational structure needed to trace how an error propagates through dependent tasks; a graph makes those causal links explicit.

The survey reports that Task Organization methods externalize goal decomposition and workflow construction as directed graphs. Early works such as HuggingGPT and ReWOO make dependencies explicit, while later systems like LLMCompiler, Plan‑over‑Graph, and DyFlow treat the graph as a mutable execution artifact that can be refined on‑the‑fly. These approaches enable parallel scheduling, dynamic replanning, and systematic optimization of operator placement.

Agent Coordination studies model heterogeneous agents, their capabilities, and their communication patterns as graphs. Capability graphs (SkillGraph, MaAS) store skill and resource attributes; team graphs (MetaGPT, ChatDev) define assignment and supervision edges; communication graphs (G‑Designer, DyTopo) optimize information flow. Recent work emphasizes dynamic re‑configuration (AgentNet, SwarmAgentic) that updates edges at runtime.

Runtime State Management approaches treat execution state as a graph of recorded transitions, enabling fault localization and recovery. State Recording systems (Magnetic‑One, Graph of States) log provenance; Fault Localization methods (MAGE, TraceElephant) traverse the graph to pinpoint errors; Recovery mechanisms (Event Sourcing, Aegis) define rollback or replay boundaries. Recent work integrates compensation for irreversible effects (SagaLLM, Atomix).

**Figure 4.** An Illustrative Conceptualization of System Intelligence and Its Related Technologies. The exam analogy depicts the progression from Model, Prompt, and Context Engineering to tool-enabled Harness Engineering, feedback-driven Loop Engineering, team-oriented Graph Engineering, and ontology-based collaboration. The lower panel summarizes representative technologies associated with these layers.

**Figure 5.** Overview of Graph Engineering. Task Organization structures the objective into explicit subtasks and executable workflows; Agent Coordination matches capabilities to work, defines team topology, and routes communication among agents; Runtime State Management records execution states, detects and localizes anomalies, and supports recovery and structural updates. Together, these coupled graph views organize work, coordinate agents, and use runtime evidence to evolve the system toward reliable task completion.

**Figure 6.** Overview of Task Organization. Goal Decomposition translates a high-level objective into explicit subtasks, exposes their dependencies for scheduling, and refines the remaining task graph using intermediate execution results. Workflow Optimization compiles semantic subgoals into executable workflows, searches and optimizes alternative control flows, and adapts execution in response to runtime feedback. These mechanisms specify what work must be accomplished, how it should be operationalized, and how the work structure evolves during execution.

**Figure 7.** Overview of Agent Coordination. The Agent Capability Graph maps agents to their capabilities and accessible resources; the Agent Team Graph organizes agents into task-dependent collaboration structures; and the Communication Graph specifies and adapts information flow among agents. These graphs determine who should perform the work and how agents collaborate during execution.

Challenges and Opportunities

Open challenges span capability graphs, self‑evolving structures, and graph‑native operating systems for robust system intelligence.

Graph Engineering structures LLM‑based agent systems by explicitly modeling task organization, agent coordination, and runtime state, thereby moving from individual to System Intelligence.

First, capability substrates such as memory stores, skill libraries, and tool registries remain largely implicit, making selection increasingly structural as these repositories grow.

Recent systems like A‑MEM, Zep, Graph of Skills, and SkillDAG demonstrate that memories, facts, and reusable procedures can be organized as evolving graphs, hinting at a unified capability graph that ties models, tools, skills, and data sources together.

Connecting these capability graphs with the task, agent, and runtime‑state graphs is the next hurdle: task decomposition must expose capability requirements, agent allocation must respect available capability subgraphs, and execution outcomes must update capability reliability.

Second, self‑evolving graph systems aim to turn execution evidence into persistent structural changes, requiring a closed loop of credit assignment, graph modification, validation, and commit or rollback.

Existing approaches (GPTSwarm, AFlow, DyTopo, ReCreate, MemTX, event‑sourced designs) adapt graphs at runtime but often only for a single execution; true evolution must survive beyond the current task and coordinate changes across task, agent, capability, and state graphs.

Governance—provenance tracking, versioning, validation, replay, and rollback—must accompany any structural adaptation to prevent unreliable changes from propagating.

Third, a graph‑native agent operating system would expose tasks, agents, capabilities, and runtime states as first‑class, typed, versioned graph objects, unifying scheduling, capability discovery, state storage, event logging, and permission enforcement under a common runtime.

Current stacks (model serving, workflow engines, memory systems, multi‑agent frameworks, state stores) are fragmented; protocols like MCP and frameworks such as LangGraph and AIOS hint at integration but still lack a shared structural substrate.

Ontological engineering must define the types, relations, and constraints for these graph objects, while the graph runtime provides services—scheduling, capability discovery, persistent storage, event and provenance logging, structural transactions, permission enforcement, checkpointing, replay, rollback, and observability.

Such an infrastructure would enable safe, continual system evolution and chart a path toward scalable, persistent System Intelligence.

Privacy and Ethics

We examine privacy, ethical, and semantic limits of system‑intelligent agents and argue that Ontology Engineering is needed to overcome them.

System intelligence amplifies privacy and ethical concerns because it coordinates many agents, tools, memories, and shared states over long horizons. Sensitive information can be replicated, propagated, and persisted across components, raising risks of unauthorized access, cross‑task leakage, and unintended inference from execution traces.

To mitigate these risks, system‑intelligent agents must incorporate privacy‑preserving state management, scoped permissions, provenance‑aware logging, and strong human oversight, ensuring that autonomy does not compromise user privacy, fairness, or controllability.

Ontology Engineering builds a shared, machine‑interpretable model of system entities, relations, and constraints, giving every component a common semantic vocabulary.

Explicit graph structures alone do not guarantee that system components interpret them consistently. Agents may still disagree on what constitutes task completion, sufficient evidence, valid state, or authorized action.

Consequently, end‑task success is an insufficient indicator of System Intelligence; performance gains can stem from larger foundation models, longer contexts, or more compute rather than better task organization, coordination, or state management.

Robust evaluation must therefore isolate component‑level capabilities, assessing goal formation, semantic consistency, parallel execution efficiency, heterogeneous capability allocation, collective decision quality, state consistency, failure recovery, transferability, and runtime overhead.

Ontologies provide the semantic foundation needed to connect, validate, and evolve graph structures, supporting the next generation of System Intelligence.

For goal formation and value alignment, ontologies can represent provenance, priority, authorization scope, completion criteria, and constraints, enabling systems to detect goal conflicts, unauthorized modifications, and required evidence.

Shared semantics and world grounding rely on ontologies to map agent observations, tool outputs, timestamps, and provenance to common definitions, while still allowing verification of factual correctness.

Standardized ontological representations also support measurement of System Intelligence by providing uniform vocabularies for task success, failure, agent contribution, recovery, state consistency, and runtime cost.

Future research must address how ontologies are grounded, updated, and governed: version control, compatibility checking, migration, rollback, and runtime enforcement of permissions, evidence requirements, and valid state transitions.

Evaluating Agent Intelligence

We map benchmarks to three intelligence levels, exposing consensus and key gaps.

Benchmarks cluster around three intelligence levels, revealing broad agreement on evaluation categories while exposing persistent gaps in system‑level credit attribution and resource fragmentation.

Model Intelligence benchmarks probe raw LLM capabilities on bounded tasks. They span knowledge recall, multi‑step scientific reasoning, NP‑complete problem solving, olympiad‑level math, instruction following, code generation, multimodal QA, and retrieval‑augmented generation. The surveys treat each benchmark as a self‑contained task with a fixed input‑output contract, allowing direct scoring of correctness, accuracy, or functional execution.

Individual Intelligence benchmarks shift focus from single‑output correctness to sustained agent trajectories. They require agents to interact with environments—web, OS, software, or APIs—over long horizons, maintain state, and orchestrate tool use. The resources include both static benchmarks (e.g., AgentBench, GAIA) and executable environments (e.g., WebArena, OSWorld) that expose mutable state and require continual decision making.

System Intelligence benchmarks evaluate coordinated multi‑agent systems, task decomposition, workflow orchestration, and runtime state management. They test how multiple components interact, share information, and adapt over time, often under constraints such as privacy, scalability, or adversarial pressure. The suite includes work‑oriented benchmarks, coordination challenges, and state‑oriented diagnostics.

**Table 1.** Representative benchmarks, datasets, and executable environments across Model, Individual, and System Intelligence. Type: B = benchmark or evaluation protocol; D = released dataset, annotations, or traces; E = executable or interactive environment. Focus denotes the principal capability or structural property evaluated.

Despite this rich taxonomy, the field still disagrees on three dimensions: (1) isolating genuine system‑level gains from stronger underlying models, (2) the fragmentation of resources across work‑organization, coordination, and runtime‑state camps, and (3) the lack of robust structural credit‑assignment mechanisms for dynamic, evolving systems.

Engineering Ecosystems

Open‑source libraries form the engineering backbone from model to system intelligence.

Open‑source libraries collectively bridge model, individual, and system intelligence, yet unified orchestration and persistent state remain fragmented.

**Table 2.** Representative open-source projects and engineering systems across Model, Individual, and System Intelligence. Libraries are grouped by their primary engineering target rather than exclusive functionality. Focus summarizes the main engineering concerns exposed by each system.

These libraries focus on constructing, refining, and exposing model capabilities. They provide unified model definitions, large‑scale distributed pre‑training, and high‑throughput inference back‑ends that downstream agents rely on. The survey notes that while they excel at parameter and execution management, they do not handle persistent agent state or system‑level coordination.

These frameworks shift focus from raw model parameters to the runtime surrounding a model, exposing tool‑use loops, state management, and session handling. They enable a single agent to interact with external tools, maintain memory, and orchestrate context construction, forming the backbone of autonomous agents.

System‑level libraries make task relationships, agent coordination, and shared runtime state explicit engineering objects. They provide graph‑oriented execution models, multi‑agent programming abstractions, and hierarchical coordination mechanisms, aiming to move beyond isolated agents toward cohesive system intelligence.

Applications and Future Outlook

Mapping real‑world deployments reveals where Graph Engineering succeeds and where it still lags.

Across domains, Graph Engineering has matured enough to orchestrate work, coordinate teams, and manage runtime state, yet systematic evolution of the graph itself remains scarce.

**Table 3.** Representative applications of System Intelligence. Level denotes the primary intelligence level: I = Individual Intelligence, S = System Intelligence, and I/S = systems spanning both. Focus summarizes the principal Graph Engineering concerns: Work Organization, Agent Team, Runtime State, and System Evolution.

Agent‑based tools for coding, repository management, and operational monitoring have progressed from single‑agent scripts to coordinated teams that manipulate codebases, handle telemetry, and maintain persistent event streams.

Research‑oriented agents organize hypotheses, experiments, and analysis into long‑running pipelines, often coupling computational reasoning with physical laboratory execution.

Multi‑agent clinical assistants coordinate specialist reasoning, longitudinal patient records, and evidence provenance to support diagnosis and long‑term disease management.

Business‑process‑driven agents enforce role‑based permissions, policy constraints, and transactional integrity while automating complex organizational workflows.

Persistent agents operate across communication channels, maintain user‑specific state, and expose reusable skills, moving beyond single‑task execution toward continual personal assistance.

Large‑scale agent societies model emergent phenomena, requiring explicit team structures and runtime state to capture feedback between individual actions and macro‑level environments.

Across all domains, Work Organization, Agent Team, and Runtime State are widely addressed, while System Evolution—persistent, evidence‑driven restructuring of the graph—remains underexplored.

Appendix Overview

Appendix lists key references on agentic systems and graph engineering.

This appendix enumerates the works cited throughout the paper, spanning agentic logic, graph‑based coordination, tool‑augmented language models, and benchmark datasets that underpin the discussion of Graph Engineering and System Intelligence.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers