New research argues that the next major advance in artificial intelligence may come not simply from making individual models smarter, but from engineering the networks of agents, tools, capabilities, workflows, and state that surround them.

Artificial intelligence has spent much of the past decade pursuing a relatively straightforward objective: build a better model. More parameters, better training data, improved reasoning, longer context windows, multimodal capabilities, and increasingly sophisticated post-training have progressively expanded what an individual AI model can accomplish.

A new research paper argues that this model-centric view is becoming insufficient.

In “Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence,” Yuyuan Feng and a large group of co-authors propose that the next important engineering frontier is the deliberate organization of intelligent components into larger systems. Their central argument is that increasingly capable AI systems should be understood not merely as individual models or even individual agents, but as networks of specialized agents, tools, skills, memories, data resources, execution environments, communication paths, and continuously changing system states.

The authors call the discipline for designing these structures Graph Engineering.

The significance of the idea goes considerably beyond drawing workflow diagrams. If the researchers are correct, AI development is beginning a transition from improving the intelligence contained inside individual models toward engineering system intelligence: capabilities that emerge from the coordinated operation of many intelligent components.

From Model Intelligence to System Intelligence

The paper describes an important progression in AI engineering.

At the foundation is the large language model. Pretraining and post-training establish the underlying knowledge, reasoning ability, and behavioral characteristics of that model.

Prompt engineering determines how those capabilities are elicited.

Context engineering determines what information, instructions, retrieved knowledge, history, and intermediate results are available to the model when it performs a task.

But a model becomes considerably more capable when it is surrounded by an operational environment.

Tools allow it to search databases, execute software, interact with applications, manipulate files, call APIs, or control external systems. Memory allows information to persist between interactions. Skills package specialized procedures. Runtime infrastructure manages execution. Permissions determine which resources can be accessed.

This surrounding structure is increasingly described as the agent harness.

The research then identifies another layer: loop engineering.

An agent does not simply receive a prompt and generate an answer. It can repeatedly observe its environment, reason about what to do, select an action, execute that action, examine the result, update its understanding, and continue until some completion or termination condition is reached.

The authors capture this relationship with a compact abstraction:

Agent = Loop(LLM + Harness).

That formulation represents an important conceptual change. The model is no longer the complete intelligent system. It becomes one component operating inside a larger computational structure.

Graph Engineering takes the next step.

Instead of asking how one agent should operate, it asks how many agents and resources should be organized to accomplish a complex objective.

The progression therefore becomes:

Model Intelligence → Individual Agent Intelligence → System Intelligence.

That final category is the principal subject of the paper.

Why One Powerful Agent May Not Be Enough

Even an extremely capable model encounters architectural limitations when confronted with sufficiently complicated work.

Imagine an AI system responsible for designing a new industrial product.

One component may research materials. Another may perform mechanical simulations. Another may evaluate manufacturing processes. Another may analyze supply chains. Still another may examine regulatory requirements.

Some tasks depend upon results from earlier tasks. Others can proceed simultaneously. Certain findings may invalidate previous assumptions and require portions of the work to be repeated. Specialized tools may be available only to particular agents. Independent verification may be required before important decisions can proceed.

Trying to force all of that activity through one sequential conversational thread creates an increasingly difficult coordination problem.

The researchers therefore treat complex agentic work as a collection of interconnected graphs.

Three questions become particularly important:

What should happen?

Who should perform it?

What is actually happening?

Those questions correspond broadly to task organization, agent coordination, and runtime state management.

Together they form the foundation of Graph Engineering.

The Task Graph: Organizing the Work

The first problem is decomposing a large objective into executable work.

A task graph represents individual tasks as nodes and their dependencies as connections.

Suppose an engineering agent must investigate five possible materials for a component. A poorly designed workflow might investigate them sequentially:

Material A → Material B → Material C → Material D → Material E.

But if those investigations are independent, there is no technical reason to wait for one before beginning another.

A graph-oriented system can instead distribute the five investigations simultaneously and later combine their results.

That produces a familiar computational structure:

Decompose → Parallelize → Execute → Aggregate → Evaluate.

The distinction becomes increasingly important as agent systems grow.

Artificial dependencies increase execution time and potentially increase cost. Properly identifying independent tasks can create substantial parallelism.

But Graph Engineering goes beyond simple parallel processing.

The task graph itself can change.

A research result might reveal that another investigation is necessary. A failed task might be assigned to a different agent. A newly discovered dependency might require restructuring the workflow. A cost constraint might cause the system to eliminate low-value work.

Consequently, the graph becomes a dynamic runtime object rather than a static workflow created before execution begins.

The Agent Graph: Deciding Who Does the Work

Once tasks have been identified, another question appears:

Which agent should perform each one?

Different agents may possess different models, tools, memories, skills, knowledge bases, costs, reliability characteristics, or access privileges.

A powerful reasoning model might be appropriate for architectural planning but unnecessarily expensive for extracting structured information from thousands of documents. A smaller specialized model might perform that task faster and at much lower cost.

Similarly, one agent might have access to engineering simulation software while another has access to financial databases.

Graph Engineering therefore treats agents as heterogeneous computational resources.

The resulting system can match:

Task requirements → Agent capabilities.

This is fundamentally different from the common assumption that every task should simply be sent to the most powerful available model.

An intelligently designed system can employ different levels of models and agents for different jobs.

A high-capability agent might coordinate the overall objective while lower-cost worker agents perform specialized subtasks. Independent agents might verify critical outputs before they are accepted.

System performance then depends not only upon the intelligence of individual agents but upon the quality of the organization connecting them.

Communication Is Another Graph

One particularly useful distinction in the research is that the agent organization and the communication network do not have to be identical.

Ten agents may belong to the same system without every agent communicating directly with every other agent.

Communication can instead be structured according to need.

A worker may report only to a lead agent. Two specialists may communicate temporarily while solving a shared problem. A verification agent may receive results without being exposed to the complete reasoning histories of the agents that produced them.

Communication paths can also change during execution.

Connections can be created, eliminated, or redirected according to the task.

This produces an important distinction:

Agent Graph ≠ Communication Graph.

That has consequences for performance, cost, reliability, privacy, and security.

Every communication channel consumes resources and potentially creates another pathway through which incorrect, malicious, or sensitive information can propagate.

Optimizing the communication topology may therefore become almost as important as selecting the agents themselves.

Capability Graphs: Mapping What the System Can Actually Do

One of the paper’s most important ideas is the capability graph.

Modern agent platforms frequently maintain separate inventories of models, tools, skills, memory systems, databases, verification mechanisms, and execution environments.

The researchers envision connecting these resources into a unified graph.

Nodes might represent:

models, agents, tools, skills, memory resources, data sources, verifiers, or execution environments.

Relationships between them could represent dependency, compatibility, composition, substitution, authorization, cost, or reliability.

The result would be considerably more sophisticated than a simple tool registry.

Suppose an agent needs to analyze a CAD model.

The system could determine which tools support the required file format, which agents know how to operate those tools, which computational environments can execute them, which alternative capabilities could substitute if the preferred resource is unavailable, and what the expected cost and reliability of each path would be.

The system could then construct an appropriate capability chain dynamically.

This creates an important architectural principle:

The intelligence of the system increasingly depends upon its ability to compose capabilities, not merely upon the capabilities of any individual model.

Knowing What Is Actually Happening

Multi-agent systems create another difficult problem: state.

In a simple chatbot, much of the relevant state may exist within a conversation.

That assumption becomes dangerous in a distributed agent system.

Agent A may believe one thing has happened. Agent B may possess different information. A tool may have failed after an agent attempted to use it. An external database may have changed. A transaction may have been proposed but never completed.

The agent’s internal narrative therefore cannot automatically be treated as authoritative evidence of the state of the external world.

The research emphasizes runtime state management, including state recording, fault localization, and failure recovery.

A sophisticated agent system needs an independently maintained representation of:

what was requested, what was attempted, what actually executed, what changed, which evidence confirms the change, and what the current state of the system is.

That distinction becomes especially important when AI moves from generating information to taking consequential actions.

An agent saying, “I completed the transaction,” is not evidence that the transaction occurred.

The system should be able to verify the external effect.

This is one of the places where Graph Engineering intersects directly with agentic security and assurance.

Evidence-Driven Agent Loops

The same principle applies to agent loops.

An autonomous agent should not simply continue acting until the language model believes the objective has been achieved.

The loop should have observable progress criteria, resource limits, validation mechanisms, stopping conditions, and evidence requirements.

A more dependable execution sequence becomes:

Goal → Proposed Action → Execution → Environmental Effect → Observation → Verification → State Update → Continue or Stop.

This architecture creates an important separation between reasoning and execution.

The model can propose what should happen.

The surrounding system determines whether the action is permitted, executes it through controlled mechanisms, observes the result, and establishes evidence of what actually occurred.

That distinction will become increasingly important as AI agents interact with financial systems, industrial equipment, enterprise software, scientific laboratories, infrastructure, and eventually physical machines.

When Graphs Begin Rebuilding Themselves

The paper then moves into a more consequential area: self-evolving graphs.

Dynamic adaptation allows an agent system to change its organization during a particular task.

Persistent evolution goes further.

The system can examine previous executions, determine which structures performed well, modify its graph, test the new configuration, and retain successful changes for future work.

A simplified lifecycle becomes:

Execute → Observe → Evaluate → Attribute Results → Propose Structural Change → Validate → Commit or Roll Back.

That means the architecture itself can become a learning object.

Instead of merely improving model weights, an AI system could improve the way it organizes intelligence.

A system might learn that five agents are unnecessary for a particular task and reduce the workflow to three. It might discover that an independent verifier substantially improves reliability. It might identify an unnecessary communication pathway or discover that a particular specialist should become involved earlier.

This creates a second form of AI improvement.

Traditional machine learning improves the model.

Graph evolution improves the organization surrounding the models.

The combination could become particularly powerful.

Cross-Graph Dependencies Create a New Engineering Problem

There is an important complication.

The graphs cannot safely evolve independently.

Changing an agent can change its available capabilities.

Changing capabilities can affect which tasks it can perform.

Changing tasks can alter communication requirements.

Changing communication paths can change security exposure.

Changing tools may alter execution environments, permissions, cost, reliability, or potential consequences.

Graph Engineering therefore becomes a problem of interdependent graph management.

A modification in one graph may require revalidation of several others.

This is one of the paper’s most consequential implications even though its full security significance remains largely outside the paper’s primary scope.

For advanced agentic systems, structural change should therefore create a corresponding assurance obligation.

The system should not merely ask whether the new graph performs better.

It must eventually ask whether the new graph remains safe, authorized, reliable, and consistent with organizational policy.

From Graph Engineering to Ontology Engineering

The researchers then propose an even more ambitious development.

Graphs describe entities and their relationships, but a sufficiently heterogeneous intelligent system also needs agreement about what those entities and relationships mean.

That leads to Ontology Engineering.

An ontology could provide formal definitions for agents, tools, capabilities, tasks, states, events, evidence, constraints, permissions, and relationships.

This common semantic structure could allow different agents and systems to reason consistently about the same operational environment.

The distinction is subtle but important.

A graph might state:

Agent A → uses → Tool B.

An ontology can define what an “agent,” “tool,” and “uses” relationship actually mean, including constraints that follow from those definitions.

The researchers envision systems in which AI helps construct and evolve these ontologies. But they also recognize an obvious danger: an autonomous system should not casually be permitted to redefine the semantics governing its own operation.

Consequently, ontology changes may require formal validation, provenance tracking, regression testing, version control, logical consistency checking, and human oversight.

This could eventually create another layer in the AI stack:

Models → Agents → Graph-Organized Systems → Semantically Governed Intelligent Systems.

Graph-Native Agent Operating Systems

The research is not entirely speculative.

Current agent-development frameworks are already moving toward graph-oriented architectures. Systems such as LangGraph, Microsoft Agent Framework, Google’s Agent Development Kit, AutoGen/GraphFlow, CrewAI, CAMEL, Mastra, and GPTSwarm illustrate different aspects of graph-based orchestration.

These platforms increasingly support capabilities such as conditional execution, parallel work, cyclic workflows, persistent state, checkpoints, human intervention, replay, specialized agents, and dynamic task decomposition.

The long-term implication is that graph structures may become part of the operating substrate for AI agents.

The analogy with conventional computing is useful.

An operating system manages processors, memory, applications, files, devices, permissions, and execution.

An advanced agent operating environment may eventually manage:

models, agents, tools, skills, memory, context, authority, tasks, communication, evidence, computational resources, and external actions.

Graph structures provide a natural mechanism for representing the relationships among those resources.

Security Becomes a Graph Problem

Although the paper is principally concerned with system intelligence rather than cybersecurity, its architecture creates major security implications.

Every new node or connection can potentially change the attack surface.

Adding an agent may introduce new identity, authority, tools, memory, communication pathways, and dependencies.

Adding a communication edge creates a new information pathway.

Adding a capability creates a new potential action.

Changing the task graph can expose previously inaccessible resources.

Security therefore cannot remain a static perimeter around the agent system.

It increasingly becomes another interacting graph.

A useful extension of the research is:

**Task Graph

• Agent Graph
• Capability Graph
• Communication Graph
• Authority Graph
• Runtime State Graph
• Evidence Graph
  = Governed Agentic System.**

The crucial security rule is that capability cannot be confused with authority.

An agent may technically be capable of accessing a database without being authorized to access it for the current task.

Likewise, a tool may be available without its use being appropriate.

The executable portion of the system should therefore emerge from the intersection of what is technically possible and what is presently authorized:

Capability ∩ Authority ∩ Task Requirement ∩ Policy = Permitted Action Surface.

That principle becomes especially important as graphs dynamically reconstruct themselves.

A New Kind of AI Benchmark Will Be Required

The research also challenges conventional AI evaluation.

Model benchmarks measure characteristics of individual models.

Agent benchmarks increasingly measure how effectively a model equipped with tools and a harness can accomplish tasks.

But a graph-organized multi-agent system introduces another evaluation object entirely.

Its performance depends upon:

task decomposition,

agent selection,

coordination quality,

communication efficiency,

state consistency,

resource consumption,

fault localization,

failure recovery,

verification,

and system-level reliability.

A system constructed from several individually weaker models could conceivably outperform a poorly organized system built around a substantially more powerful model.

The implication is profound:

Model intelligence and system intelligence are not the same thing.

Future AI benchmarks may therefore have to measure not only how intelligent a model is, but how effectively an entire computational organization uses intelligence.

What the Research Establishes—and What It Does Not

The paper should primarily be understood as a broad architectural synthesis and research agenda rather than proof that one particular graph architecture is optimal.

Its importance lies in bringing together several rapidly developing areas of agent research and identifying a larger pattern.

Prompt engineering optimizes instructions.

Context engineering optimizes information.

Harness engineering provides capabilities.

Loop engineering creates persistent agency.

Graph engineering organizes multiple intelligent components.

Ontology engineering may eventually provide the shared semantics through which those systems understand themselves and their relationships.

The terminology is not yet a universally accepted engineering taxonomy, and the paper does not experimentally demonstrate that every future AI system will develop according to this hierarchy.

Nevertheless, the architectural direction it identifies is already visible.

Intelligence Is Moving Outside the Model

The most important implication of this research may be that the AI industry’s long-running search for increasingly intelligent models is beginning to be accompanied by an equally important search for better ways to organize intelligence.

A frontier model remains enormously important. But the model increasingly sits inside something much larger.

The emerging AI system contains models, agents, tools, skills, memory, data, software, communication channels, execution environments, security controls, humans, and external machines. These components interact dynamically, producing capabilities that cannot necessarily be attributed to any single component.

That changes the fundamental engineering question.

The question is no longer simply:

How intelligent is the model?

It becomes:

How intelligent, reliable, efficient, secure, and adaptable is the system we can construct from models and everything surrounding them?

That is the transition from individual intelligence to system intelligence described by this research.

And it may prove to be one of the defining transitions of the emerging agentic AI era.

Principal Research Source

Yuyuan Feng et al., “Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence,” arXiv:2608.21156, August 2026.

https://arxiv.org/abs/2608.21156