Graph Engineering Is Mostly Airflow With A New Coat Of Paint

Graph Engineering Is Mostly Airflow With A New Coat Of Paint

There's a new buzzword rolling through the AI world, and it landed with all the subtlety of a brick through a window: graph engineering. It's the top rung of what people are now calling a "scope ladder" — prompt, context, harness, loop, graph. Five labels since 2022, each one a bigger box for the same question: how do I get a useful result out of a model?

I've been a professional engineer for over twenty years. I've scheduled ETL pipelines in banks, queued jobs through Laravel at 3am in Amman, and watched trend after trend arrive dressed as a revolution when it was really a reorg. So let me save you six months: most of graph engineering is Airflow with a new coat of paint. But one part of it is genuinely real, it maps embarrassingly well to the queues you already run, and it's the only thing worth your time. Let me show you which is which.

First, the ladder is mostly one idea wearing five hats

Every label in that ladder exists because the one below it hit a wall. That's not a conspiracy — it's just how the industry works.

• Prompt → context: because perfect wording can't supply facts the model doesn't have. No sentence you write gets a model to know the date of your last production deploy.
• Context → harness: because a model that can only read can't change anything. It needed hands — tools, a filesystem — and a mirror: test output, compiler errors it could argue with.
• Harness → loop: because one pass through the tools rarely lands the job. Quality came from iteration count, not prompt cleverness. The people winning weren't writing better prompts; they were letting the agent fail and retry.
• Loop → graph: because one loop can't parallelise, can't specialise, can't independently check its own work. One context, one responsibility — and some jobs need an organisation, not a single worker.

Rungs two, three, and four — context, harness, loop — are so entangled that working engineers use the words interchangeably. Only two boundaries hold weight: the shift from instruction to information (01→02), and the shift from one worker to an organisation (04→05).

That last one is graph engineering. The rest of the ladder is the same idea in five different coats.

So what's actually new in graph engineering?

At rung five, the question stops being "how do I get one model to do a thing" and becomes "how do many loops wire together?" One word: topology. The scope is the whole system — several rung-04 loops, deterministic functions, validators, tools, and humans, all wired together.

The levers are nodes, typed edges, shared state, parallel branches, verifiers, handoffs, stop conditions, budgets. And here's my contrarian bit: none of that structure is new. DAG schedulers and workflow engines have been drawing these graphs for a decade. Airflow has been orchestrating dependencies since 2015. If all you want is to draw boxes and arrows and run them on a schedule, you could have done that when most LLM developers were still in high school.

The only truly new thing — the entire delta, the whole novelty worth your attention — is that the nodes now interpret their tasks instead of following fixed rules.

That's it. That's the whole revolution. And it's a big one, because it changes every implicit assumption you had. When a node is deterministic, you can trust it, unit test it, predict its cost. When a node is a model, it will occasionally lie to you — confidently, politely — and take as long and cost as much as it likes. Which means state, vetoes, and budgets stop being implied and have to become explicit. That's the real engineering. Everything else is paint.

Two things called the same name

Before you build anything, you need to know the term is split. "Graph engineering" means two genuinely different things, and a lot of the confusion in the hype is people using the same word for both:

• Meaning A — Orchestration graph. Nodes are units of work, edges are permitted transitions. This is control flow. Ecosystem: LangGraph, Mastra, Temporal. This one sits genuinely above loop engineering. My favourite one-liner for it: loops are subroutines, graphs are programs.
• Meaning B — Knowledge graph / GraphRAG. Nodes are entities, edges are typed relationships — caused, owns, wrote. This is data and retrieval. Ecosystem: Neo4j, GraphRAG pipelines. It's a smarter way to fill one context window. My favourite one-liner there: vector search finds things that sound like your question; a graph finds things connected to your answer.

The disambiguation question is brutally simple: are you routing work, or retrieving knowledge? A is control flow, B is data. They do compose — a node in graph A can retrieve by traversing graph B — but if you don't know which one you're building, you will build the wrong thing.

Do you even need a graph? Be honest

Here's the most useful thing I can hand you, and it's three questions:

1. Does the work have two or more sub-tasks that could run in parallel, or need different specialised context?
2. Do you need an independent check on the output — something other than what produced it?
3. Is there a point where a human must approve before work continues?

Two or more yeses? Build the graph. Zero or one? Stay on a single loop. A single well-guarded loop is cheaper, easier to debug, and good enough for most tasks. Reaching for a graph too early is the single most common way to turn a working agent into an unobservable mess. I've watched teams install LangGraph and instantly lose the ability to explain what their own system did on any given run.

And here's my strong opinion, stated plainly: don't install a graph framework yet.

A graph is a plain data structure plus a fifty-line runner. Build that first. You'll understand the failure modes from the inside, and you'll know exactly what a framework would actually buy you. There are genuine reasons to adopt LangGraph, Mastra, or Temporal later — durable checkpointing, human-in-the-loop pauses that survive days, time-travel replay, a visual trace UI. Those are real features. They are not reasons: "this is how everyone does it," or wanting the word graph in your architecture diagram, which I promise you a VP will not read as deeply as you think.

The five ways agent graphs die in the first month

If you do build one, the first thirty days will throw five traps at you:

1. The verifier shares the drafter's model and context. It rubber-stamps its own work — a model that wrote a thing will nod approvingly at that same thing. Give the verifier fresh context and an explicit checklist, or make it deterministic code.
2. Edges decided by free text. "I think we should retry" is not an edge. Return a validated enum; route anything unrecognised to escalate.
3. No step budget. A two-node cycle with no cap is an unbounded invoice. Every graph needs a global ceiling, not just per-node retries.
4. Every node is an agent. Threshold checks and enum routing belong in code. LLM nodes are for ambiguity only.
5. Unlogged runs. Without a per-node trace you can't answer "why did it do that?" — and that question arrives, without fail, on day three, from your boss.

The discipline that saves you from all five, in one line: an agent that runs out of budget escalates. It does not fail quietly.

Not every node should be an agent

Listen, this is the part too many architecture diagrams get wrong. The model is not the star of every scene. The split is not "use AI everywhere" — it's about where ambiguity lives.

• If it's deterministic, plain code wins. Invoice approval thresholds, plan-active checks, routing on a known enum — anything you can unit test is code, full stop.
• If there's ambiguity, an LLM earns its place. "Is this email a refund request?" Summarise, draft, translate. Planning under open conditions. Interpreting messy human input. That's model territory.

And here's the budget angle nobody puts in the blog posts: each LLM node multiplies your cost per run by roughly its retry ceiling. A node that retries five times isn't one model call — it's up to five, plus the verifier, plus the retries on that. The code/LLM split isn't just architecture; it's the difference between pennies per run and a bill that lands like a licence renewal on a Friday.

Here's the kicker: you've already built this

Now the part that should land hardest if you're a Laravel developer. Read this mapping and tell me it doesn't make you a little uncomfortable — because I already know the answer, I built this exact thing years ago:

• a node = a queued Job class (ClassifyTicket, DraftReply)
• a typed edge = a PHP enum the job returns, validated before dispatch
• shared state = an agent_runs row
• a trace = agent_run_steps rows: node, tokens, latency, cost
• a step budget = a steps_remaining column, decremented atomically
• a retry cap = $tries and $backoff
• a verifier = a Job allowed to re-dispatch its own predecessor
• a parallel branch = Bus::batch([...])
• a join node = the batch's then() callback
• a terminal state = a status enum: done, escalated, failed
• a human checkpoint = awaiting_approval, resumed by a controller action

Read that table again, slowly. You already know rung 05. The wiring is Laravel queues. The orchestration, the retries, the state, the escalations, the sits-awaiting-a-human — it's all there. Graph engineering isn't new. It's the architecture you've been building for twenty years, where the only thing that changed is the workers.

And that changed worker is the entire problem. Your old queue workers were deterministic — they did the same thing every time and failed predictably. Your new workers are non-deterministic and, occasionally, they will lie to you. Which is exactly why every edge now needs an explicit guard: a verifier, a hard attempt cap, a stop condition. That's not buzzword territory. That's just good engineering with the stakes raised, because the component in the middle of your pipeline has an opinion.

Not a rebrand. A rebrand plus one hard truth

So let me land this the way I started it. Most of graph engineering — the boxes, the arrows, the DAG you could draw in Airflow when Trump was still in his first term — is exactly what we've always drawn. A rebrand. New paint, same skeleton, and a lot of people charging consulting fees to draw it for you.

The one delta is real, and it's not the graph at all — it's the nodes that interpret their tasks. That single change forces state, vetoes, and budgets to become explicit instead of implied, and that's where the genuine engineering work of the next decade is going to happen. The engineering lives in the edges, not the node count. Always has.

So my advice: don't chase the graph framework — chasing the word graph in your diagram is how money disappears. Build the plain data structure. Build the fifty-line runner. Give each node a guard. Log everything. And for the love of your own sanity, leave an escalate edge — every graph needs a door marked give this to a human.

Because here's the provocation I want to leave you with: the AI field is not discovering orchestration. It's rediscovering it, badly, and selling it back to you as new. The question isn't "should I adopt graph engineering?" The question is whether you'll notice you've known the answer since your first queue worker. The only thing new under the sun is that the workers now have opinions. Tell me — how are you planning to verify theirs?