Every eighteen months our industry finds a new noun for the same problem.
First it was prompt engineering. Then we discovered that the prompt was never the hard part and it became context engineering. Then context became plumbing and we started talking about loop engineering. And now, if you open LinkedIn on any given morning, someone will tell you that loop engineering is dead and graph engineering has arrived.
I have been around long enough to get suspicious when a word travels that fast. So I went looking for the oldest thing I could find that described what we are actually doing. It turned out to be a business process management paper from 2005, and it has made me rethink which end of this problem is the interesting one.
What graph engineering actually is
The shape is concrete enough. A planning agent decomposes the ticket. Implementation agents work the pieces in parallel, each in its own sandbox. A review agent inspects every diff, a test agent pokes the running result, a verifier decides merge or rework, and failures route back to planning.
Look closely at that picture. Every one of those boxes is still a loop. An agent iterating until its gate passes.
The most honest definition I have read comes from one of the term’s sceptics. Louis Bouchard calls a graph what you get when one loop is no longer enough, with every node in the graph still a loop. André Lindenberg, in his piece From Loops to Graphs, adds the clarification that matters most: graph engineering, in the sense worth keeping, is not about graphs of knowledge. It is about the topology of the system that builds your software.
That is a useful idea. It is not a new discipline.
The sentence that reframed it for me
Lindenberg writes one line that I have not been able to put down:
A loop does not satisfy your goal; it satisfies the gate you wrote, so the gate is the multiplier on everything the loop produces.
Read that again, because it quietly demolishes most of what gets sold as agent strategy.
Your agent is not trying to build good software. It is trying to pass your check. If your check is weak, the loop will find the cheapest path through it and hand you something that looks finished. Scale that loop into a graph of twenty loops and you have not solved anything. You have multiplied it. Graph engineering does not retire the question of the gate. It multiplies it.
And here is the part I find genuinely encouraging: a gate is by definition deterministic. It is a check you can run without a model. A test that fails on the pre-patch code. A type signature. A policy. A schema. A human reading a hundred-line vertical slice instead of a two-thousand-line diff at the end.
Cognition’s Frontier Code only credits an agent’s tests if they fail on the pre-patch code, and runs a judge over every diff for design-quality rules. That is not clever prompting. That is engineering discipline, applied to a new kind of worker.
We have been here before, in 2005
Here is the part that genuinely surprised me while I was thinking this through. The most useful description of what an agent loop is was written more than twenty years ago, by people who had never seen a language model.
In 2005, Wil van der Aalst, Mathias Weske and Dolf Grünbauer published Case Handling: A New Paradigm for Business Process Support. Van der Aalst is the process-mining professor from Eindhoven; this is mainstream, well-cited business process management research, not a fringe paper. Their central distinction:
Unlike workflow management, which uses predefined process control structures to determine what should be done during a workflow process, case handling focuses on what can be done to achieve a business goal.
And on the role of the system:
The knowledge worker in charge of a particular case actively decides on how the goal of that case is reached, and the role of a case handling system is assisting rather than guiding her in doing so.
Read that with 2026 eyes. Assisting rather than guiding. Driven by the data of the case rather than by a predefined control-flow graph. The worker decides how the goal is reached. That is a remarkably precise description of an agent loop, written in the era of Staffware and Petri nets.
Their critique of rigid workflow lands just as hard. They list four problems, and two of them should make anyone building agent systems uncomfortable. Work gets straight-jacketed into activities that are atomic to the system but not to the person doing them. And context tunneling: by focusing on control flow, the data relating to the whole case is pushed into the background, so the worker only ever sees the fragment their current step requires. Anyone who has watched an agent make a confident, locally-correct, globally-stupid decision has watched context tunneling.
They dramatise it as the blind surgeon: a surgeon who sees only the work-item in their in-tray, ignores everything not directly related to the current procedure, and executes exactly what the protocol specifies. The paper’s verdict on that design is blunt, and it is my favourite line in the whole thing:
If users are forced to bypass the workflow system quite frequently, the system is more a liability than an asset.
Which is exactly why the gate matters more, not less
So if case handling is the better name for the loop, what does that do to the gate argument?
It sharpens it considerably, and it points somewhere slightly uncomfortable for the current fashion.
A production workflow is bounded by its topology. You drew the graph, and the graph constrains what can happen. The structure is quietly doing your verification for you: an agent cannot wander off, because there is nowhere to wander to. Much of what is being sold as graph engineering is, honestly, this — a predefined control-flow structure with a language model inside each box. That is not the radical end of the spectrum. It is the conservative one.
Case handling is explicitly not bounded that way. Its entire promise is “what can be done” rather than “what should be done”. The moment you accept that promise, the topology has stopped being your constraint.
The constraint does not vanish. It relocates. It moves into the gate, which is now the only thing left holding the shape of the work.
And notice what van der Aalst and his co-authors never had to solve. A colleague sharpened this point for me and I have not been able to improve on his phrasing, so I will borrow it: in 2005, when the topology stopped constraining the work, something else caught it — a qualified human being. The paper is completely explicit that the knowledge worker in charge decides how the goal is reached. The human was the gate. That is why case handling could safely be so permissive.
Automate the knowledge worker and that seat is suddenly vacant.
That is the actual transition we are living through. Not loops to graphs. The paradigm was described correctly two decades ago; what arrived recently is an engine capable of running it, and the engine does not come with the judgement that made the original design safe. If you do not deliberately fill the gate seat, it gets filled by default, by the model marking its own homework.
The paper says, of the flexibility problem: it is difficult to offer flexibility without losing control. That sentence was true in 2005 and it is the whole game in 2026. The gate is how you get one without giving up the other.
The bill nobody is showing you
The factories are real and the numbers are loud. OpenAI’s Symphony shipped roughly a million lines with no human-written source code in five months, with the codebase deliberately restructured for agent legibility. Stripe’s Minions merge over a thousand agent-written pull requests a week. Ramp’s Inspect produces about thirty percent of merged PRs. StrongDM’s factory forbids humans from writing or reviewing code and treats a thousand dollars a day in tokens per engineer as the price of maturity.
Impressive. Also worth noticing: StrongDM, asked on Hacker News how the factory is going, offered cadence and optimism but no results data.
Addy Osmani gave the gap a name that I think will outlive most of this vocabulary: comprehension debt. The widening distance between how much code exists and how much of it any human still understands.
That is the real invoice. Not the token spend. The token spend is visible and finite. Comprehension debt is invisible and compounding, and it comes due at exactly the worst moment, during an incident, during an audit, during a migration, during the conversation where a regulator asks you to explain a decision your system made.
Notice that WorkOS’s Project Horizon lets agents decompose projects and build them, and still requires a human before every merge. That is not timidity. That is somebody who has read the invoice.
Where this meets sovereignty
Regular readers know where I am going, and it is not a detour.
If the gate is the multiplier on everything your system produces, then the gate is your most strategically important asset. Not the model. The model is already becoming interchangeable, and three years from now swapping it will be a configuration change. What will not be interchangeable is the set of deterministic checks that encode what your organisation considers correct, safe, and compliant.
So ask the uncomfortable question. Do you own your gates, or are you renting them?
If your verification lives inside a vendor’s closed harness, you have outsourced your definition of quality to a company whose roadmap is not your roadmap. You will not be able to audit it, you will not be able to port it, and when the pricing changes or the product sunsets, you do not get to take your judgement with you. You will own a codebase you cannot explain, gated by rules you cannot read.
Whoever owns their gates can keep building. Whoever rented them cannot explain their own system.
This is the same argument I have been making about private AI and digital sovereignty, arriving from a completely different direction. Control over data was the first battle. Control over models was the second. Control over verification is the third, and it is the one almost nobody is talking about yet.
Determinism is a feature, not a compromise
There is a related shift happening in how we feed context to agents, and it rhymes with everything above.
Google’s Open Knowledge Format takes company knowledge out of the vector database and puts it into plain Markdown files with YAML frontmatter, linked explicitly. As the OKF write-up puts it, this shifts strategy from probabilistic search over unstructured files to deterministic navigation across a living, human-and-agent-readable knowledge graph. Chunking destroys table structures, vector retrieval is inherently probabilistic, and keeping embeddings synchronised with fast-moving data is an operational nightmare.
Asking a probabilistic system to find your legal tax identifier or your definition of “revenue” is fundamentally a bad design choice.
And because it is git-native, you can version-control it, audit it through pull requests, and track exactly how your organisation’s knowledge changed over time. Format over platform. No cloud accounts, no bespoke SDKs, no lock-in.
Same pattern as the gate. Where the answer must be absolute, remove the guessing. Keep the probabilistic machinery for the parts where exploration is the point.
So, before you build the harness
Lindenberg’s Loop Engineering Canvas exists to make a team answer one question before any harness gets built: has this problem earned a loop, and can you name the deterministic check that gates it?
I would put it on the wall. Two questions, asked out loud, before anyone opens a terminal:
- Has this problem earned a loop? Plenty of things you are about to make agentic are a script, and a script you can read at three in the morning.
- Can you name the deterministic check that closes it? If you cannot say it in one sentence, you do not have a gate. You have a hope.
Closing thoughts
I am not sceptical about agents. At Tech Tribes we are building with them, in production, for organisations where being wrong has consequences. What I am sceptical about is the annual renaming ceremony, because it keeps our attention on topology while the actual craft sits somewhere much less exciting.
Van der Aalst and his co-authors got the paradigm right in 2005. What was missing was an engine capable of running it. That engine has arrived, and in the excitement we have skipped past the small print: the original design was safe because a knowledge worker sat in the middle of it, deciding. That seat is now open.
Topology is fashion. The gate is the job.
Build your gates deterministically, keep them in the open, in your own repository, under your own review. Then the model can change, the vocabulary can change, graph engineering can be replaced next spring by whatever comes after it, and you will still be able to explain your own system.
That, to me, is what sovereignty looks like when it stops being a slide and becomes an architecture.