Graph Engineering in AI, at the Kitchen Table

The phrase is two months old

The phrase is about two months old. It traces to a single post on X in the middle of July 2026, when a developer asked out loud whether we were still talking about loops or had moved on to graphs. That was the whole event. No framework launched alongside it. No model came out. No capability shipped.

When LangChain wrote about the term a few days later, they linked that post as the thing that kicked it off and called the phrase, in their words, "the latest name for a well established approach." They had built a framework that does exactly what it describes three years earlier.

Loop engineering got the same treatment the same week. IBM published a definition on July 17, 2026: the practice of designing agentic workflows, or loops, that iteratively guide AI agents toward completing user-defined goals with minimal human intervention. Read that twice and you will notice it names something people were already doing. I had written up the loop I was running a month before IBM's definition existed.

So the phrases are about two months old, at least in print, and the work behind them is three years old. Hold that gap in mind before you let a phrase convince you that you are late.

Start with a kitchen

The same shape, in software

Now the version your feed is actually arguing about.

Say you want a weekly digest of what is happening in your market. Every Monday something has to read the latest news in your market and the blogs your buyers follow, see what your competition is doing, research your top prospects, comb your own inbox for the threads that matter, and write the whole thing up.

The loop version is one agent in charge of all five. It reads the news, then the competition, then the prospects, then the inbox, then writes the report into a folder. Along the way it decides what reads thin, whether to spin up a helper for a source, and whether to hand its draft to a checker. It stops when the report is good enough.

The graph version settles all of that before Monday. Each source gets its own worker with one job and one set of instructions, and all four run at once instead of in a line. Their output goes to a checker whose only job is to decide whether each piece is any good. Whatever clears the check goes to a writer, and the writer produces the report.

Six workers instead of one. When the competitor sweep comes back thin, the checker sends the competitor worker back out while the other three sit finished. Monday still ends with a report.

That is the picture behind every "nodes and edges" post you have scrolled past. A plan drawn in advance, or one worker deciding as it goes.

One level down

For the technical reader, here is the same thing one level down.

A graph has three parts. Nodes do the work, and LangChain's description is the plainest one out there. A node can be plain code, a single model call, a tool call, or a whole agent running its own loop inside itself. Edges define what happens next, some of them fixed and some conditional on what a node returned or on the current state. State is the object that travels the edges and gets updated along the way. That is how LangChain describes LangGraph, the framework the phrase is most often attached to.

Strictly speaking, that is all a graph is: the wiring. Because a node can be a whole agent, a loop with helpers inside it is one node from the outside. IBM's own page on loop engineering has the worker in charge delegating to subagents, a separate checker among them, so a crew is not what separates the two phrases. What separates them is where the decisions live: in flight, in the head of the worker in charge, or drawn as edges before the first call.

Anthropic had written the patterns underneath down more than a year and a half before the phrase existed. They published a piece on building effective agents in December 2024 that named five of them: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. Map them onto the kitchen and they stop being vocabulary. Orchestrator-workers is the general contractor. Evaluator-optimizer is the inspector and the trade that has to come back. Parallelization is the tiler and the painter working two rooms on the same afternoon. Routing is deciding whether this job needs a plumber at all.

Now the mechanism, because this is the part that actually explains why any of it works. A model can only hold so much at once. Everything you hand it, the instructions, the source material, the history of what it has already done, competes for room in a fixed window. Give one worker the entire job and the entire job has to fit in there together. Split the job across four workers and each one gets a full window's worth of exactly what its own task needs, and none of the other three occupy any of it.

That is why the electrician gets one plan sheet. It is also why the phrase context engineering showed up in the middle of 2025, roughly a year before this one, and why context is the hinge that both phrases turn on. Loops manage context over time, one pass after another. Graphs manage it across workers, all at once.

Handing the jargon back

Now you can pick the words back up. Every term below names a part of the kitchen you already understand.

Seven words. That is most of the vocabulary in most of the posts.

A graph is not free

Here is where I would slow down, because the feed skips this part and it is the part that decides whether any of it is a good idea for you.

Anthropic built a multi-agent research system and published both what it bought and what it cost in June 2025. The headline is real and it is large: a lead agent running Claude Opus 4 with Claude Sonnet 4 subagents beat a single Claude Opus 4 agent by 90.2 percent on their internal research eval.

Read the next part of the same post. Agents already burn about four times the tokens of an ordinary chat. Multi-agent systems burn about fifteen times. Put those two side by side and a crew runs close to four times the tokens of a single agent. Tokens are what these systems bill in, so that gap lands on the invoice, scaled by what each model charges per token.

The caveats are the useful half, and Anthropic wrote them down instead of leaving them for a critic. Their words: multi-agent systems "require tasks where the value of the task is high enough to pay for the increased performance." And some domains "that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today." They name coding as an example, because writing software has fewer genuinely parallel pieces than research does. It is also one company's internal eval, on one kind of task, run on its own models. Worth remembering before somebody quotes 90.2 percent at you as a general law.

Anthropic's own earlier advice is blunter, and nearly two years later it still holds: find the simplest solution that works, and add complexity only when you need it.

The kitchen says all of that without a single number. A general contractor costs more than a handyman, and the difference is not a markup, it is the coordination. Somebody has to sequence the trades, hold the inspection, and get one of them back on site when the inspection fails. That is worth every dollar on a full remodel. It is absurd on a backsplash.

Three questions, and you will know

You can run this on a real problem today. Three questions, out loud, about a job you actually want AI to do. Every yes points to the graph.

One. Can the job be split so that no single worker has to hold all of it? If it only makes sense when one head holds the whole thing, splitting it means four workers each know a quarter of the job and none of them know why. That is a loop, and you should be glad, because loops are cheaper and easier to fix. If it splits into pieces that stand on their own, keep going.

Two. Is the order worth fixing in advance? Some steps have to finish before others can start, or several could honestly run at once, and you would rather that be written down than decided in the moment. If it is the same step over and over until the work is good enough, there is nothing to draw. That is a loop.

Three. Does the check belong at a fixed point in the plan? A worker in charge can check its own work, and can call in a second set of eyes when it thinks to. The question is whether that check belongs at a spot you picked, with a written rule for what happens when it fails. If it does, the check is a worker of its own. That is your inspector.

Three yeses and the job wants the plan drawn first. Anything less and a loop with a good worker in charge will do.

Where I would start

Four moves, in order.

1. Write the job down as steps before you name anything. Plain sentences, one page. Nobody can wire six workers together until somebody has written down what the six of them are supposed to do, which is the same reason a pile of tools is not a workflow. That page is the graph, whether or not you ever build it.
2. Circle the steps that need a genuinely different skill. Those circles are your candidate workers. If nothing gets circled, you are finished. Build the loop and go do something else.
3. Name the checker and the standard before you build. Who signs off, and against what. A graph with no inspection is a more expensive way to be wrong, and it will be confidently wrong in four places instead of one.
4. Price the coordination before you buy it. Run the whole thing as one loop for a week. Write down what it cost and where it broke. Then split off only the piece that broke. It is the cheapest week you will spend on the whole project.

Every one of those is a decision about how your team works, not a decision about software, which is exactly why they tend to sit unmade while everybody compares frameworks. Once they are made, the people who do the work every week still have to learn to run it, and that is what I do with a whole team in the room over four weeks: Claude training for teams.

Decided as it goes, or drawn in advance

My friend asked a question that a lot of people are quietly carrying around right now, and the honest answer is shorter than the vocabulary implies.

A loop is a graph with one worker in charge. Everything the new phrase describes is what happens when the plan is worth drawing before anyone starts: give each worker its own sheet, fix the order, write the inspector in, and say on paper what happens when the inspection fails.

The words will change again. They have twice this year. What will not change is the question underneath, and it is a question you can answer without knowing any of the words: how many kinds of skill does this job need, and is the plan worth drawing before anyone starts?

Answer that at your own kitchen table, and you already know which one to build.

All signal. No noise.