Graph engineering explained: how it differs from prompts and loops
Graph engineering means drawing an AI system as a network of blocks and arrows before you build it: which step does what, which routes the work may take, what the steps hand to each other, and where a checker or a person looks along. A prompt is one instruction. In a loop, the model picks its own next step. In a graph, the designer fixes the route.
You give an AI one big job: find twenty companies, read their sites, judge whether they fit us, and write each a mail. The result looks tidy and is slightly off. Company seven no longer exists and company twelve sits in another industry. You cannot tell which step went wrong, because all of it happened at once.
In July 2026 a question went around the AI world: are we still talking about loops, or have we moved on to graphs? The term graph engineering came out of the argument that followed. Updated on 15 October 2026. The term is three months old, has no fixed definition and is partly a new name for something that already existed. That sets how much you should expect from it.
Graph engineering at a glance
The facts in one place, as of 15 October 2026.
| Item | Short answer |
|---|---|
| What | You plan the steps of an AI system up front: blocks, arrows, shared memory, checks and human sign-offs. The model thinks inside a block, and the route is fixed. |
| When the term appeared | Around 18 July 2026, in a discussion on X. Older relatives go by other names (flow engineering, January 2024). |
| Who | Peter Steinberger asked the question that started the term, without defining it. A survey paper with 35 authors followed in August 2026. |
| What it is not | It is not a settled, standardised discipline. It is not automatically a knowledge graph or GraphRAG, and it does not mean adding more agents. |
| Where it comes from | Workflows, state machines and flowcharts are decades old. Frameworks such as LangGraph (January 2024) build them for AI agents. |
| Key source | The arXiv survey "Graph Engineering in the Era of LLM Agents" (21 August 2026), and the LangGraph documentation for the building blocks. |
What graph engineering is, in plain language
Picture two employees. The first is told "sort out the quote for this client" and works out what that takes. Sometimes he skips the VAT check. The second gets a work instruction with a flowchart: fetch the client's details, calculate the price, have a colleague check it, then send. He may think, but only inside his step. The route is fixed.
Graph engineering is the second way of working, applied to AI. The word graph here means a drawing of boxes and arrows, not a chart with axes. You design that drawing in advance and the model works inside the boxes.
The building blocks follow the documentation of LangGraph, the best-known framework for this, plus third-party tutorials.
Blocks (nodes in the jargon). A block does one task. DataCamp offers a useful test: can you describe the task without the word "and"? If not, you have two blocks.
Arrows (edges). An arrow says which block follows which. Some arrows are fixed. Others are conditional: a small routing function looks at what has happened so far and picks the next arrow, or stops.
Shared memory (state). All blocks read from and write to the same logbook: the assignment, the sources found, the draft, the checker's comments. What a block passes on lives there. What is missing from it, the next block does not know.
Parallel branches. Three blocks can work at the same time and merge their results afterwards.
A separate checker. A block that writes nothing and only checks the result. DataCamp calls it usually the most valuable block in the graph.
A human gate. The graph pauses and waits for your approval. For that, the system saves a snapshot after each step (a checkpoint).
A maximum number of repeats. If the check keeps doubting, the graph goes round in circles. A limit stops that.
One confusion you need to know about. A task graph describes how work flows. A knowledge graph describes what is known, with companies, people and the relations between them. Both are called graphs. DataCamp and AI Builder Club say graph engineering is not about knowledge graphs or GraphRAG. This article is about the task graph.
Figure 1 shows a task graph at work. An assignment comes in and goes to a plan. The work then splits into three blocks running at the same time: search, read and calculate. Everything comes together at the check. If the check doubts, the work goes back to the plan. If the check approves, it goes to you, and only after your approval to the result.
The model picks no route here. It writes and reads inside the blocks, and the designer draws the arrows. When something goes wrong, you open the shared memory and see which block let the error in. That is the biggest practical gain over one big job done at once.
Prompting, loops and graphs: who decides the next step
Sources such as Design Gurus, Future AGI and PALO IT keep landing on the same question: who decides what the next step is? With a prompt there is no next step, because you ask once and get one answer. In a loop the model decides along the way: it tries something, looks at the result and picks its next move, until it thinks it is done or a limit stops it. In a graph the designer decides up front. The model at most chooses between branches you drew.
The table sets the three side by side, in my own words.
| Prompt | Loop | Graph | |
|---|---|---|---|
| Who picks the next step | Nobody, there is one call | The model, while it works | The designer, in advance |
| What you design | Instructions, examples, the shape of the answer | Tools, budgets, stop rules, checks | Blocks, arrows, shared memory, conditions |
| Memory | None | Within one run | Explicit, shared, with snapshots |
| How it usually fails | A wrong or badly formatted answer | Repeats a failed action, never stops, or is confidently wrong without crashing | One branch fails or gets work routed to it wrongly while the totals look fine, or an input arrives that has no path |
| How you test | Score sample questions against good answers | Judge whole runs on goal, steps and cost, using fixed test tasks | Each block alone, then the routing, then the memory, then end to end |
| Cost in calls | Nearly fixed: one call | Varies: three steps or thirty, so you need a ceiling | Bounded by the design, but parallel branches and repeats multiply the count |
Figure 2 shows the same three as pictures.
A loop is the smallest graph
AI Builder Club writes it outright: a loop is the smallest graph, one block with an arrow pointing back at itself. Dale Everett said the same. Formally that is right, and it feeds the criticism: if every loop is already a graph, what does the word add? In practice the three form a ladder: start at the bottom and climb only when you have to.
How each approach fails
A prompt fails visibly: the answer is wrong and you see it at once. A loop fails more quietly. Addy Osmani, who wrote the essay Loop Engineering in June 2026, warns that "done" is a claim and not proof. He advises a separate checker, preferably running a different model.
A graph fails in a third way. The whole thing looks fine while one branch keeps working wrongly, or one kind of input fits nowhere. Build too early and you have forty blocks when one block was not yet reliable. Future AGI and Design Gurus add some arithmetic: a system that gets 95 percent per step has only about a 36 percent chance of getting all of twenty steps right. That is a worked example and not a measurement, but it shows why long chains need a check.
How you test them
For a prompt you score sample questions. For a loop you judge whole runs on goal, steps and cost. For a graph you test each block alone, then the routing, and you inspect the memory. Anthropic advises judging outcomes and not exact steps, and starting with about twenty test questions.
What they cost in calls
Every block with a model inside is at least one call. DataCamp counts about three calls for a three-block writing graph when the check approves in the first round and about five when it rejects. A single loop costs about one. A five-way fan-out with a merge and three repeats reaches fifteen or more. Set limits and log usage per block. I name no prices.
They stack
You do not have to choose. A block in a graph can run a loop of its own: a search block that tries until it finds something, with a maximum. Inside that loop sits a prompt again. The arXiv survey puts them on a ladder: prompt and context at the model, harness and loop at one agent, graph at the whole system. That is the authors' claim, not a settled classification.
Where it comes from and why the term is contested
A short timeline, as far as I could check the sources:
January 2024. Flow engineering, a forerunner, in a paper on a system called AlphaCodium (arXiv 2401.08500). LangGraph appears around the same month.
19 December 2024. Anthropic publishes "Building effective agents". It separates workflows, where predefined code paths steer the model, from agents, where the model picks its own route. Its advice is to start with the simplest solution. The patterns it describes (chaining, routing, parallel work) are in effect graph shapes under other names.
7 or 8 June 2026. Addy Osmani writes about loop engineering, with five building blocks plus memory and the warning that "done" is not proof.
18 July 2026. Peter Steinberger asks on X whether we are still talking about loops or have moved to graphs. Another source says 17 July. I could not open the original post, so I rely on sources that describe it. It was a question about wording, not a definition. The term grew out of the discussion afterwards. Dale Everett replied that a loop is already a simple graph. Harrison Chase of LangChain is said to have asked whether it is LangGraph under another name. I pass that on approximately, and his company makes LangGraph.
21 August 2026. A survey paper with 35 authors appears on arXiv, "Graph Engineering in the Era of LLM Agents". It describes explicit, changeable graphs that cover tasks and agents as well as system states, in three views: task organisation, agent coordination and runtime state management. This comes from the abstract, I did not read the rest.
The criticism
The criticism is serious and I share a good part of it.
It is a new name for existing practice. State machines, flowcharts and workflow engines have done this for decades. PALO IT calls it largely a rename of orchestration. DataCamp calls the term a useful shorthand, not a necessity.
The term is overloaded. Some mean a task graph, others a knowledge graph. The scale varies too: a way to design whole systems in the survey, a handful of blocks in the blogs.
Many sources are vendor blogs. Viral claims, such as graph engineering replacing RAG at a large company, I found nowhere backed up. A reported figure of 18 percent more accurate and 85 percent cheaper comes from a study on industrial diagrams. Ask of every gain which kind of graph it was and what it was compared with.
The gains are often small. A Berkeley team (arXiv 2503.13657) looked at more than 1,600 traces from seven multi-agent frameworks and described fourteen ways they fail. The authors see room for better design. Anthropic reported that its multi-agent system scored 90.2 percent better than a single agent on an internal test, which is the vendor's own measurement, at about fifteen times the tokens of a chat. In a small experiment by Analytics Vidhya the graph was about 6.0 seconds faster than the loop, with no better accuracy.
Defenders say the architecture is real and useful even if the name is not. A shared name makes conversations easier, and some tasks call for a fixed route, such as human approval before irreversible steps. PALO IT adds the opposing view: some tasks are truly agentic and a fixed path is worse for them. Loops are easier to run, debug and roll back, and every hand-written branch takes a decision away from the model and can go stale as models improve.
My reading: the critics and the defenders are both right. The term is new, the idea is old, and drawing the thing first is a good habit.
My bots are a small graph
I work with a setup that I can read as a graph after the fact. This is what I do, in my own words (my Dutch, translated here): "I have the bots search for specific leads, very specific requirements, and then when there is a match the stalker picks it up and finds out all the information about the company. After that the analyst gives an estimate of the chances, and the head of desk gives me all the filtered prospects who are worth approaching for us."
I use Grok Bot for this, from the Netherlands through Cursor Pro+, with four bots: scout, stalker, analyst, head of desk. I wrote earlier about OpenAI Dots, but I have not used it. The two sit side by side in my comparison.
If I follow the terms, this is a small graph. There are four blocks, each with its own job. There is a conditional arrow: only when the scout finds a match does the stalker go to work. And there is a filter at the end: the head of desk gives me only the prospects worth approaching. That is a reading, not proof that I practise graph engineering. I do not use LangGraph.
What I see: each bot gets one job. The scout needs to know nothing about analysis. The filter at the end decides what reaches me. That is an observation about the setup, not a conclusion about how well it works.
What I do not know, I want to say plainly. I do not know how the bots hand over to each other: whether they share a memory or send each other something. I have no numbers, no results and no time saved to report, so I cannot say whether this works better than one bot with one long assignment. I am describing a recognisable pattern, not a measured result.
Draw your first graph on paper before you build anything
Pen and paper are enough to start. My example is an assumption and not a real case: a small business that answers quote requests by email. The sources give no small-business cases. They do give principles: an approval gate before irreversible actions, a separate checker, limits on repeats and cost. I apply those.
Write the goal in one sentence. "Every quote request gets a draft reply with a price indication within one working day, ready for me to review."
Name the blocks and give each a task without "and". For example: read (what does the client ask), look up (does this fit our offer), calculate (the indication, in plain code), write (the draft) and check (does it match the request).
Decide what each block passes on. That is the shared memory. Write down per block what has to go in: the summary of the request, the services found, the calculated figures, the draft, the verdict.
Put in a check that is not done by the writing block. The checker compares the draft with the original request and returns only "good" or "revise" with a reason. On "revise" it goes back to the writing block.
Put a person on every irreversible step. Sending, paying and publishing never happen without your approval. In this example the system sends nothing to the client. Parking the draft is the end.
Set a maximum number of repeats and a cost ceiling. For example two revisions. After that the draft goes to you with a flag. Decide too how many calls one request may cost.
Test each block alone, then the route. Give the read block ten real requests and check the summaries. Then test the routing with a request that looks like nothing you expected, and only then run end to end.
Start with the smallest version. A fixed order with no feedback may be enough. Add an arrow when you see a mistake it would prevent.
For many small-business tasks a fixed workflow or a single loop is probably enough. That follows from the advice to start simple, but nobody has tested it on small businesses.
To do this with an AI assistant, paste the prompt below into a chat and fill in the part in brackets:
Help me work out a graph on paper for this task: [describe the goal in one sentence]. Give the blocks, each with one task you can describe without the word "and". For each block say what it reads from the shared memory and what it writes to it. Say which arrows are fixed and which are conditional. Add a separate checker that does not write anything itself. Mark every step that cannot be undone (sending, paying, publishing) and put a human approval there. Suggest a maximum number of repeats and say which blocks need a model and which can be plain code. Finish with the smallest version to start with and an honest view on whether a prompt or a single loop might be enough. Do not invent data and ask if something is unclear.
When a graph does not pay off
Start with the simplest solution, says Anthropic, and add complexity only when it demonstrably improves things. Design Gurus turns it into a ladder: take the lowest rung that works. Prompt, then loop, then graph.
A prompt is enough for a fully specified task with no lookups or actions.
A loop is enough when an agent with a few tools can check its result and try again, when the steps depend on what the model finds along the way and when mistakes are cheap or reversible.
A graph pays off with separate specialists per step, lookups that can run at the same time, an independent check, a person who has to approve, or long tasks you want to resume after an interruption.
Sometimes a graph is overkill. DataCamp gives an example: five blocks for 800 hotel addresses, where a short script would have done better. If all steps are fixed up front, you need no model to route. Blocks that merge into a loop without loss should. Anthropic considers multiple agents a poor fit when they share a lot of context, depend on each other heavily or leave little to run in parallel, as with most coding tasks.
Frequently asked questions
What is graph engineering?
Graph engineering means designing an AI system in advance as a network of blocks and arrows, with shared memory, checks and human sign-offs. The term dates from July 2026 and has no fixed definition.
What is the difference between prompt engineering and graph engineering?
Prompt engineering is writing one good instruction for one call. Graph engineering is designing several steps and the route between them, and a prompt becomes the content of a single block.
What is the difference between graph engineering and loop engineering?
In a loop the model picks its own next step until it is done or a limit stops it. In a graph the designer fixes the route in advance and the model at most chooses between branches you drew. A loop is the smallest graph.
Is graph engineering the same as LangGraph?
No. LangGraph is a LangChain framework for building such a graph. Graph engineering is the design itself, and you can do it with other tools or plain code.
Do I need graph engineering as a business owner?
Probably not first. Start with a prompt, move to a loop when the task asks for it, and use a graph only when you need separate steps, an independent check or a human approval. The sources give no small-business cases, so this is an inference.
What is the difference between a task graph and a knowledge graph?
A task graph describes how work flows: which steps, in what order, with which checks. A knowledge graph describes what is known: companies, people and the relations between them.
Is graph engineering a hype?
Partly. The name is new and the practice old, many sources are vendor blogs and the gains vary. The fixed route, the check and the human approval are still useful design choices.
If you want to talk it through
Unsure whether a task needs a prompt, a loop or a drawing with blocks? I am happy to think along. Book an intro through makeitmatter.studio.
Sources
Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence, arXiv 2608.21156, submitted 21 August 2026.
LangGraph Graph API, LangChain, consulted 15 October 2026.
Building effective agents, Anthropic, 19 December 2024.
How we built our multi-agent research system, Anthropic, 13 June 2025.
Loop Engineering, Addy Osmani, June 2026.
Why Do Multi-Agent LLM Systems Fail?, arXiv 2503.13657, Berkeley, 2025.
Graph Engineering Guide, DataCamp, 24 September 2026.
Graph Engineering Guide 2026, AI Builder Club, 20 July 2026.
Peter Steinberger's Loops or Graphs Tweet, AI Builder Club, July 2026.
Prompt engineering vs loop engineering vs graph engineering, Design Gurus, 29 July 2026.
Prompt engineering versus loop and graph work, Future AGI.
Loop and graph engineering, PALO IT.
Agent harnesses and loops next to graphs, Analytics Vidhya, 4 August 2026.
