---
title: 'Four graphs are hiding inside one term'
description: 'Graph engineering is a useful way to expose control, state, knowledge, and improvement relationships, but only when we stop treating every graph as the same thing.'
canonical_url: 'https://darkfactory.dev/blog/four-graphs-are-hiding-inside-one-term'
markdown_url: 'https://darkfactory.dev/blog/four-graphs-are-hiding-inside-one-term.md'
collection: blog
---

# Four graphs are hiding inside one term

Graph engineering has arrived with the usual signs of a new AI category: a catchy name, a vendor product, a backlash, and an argument about whether the thing exists at all.

The name began as a joke. Peter Steinberger asked whether we were still talking about loops or had moved on to graphs, and a few hours later Hamel Husain posted the deliberately provocative ["Loop Engineering Is Dead. Enter Graph Engineering."](https://x.com/HamelHusain/status/2078346425621237935) Within days there were explainers, a terminology audit, and a critique. No framework shipped. No capability changed. The discourse was chasing a name, not an artifact.

The name may not last. The engineering problem will.

An autonomous system has work to perform, state to carry, decisions to make, evidence to collect, and limits it must not cross. Those relationships exist whether the architecture is drawn as a graph, implemented as a loop, buried in prompts, or scattered across application code.

The useful question is not whether graph engineering is real. It is whether making those relationships explicit helps us build a safer and more capable system.

Often it does. Sometimes it is needless ceremony. The difference depends on which graph we mean.

## A loop is already a graph

The supposed choice between an agent loop and a graph is mostly false.

An [agent loop](/glossary/agent-loop) observes state, chooses an action, invokes a tool or model, receives feedback, updates state, and decides whether to continue. Draw that process and you have a directed cyclic graph. It returns to an earlier point by design.

This matters because people often use [directed acyclic graph](/glossary/directed-acyclic-graph) as shorthand for graph-based orchestration. A DAG works well for one-way dependencies. Agent work commonly retries, revises, asks for missing information, pauses, resumes, or calls a tool more than once. Those behaviors introduce cycles.

[LangChain's three-year retrospective](https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph) makes the practical case. Nodes can contain ordinary code, a model call, a tool, or a full agent. Edges select what may run next. Some transitions are fixed, some conditional, and some created dynamically. The useful boundary is not graph versus agent. It is deterministic control versus model judgment.

That source is written by the company behind LangGraph, so it is also product marketing. It does not prove that every agent needs a graph framework. It does describe a real production design problem.

## The four, separated

The best correction I found comes from [Turing Post's terminology audit](https://www.turingpost.com/p/is-graph-engineering-real-why-everyone-is-talking-about-it). It separates several ideas that the phrase tends to collapse. I split its execution trace into an execution graph and the trace that graph produces, because planned work and observed events answer different questions.

### The control graph

A [control graph](/glossary/control-graph) defines the steps a system may execute and the conditions that select what happens next.

This is where deterministic checks belong. Code can require a test to pass before promotion, route a failed result into repair, stop after a budget is exhausted, or require human authority before an irreversible action. The model may supply judgment inside a node, but the model does not need to own every edge.

### The execution graph

An [execution graph](/glossary/execution-graph) represents the work instantiated for a run and the dependencies among its tasks. It can reveal which jobs may run concurrently, who owns each result, where retries occur, and where results must join before the next step begins.

The control graph describes permitted routing. The execution graph shows the work created under that control. The [trace](/glossary/trace) records what actually happened.

Those are related, but they are not interchangeable.

### The knowledge graph

A [knowledge graph](/glossary/knowledge-graph) connects entities, concepts, and claims through named relationships and provenance. It helps answer questions whose meaning lives in connections rather than in one matching passage.

[Microsoft GraphRAG](https://microsoft.github.io/graphrag/) is one concrete version of this approach. Its indexer extracts entities, relationships, and claims, builds communities and summaries, and uses those derived structures during retrieval.

The word derived is load-bearing. A model-extracted graph is an index over source material. It is not the source material and it is not automatically true. Every important node and edge needs a path back to the artifact that supports it.

### The improvement graph

An [improvement graph](/glossary/improvement-graph), a category Turing Post credits to Carlos Perez, makes the system that changes the system visible. An optimizer proposes a prompt, skill, workflow, or harness change. Evaluators measure it. Counter-metrics watch for regressions. An auditor checks the evidence. A promotion gate accepts or rejects the mutation.

This is more useful than the vague idea of a self-improving agent. It gives each authority a name and lets us ask whether the evaluator is actually outside the thing being optimized.

It is also the least mature of the four categories. Treat it as a design lens, not a settled discipline.

## Graphs move control out of the model

The strongest reason to use an explicit graph is not visualization. It is enforceability.

Prompts are inputs to a probabilistic system. They can describe a policy, but they do not reliably enforce one. An external transition can refuse to continue when evidence is missing. A persisted state can survive a crash. A budget can stop a loop. A gate can require a human decision for a production deletion.

This is the part of graph engineering that belongs in a dark software factory. The factory cannot depend on the model remembering which promises it made three hours ago. State, authority, and promotion rules need durable representations outside inference.

The graph also gives us a better vocabulary for review. For each node, what can it see and change? For each edge, who chooses it? For each state transition, what evidence permits it? For each cycle, what guarantees termination? For each join, what happens when one branch fails?

Those questions are more valuable than the diagram.

## A graph does not create truth

There is a dangerous version of this idea in which several agents debate, critique, score, and approve one another, and the resulting network is treated as independent verification.

It is not.

[Louis-François Bouchard's critique](https://www.louisbouchard.ai/graph-engineering-explained/), building on Carlos Perez's point, makes the essential argument: a graph of correlated agents can organize error without correcting it. Agents that share a model family, prompt assumptions, context, or evaluator can agree for the same wrong reason.

A neat graph of weak evidence is still weak evidence.

Important truth signals must come from outside the builder and sometimes outside the graph: a deterministic test, a trusted reference implementation, a production observation, a held-out scenario, a physical measurement, or an accountable person with relevant knowledge.

The graph can require that evidence and preserve its provenance. It cannot manufacture independence.

## Where graph engineering costs more than it returns

Explicit structure has a cost. A graph becomes a liability when the work is too open-ended to know the important states and transitions in advance. Teams can spend more time maintaining a brittle workflow than learning from the task.

That suggests a simple rule:

> Encode the paths whose safety, recovery, cost, or accountability matter. Let exploratory judgment remain flexible inside bounded nodes.

A short research task may need one agent loop with a deadline and an acceptance check. A production migration may need a persisted state machine, parallel execution graph, independent verification branch, rollback path, and promotion authority. Drawing both with the same level of machinery would be a category error.

The graph earns its complexity when it makes an important boundary easier to enforce or inspect.

## The position I am taking

In the dark factory I am building, Markdown remains the canonical research record. Sources, glossary terms, factory areas, and conclusions declare relationships in front matter and links. A public JSON graph can be generated from the published subset, and a browser can let readers explore it.

That graph will not become a second truth store. It is compiled from the documents, just as a site page is rendered from Markdown. If the graph and the source disagree, the source wins and the projection is rebuilt.

The same principle applies to the operating factory:

1. Put deterministic behavior in code.
2. Use model judgment where the work requires judgment.
3. Persist state outside the model.
4. Make retries, stopping rules, and promotion gates explicit.
5. Keep the evidence that matters outside the component being judged.
6. Trace the path a real run took.
7. Add graph structure only when it exposes a boundary worth owning.

Graph engineering is real in the same modest way that workflow engineering, state-machine design, and provenance engineering are real. It is a useful collection of practices with an unstable name.

The name is not the opportunity. Moving invisible control out of prompts and into inspectable systems is.

---

*The evolving source trail lives in the [Orchestration, state, concurrency & recovery](/factory/orchestration-state) and [Context, memory, knowledge & skills](/factory/context-memory-skills) sections. If your team is moving toward autonomous software production, [Agency Intentional](https://agencyintentional.com/) works on the control, evidence, and operating boundaries that make it usable.*