Graph Engineering vs Loop Engineering

A few days ago, my feed started filling up with "graph engineering." New term, new frameworks, new experts. The claim is that instead of letting AI models loop endlessly, we should structure tasks as graphs: nodes, edges, dependencies, parallel paths.

It sounds smart. It sounds new. But something about it kept bothering me, and it took a while to articulate why.

We have been doing this for ten years.

Every time we drew a user journey map, we were building a graph. Every time we sketched a technical workflow with branches, decision points, and fallback paths, we were engineering a graph. Every flowchart, every state machine, every CI/CD pipeline with conditional gates - these are all directed graphs. We just did not call it "graph engineering" because the buzzword had not been invented yet.

That is not to say the current conversation is worthless. The application of graph thinking to AI agent workflows is genuinely useful. When you have multiple agents that need to coordinate, when tasks have dependencies, when some steps can run in parallel while others must wait - modeling that as a graph is the right abstraction. It is more disciplined than telling a model to "think harder" in a loop and hoping for the best.

But I wonder if the framing is doing more harm than good.

When we rename something that already exists, we create the impression that it is new knowledge. People who have been building workflows for a decade suddenly feel like they are behind. They start buying courses, adopting frameworks, and relearning concepts they already know under different names.

The risk is that "graph engineering" becomes what "prompt engineering" became - a term that starts with genuine insight, gets co-opted by marketing, and ends up meaning whatever the seller needs it to mean.

Here is what I think actually matters.

The graph was never the hard part. You probably already know how to break a complex process into steps. You know which steps depend on each other. You know where parallelism helps and where it creates race conditions. You learned this by shipping software, not by attending a webinar.

The hard part is execution. Making the steps reliable. Handling failure gracefully. Knowing when the graph is overengineered for the problem in front of you.

Loop engineering says: let the model iterate until the output is good.

Graph engineering says: structure the task so the model knows what to do at each step.

Both are right. Both are incomplete.

What actually works is the thing experienced engineers have always done: start simple, observe where it breaks, add structure only where needed. Sometimes that structure looks like a loop. Sometimes it looks like a graph. Most of the time it looks like a short script that gets the job done.

I am not anti-graph. I am anti-renaming. If we can help people see that the skills they already have transfer to AI workflows, we will get better adoption than if we keep inventing vocabulary.

The best framework is the one your team already understands.