Graph Engineering Rebuilds Agent Systems: From Harness to System Intelligence

From Individual to System Intelligence

The survey Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence (Feng et al., arXiv:2608.21156v2, 2026) frames agent evolution in three tiers: Model Intelligence (pre-training, prompt/context engineering), Individual Intelligence (Harness + Loop around a foundation model), and System Intelligence (multi-agent coordination via explicit graph structures). An Individual Agent is formalized as Loop(Foundation Model, Harness; Runtime State) where Harness provides knowledge, tools, memory, skills, and execution environments, and Loop drives continuous perception-reasoning-action-feedback cycles.

However, stacking single-agent autonomy fails for complex tasks (software engineering, scientific discovery, enterprise workflows) that require heterogeneous expertise, interdependent subtasks, parallel execution, independent verification, and long-term state maintenance. Stuffing everything into one loop causes context contention, forced serialization of parallel operations, implicit dependency management, and mixed state that makes failure isolation and progress preservation difficult.

DAG Returns: Explicit Task Organization

Task Organization externalizes plans from model context into explicit graph structures where nodes are subtasks and edges encode dependencies, ordering, and verification constraints. Key systems:

LLMCompiler compiles function-calling plans into Dataflow DAGs, dispatching nodes as soon as upstream dependencies are satisfied.

Plan-over-Graph generates parallel agent schedules directly from task dependency graphs.

TDAG and Flow allow dynamic task splitting, dependency adjustment, and agent generation during execution based on intermediate results.

This mirrors traditional DAG-based systems (Airflow, Dagster, Spark) but must handle probabilistic model outputs, dynamically changing task structures, and continuous environment interaction. Further work ( GPTSwarm , ADAS , AutoFlow , AFlow , DyFlow , EvoFlow , QualityFlow ) treats the agent workflow itself as a search/optimization object, using runtime feedback to continue, clarify, debug, roll back, or rewrite plans. The emerging hybrid model: models propose/modify structure; runtime constrains, schedules, validates, and records execution.

Runtime State Management: Beyond Memory

Runtime State Management addresses "what actually happened" across three layers:

State Recording

Systems now capture evidence, provenance, and versioned state transitions, not just "memory":

Magentic-One maintains Task Ledger and Progress Ledger via an Orchestrator.

Graph of States uses structured Belief State, causal graphs, and state-machine constrained transitions.

PatchBoard requires agent-generated patches to pass schema, role-permission, and runtime invariant checks before commit.

MemTX distinguishes tentative writes from transactional belief commits, preserving provenance and repair semantics.

A proposal-validation-commit pattern emerges: observed/proposed changes must be validated before becoming authoritative state. Concurrency demands isolation, causal ordering, conflict resolution; append-only history and Event Sourcing enable reconstruction, replay, and branching. The survey notes the lack of a unified graph-native transaction implementation as an open problem.

Fault Localization & Failure Recovery

Long-horizon tasks obscure root causes (error at step 20 surfaces at step 50). Systems preserve Actor, Transition, Dependency, and Validation Evidence to treat root cause as a hypothesis requiring evidence:

MAGE uses hierarchical state trees to locate error branches.

Who & When attributes responsibility to specific agents and steps.

MAST categorizes failures into system design, agent collaboration, and task verification.

TraceElephant incorporates execution traces, intermediate context, and full inputs.

Recovery defines Recovery Boundaries : which states to undo, which internal computations to replay, which external side-effects require compensation (not rollback). Techniques include Event Sourcing, AgentGit , Shepherd (replay/rollback/branching), DART (semantic valid boundaries), SagaLLM / RAC (checkpoint + compensation), and Atomix (coordinating reversible/irreversible operations). Unlike traditional transaction recovery, post-recovery the model may need to replan rather than mechanically resume.

Multi-Agent Coordination Demands a Control Plane

Agent Coordination splits into Capability Modeling, Team Organization, and Communication.

Capability Modeling

Skills, accessible resources, underlying models, permissions, reliability, and task fitness become explicit, queryable graph attributes (nodes for Agent/Skill/Tool/Model, typed edges for ownership, access, permission, reliability). This enables capability-aware routing when conditions change (e.g., an agent loses tool access). Examples:

DyLAN estimates candidate agent contribution.

MasRouter selects collaboration mode, roles, and models by task difficulty/cost.

SkillGraph guides communication topology via skill relationships.

MaAS searches an Agentic Supernet for better multi-agent structures.

"Which agent" becomes a dynamic scheduling problem over capabilities, cost, permissions, and reliability, not fixed role assignment.

Team Organization & Communication

Structures include chain (MetaGPT, ChatDev), orchestrator-centric (Magentic-One), parallel fan-out/fan-in (Mixture-of-Agents, MacNet), and dynamic restructuring (Puppeteer, AgentNet). More connections ≠ better collaboration; the communication graph must balance information value, invocation cost, and error propagation risk. The core challenge: clear responsibility boundaries, verification ownership, visibility scopes, human approval gates, and reorganization on environment change.

Toward Graph-Native Agent Operating Systems

Today's stack fragments Model Serving, Harness, Workflow Engine, Memory, Multi-Agent Framework, State Store, and Tool Protocol, each maintaining separate abstractions. The survey proposes a Graph-Native Agent OS where Task, Agent, Capability, and Runtime State are first-class objects unified by a typed, versioned graph. Shared runtime services would include Graph Scheduling, Capability Discovery, State Storage, Event/Provenance Logging, Structural Transactions, Permission Enforcement, Checkpoint/Replay/Rollback, and Graph-level Observability. Early precursors: MCP (external capability access), LangGraph (explicit workflow/state), AIOS (OS-level scheduling, context, memory, storage, tool, access control). Yet a common structural substrate for full agent systems is still missing; the emerging architecture resembles a control plane governing heterogeneous execution resources (models, tools, skills, specialized agents).

Agent's Next Step: Return to System Engineering

"The more autonomous the agent, the more deterministic the peripheral infrastructure must be." Probabilistic model outputs and dynamic task paths demand reliable organization, scheduling, verification, and recovery. Concepts like DAG, Scheduler, State, Provenance, Checkpoint, Replay, Rollback, Observability reappear not from regression but because AI now tackles complex production tasks that face classic software engineering and distributed systems problems.

Looking further: System Evolution (runtime success/failure/structural adjustments feeding back into task graphs, team structures, capability relations, state graphs under provenance, versioning, validation, replay, rollback constraints) and Ontology Engineering (shared entity, relation, type, and constraint semantics so "task completion", "sufficient evidence", "valid state", "legal permission" are not left to individual agent interpretation). The next competition: who can organize probabilistic intelligent components into explainable, verifiable, recoverable, continuously evolving yet governed production systems. Graph Engineering aims to build the system structure that lets models produce intelligence while the system ensures stable collaboration.