Graph Engineering: AI Needs a Standard for Connecting Models, Tools, and Machines

At first, graph engineering sounded like loop engineering with extra boxes.

Loop engineering already allows an AI system to receive a task, choose an action, check the result, learn from failure, and retry. A capable general agent can also classify a request as technical, billing-related, unsafe, or unclear. So why draw a graph around it?

The answer, I think, is not simply branching. It is structure.

Graph engineering encourages us to turn parts of an AI system into explicit, replaceable units. Once that happens, a node does not have to be another AI agent. It can be a model, an API, a local program, a database query, a laptop, a cloud server, a reviewer, a human approval step, or even an entire loop-engineered workflow.

That changes the question from:

What should one agent do next?

into:

Which capability should receive this state next, and what contract connects it to the rest of the system?

This starts to look less like prompt engineering and more like infrastructure engineering.

A Node Is Just a Unit of Work

The word node can make graph engineering sound more abstract than it is.

A node is simply a named unit that receives input, does some work, and returns output.

For example:

[Receive GitHub issue]
          ↓
[Implement change]
          ↓
[Run tests]
          ↓
[Review against issue]
      ↙          ↘
   Failed       Passed
     ↓             ↓
[Implement again] [Open pull request]

Each box is a node, but not every node needs to be an AI agent.

• Receive GitHub issue could be an API call.
• Implement change could be a coding model running on a cloud machine.
• Run tests could be a deterministic shell command in CI.
• Review against issue could be a separate model with a narrow reviewer role.
• Open pull request could be a GitHub integration.

The graph connects these units and decides which one runs next.

A Loop Can Live Inside a Graph

Loop engineering and graph engineering are not really competitors. They describe different layers of the same system.

Loop engineering focuses on how work continues:

Act → Check → Learn → Retry → Stop

Graph engineering focuses on how units of work are connected:

Planner → Coding workflow → Reviewer → Deployment gate

The coding workflow in that graph may contain its own loop:

Coding workflow
   ↓
Implement
   ↓
Run tests
  ↙      ↘
Fail     Pass
 ↓         ↓
Fix       Return result
 └────────→ Run tests again

From the outside, the whole coding workflow can appear as one node. Internally, it may contain several nodes and multiple retries.

We can zoom in or out depending on what we are building.

That is an important realization: a loop can be a node in a larger graph, and a graph can contain many loops.

Action Nodes Should Act, and Reviewer Nodes Should Review

One large agent can plan, implement, test, review, secure, and publish its own work. But making one agent responsible for every role does not always produce the clearest system.

A graph lets us separate those responsibilities.

Action node → Reviewer node
                 ├─ Pass → Continue
                 └─ Fail → Return feedback to action node

The action node focuses on doing the work. The reviewer focuses on deciding whether that work satisfies the task.

For a GitHub issue, the reviewer might receive:

• the original issue;
• the implementation diff;
• test results;
• repository instructions;
• explicit acceptance criteria.

It could return:

{
  "passed": false,
  "feedback": [
    "The issue requires pagination, but the endpoint still returns only the first page.",
    "There is no test for an empty result."
  ]
}

The main workflow then follows the failed edge and sends the feedback back to the action node.

If the reviewer says the work has not met the criteria, the task is not finished. That is the reviewer's role.

The reviewer can still be wrong. AI reviewers do not magically have more knowledge than AI action nodes. But separating the roles gives each node a narrower objective, a better prompt, and the right evidence. It also lets us replace or improve the reviewer without changing the implementation node.

For important work, a review stage can combine several forms of evidence:

Tests + static analysis + AI review + optional human approval

The goal is not to create an all-knowing reviewer. The goal is to make judgment an explicit part of the system instead of asking the action node to approve itself.

The Main Server Owns the Flow; Each Node Owns Its Job

A central orchestrator can keep the system simple.

It does not need every node to understand the entire graph. It only needs to:

• send the correct input to a node;
• receive and store the result;
• decide which edge to follow next;
• enforce stopping conditions;
• report failures that cannot be handled automatically.

Each node only needs to perform its own contract.

Main server
   ├─ sends task to action node
   ├─ sends result to reviewer node
   ├─ routes failed review back to action node
   └─ routes passed review to the next stage

This is not very different from ordinary distributed software. Services receive requests and return responses. The interesting part is that some services may now contain AI models capable of handling less deterministic work.

Why This Structure Can Scale Better

Once nodes have clear inputs and outputs, the system becomes modular.

Imagine this workflow:

Private-data preparation → Planning → Coding → Testing → Review → Human merge

The nodes could run in completely different places:

Private-data preparation → local laptop
Planning                 → one cloud model
Coding                   → GPU server
Testing                  → CI machine
Review                    → another model provider
Human merge               → GitHub

If the coding model is replaced, the rest of the graph should not need to change. If the review node becomes a bottleneck, it can be scaled separately. If private data must stay local, only a filtered result needs to leave the local node.

This structure makes several things easier:

• replacing one model without rebuilding the whole workflow;
• running different jobs on different computers;
• scaling expensive or heavily used nodes independently;
• inserting a reviewer or safety check before a sensitive action;
• reusing the same node in multiple workflows;
• testing one stage without running the entire system.

The major benefit is not merely that the graph contains more actions. The graph encourages us to define boundaries between actions.

Prompts Define the Role; Schemas Define the Connection

A good prompt can tell a reviewer exactly what to check and how to format its answer. That may be enough inside one application.

But if nodes are meant to be reusable across models, computers, or organisations, it helps to make the connection explicit as well.

A minimal node description might look like this:

{
  "name": "github-issue-reviewer",
  "version": "1.0",
  "capability": "review-implementation-against-issue",
  "accepts": "implementation-review-request",
  "returns": "implementation-review-result",
  "endpoint": "https://example.com/nodes/reviewer",
  "timeoutSeconds": 300
}

The request might contain:

{
  "issue": {
    "title": "Add pagination",
    "body": "..."
  },
  "diff": "...",
  "testResults": {
    "passed": true
  }
}

And the response might always follow this shape:

{
  "passed": true,
  "feedback": []
}

The prompt still defines how the reviewer behaves. The schema defines how the rest of the system communicates with it.

The orchestrator does not need to care whether the reviewer uses GPT, Claude, Gemini, a local model, a deterministic analyser, or a human behind a queue. As long as the contract remains compatible, the node can be replaced.

The Missing Product Is a Runtime for AI Nodes

We can build this architecture today, but we often have to assemble the infrastructure ourselves.

Several existing technologies already solve parts of the problem:

These are important pieces, but they still feel like separate layers rather than one simple universal runtime for AI nodes.

What I would like to see is a system where a developer can:

1. register a node and describe its capability;
2. define its input and output contract;
3. connect it to other nodes visually or in code;
4. run nodes on different models, machines, and providers;
5. preserve graph state between steps;
6. add reviewers, retries, budgets, and human gates;
7. observe which node made each decision;
8. replace one node without redesigning the workflow.

In other words, something like a control plane for AI capabilities.

A Kubernetes-Like Layer for AI Work

The Kubernetes comparison is useful, although the proposed system would probably run on top of Kubernetes rather than replace it.

Kubernetes does not understand whether an application is writing code, reviewing a contract, or researching a company. It manages compute resources and tries to keep workloads running in the declared state.

An AI-node runtime would operate at a different layer. It would understand concepts such as:

• task state;
• node capability;
• structured inputs and outputs;
• review results;
• failure routes;
• retry limits;
• human approval gates;
• model and prompt versions;
• cost and execution budgets.

A simple graph could then say:

Use any available planning node
→ send the plan to a coding node with repository access
→ run the result through the required test node
→ require a passing review node
→ create a pull request
→ stop before merge

The system could choose where each node runs and recover if one machine becomes unavailable.

This is where graph engineering becomes more than drawing a flowchart. The graph becomes a portable description of how AI work should move through a network of capabilities.

Most Risks Are Not Unique to Graph Engineering

Connecting multiple nodes introduces engineering concerns, but many of them already exist in single-agent systems.

Prompt Injection

An agent with internet or tool access can already receive malicious instructions. A graph does not invent that problem.

A graph can make controls more explicit by placing a verification node before a privileged action:

Untrusted content → Action proposal → Security review → Privileged tool

A security node is not a perfect shield, but the architecture makes it easier to add, replace, and combine checks at important boundaries.

Private Information

Private data can already be exposed when a coding agent or assistant runs in an automatic mode with broad access.

A graph can reduce unnecessary sharing by filtering the payload passed to each node:

Local private-data node
→ redacted structured summary
→ external planning node

The important question is not whether a graph contains data. It is whether each edge sends only the data required by the next node.

Runaway Loops and Cost

Any API or cloud system can create a large bill when it is used incorrectly. This is not unique to graph engineering or AI.

The workflow should support ordinary resource controls:

Maximum attempts: 10
Maximum execution time: 20 minutes
Maximum cost: £5
Warning threshold: £3

A loop that reaches its limit should stop, report its state, and ask for intervention rather than continuing forever.

Model Behaviour Changes

A model update may change the quality of a node even when its input and output schema stays the same. That matters, but it does not break the architectural idea.

Tests and reviewer nodes already exist to detect bad results. Where consistency is important, the workflow can also pin a model version, version the prompt, and run evaluation tasks before replacing a node.

These are platform features to build, not reasons to avoid modular graphs.

The Standard Should Remain Small

The biggest danger may be creating a standard so complicated that nobody wants to implement it.

A useful first version may only need:

• a node identifier and version;
• a capability description;
• an input schema;
• an output schema;
• an endpoint or transport;
• standard success and error responses;
• timeout and cancellation behaviour.

Optional metadata could describe cost, required credentials, data restrictions, or expected latency, but the basic contract should remain easy to implement.

The internal node could be sophisticated or extremely simple. It could contain one prompt, a hundred-line program, a cluster of models, or a human workflow. The graph should not need to know.

The Human Role Changes

This does not necessarily remove humans from the system.

It changes where human effort is spent.

Instead of operating one agent step by step, a person defines:

• what each node is responsible for;
• what evidence a reviewer should inspect;
• what input and output formats are required;
• when the system should retry;
• which actions require approval;
• when the workflow must stop.

The human becomes the designer of the system rather than the person repeatedly typing the next instruction.

That is similar to the shift created by loop engineering, but graph engineering extends it across specialised roles, models, tools, and machines.

The Bigger Opportunity

At first, I thought graph engineering was simply another version of loop engineering with more specific actions and occasional human feedback.

Now I think its most important idea is different:

A node can become a replaceable capability with a clear contract.

Once a node can be an AI model, an API, a laptop, a server, a reviewer, a human, or an entire loop, the graph becomes an infrastructure pattern.

Loop engineering still matters. It defines how an individual process checks, learns, retries, and stops. Graph engineering defines how that process connects to everything around it.

The next major tool may not be another general-purpose agent that tries to do every job. It may be the runtime that lets us connect the best available agents, tools, computers, and reviewers into one understandable system.

That would move us from manually wiring AI experiments to building portable, modular AI infrastructure.

Further Reading

• LangGraph Graph API
• Temporal Durable Execution
• Model Context Protocol Architecture
• Agent2Agent Protocol
• Kubernetes Overview