Graph Engineering, Without the Hype

The useful shift is making state, handoffs, verification, budgets, and stop conditions explicit.

Good morning!

Apparently, loop engineering died before some of you even had time to try it.

Peter Steinberger posted one tongue-in-cheek line asking whether we had moved from loops to graphs. Then Hamel Husain played along with an X Article titled, “Loop Engineering Is Dead. Enter Graph Engineering.”

And suddenly, we had a new discipline.

But it was mostly all a big meme around creating new terms.

And, actually, the joke worked because it points at something real. We keep renaming the layer of the AI system we are paying attention to. Prompt engineering, context engineering, harness engineering, loop engineering, and now graph engineering overlap heavily, even if they are not identical.

So what is actually useful here?

A loop is a good starting point for one recurring job:

• an agent acts toward a goal;

• an external signal checks the result;

• failed work goes back in;

• a hard stop prevents the system from running forever.

That external signal matters. Asking a model to review its own answer is still useful, but it is not external verification. A test runner, execution result, transaction, customer outcome, or expert human review gives the system evidence from outside its own reasoning.

A graph becomes useful when one loop is no longer enough.

I break down the full argument: Claude Code dynamic workflows, Codex subagents, and the outside evidence every agent system needs in this week’s video.

Watch it here (or read the article version here):

Do you see graph engineering as pure hype, or as a useful way to think about orchestration?

Have a great week!