A term I had not seen before started appearing on my timeline a few weeks ago. Graph engineering. Rakesh Gohel set out one of the clearer versions of it: agents that run for any length of time eventually have to decide what happens next, and if that decision lives inside the model's own reasoning, nobody can review it. So move it out. Name the stages in advance. Declare which transitions between them are legal. Lock the plan so the agent cannot quietly revise it mid-run. Keep planning, execution and recovery genuinely separate, so the layer producing the work is never the layer judging it. Write state to disk at every step instead of leaving it in a conversation that will eventually be compacted away.
It is a good argument, and Gohel is careful to present it as a hypothesis worth testing rather than a settled result, which is the right posture. It is also, in substance, decades old. State machines, checkpointing, two-phase commit, tamper-evident logs: financial services has run on these for a very long time. What is new is applying them to systems whose central component is a language model.
For readers who do not spend their days in this
If your interest here is regulatory rather than architectural, the distinction is worth two paragraphs, because it decides whether an AI system can be evidenced at all.
The default way to build an AI agent is what people now call a loop. You give it a task and it runs: tries something, reads the result, decides what to try next, and keeps going until it stops. Every one of those decisions happens inside the model's own reasoning, in a single long context. You can see what it did afterwards. You cannot see the decision being made, and nothing structural stops it repeating a bad approach five times.
The alternative is to draw the steps out in advance. Named stages, declared rules for moving between them, and a record written outside the model of what happened at each one. That is the graph. It is the same instinct as a documented process with defined handoffs and checkpoints, applied to software that improvises.
The reason this matters for regulated work: one of these produces something a supervisor can reconstruct after the fact, and one does not.
I went to check whether I had already built it. I had two systems to check against: ComplyAI, the governance layer I build for AI-assisted credit decisions, and a smaller systematic trading system I run on my own account.
Both passed on structure. Named stages, declared transitions, state written to disk, human sign-off as a real step rather than a box ticked at the end. Neither was built from the framework, because the framework did not exist when they were built. Both arrived at the same shape because the domain does not offer an alternative.
Then I asked a harder question, and the two systems separated immediately.
Every layer these frameworks define is read by the model
There are three related bodies of thinking here, and it is worth being fair to all of them before saying what they miss.
The first is the Interpretable Context Methodology, published to arXiv in March by Jake Van Clief and David McDermott of Eduba and the University of Edinburgh, which replaces framework-level orchestration with filesystem structure: numbered folders as stages, plain markdown carrying the instructions, one agent playing a different role at each step. I have been running a version of it since April, so this was not an unfamiliar idea being evaluated from the outside. The second is graph engineering as described above, which adds declared state transitions, an immutable plan, and a fixed recovery protocol with an attempt limit. The third is the loop, which is what most agent tooling gives you out of the box.
Each has genuine merit, and they compose well. The ICM paper is explicit that its own motivation is partly regulatory, citing the EU AI Act's requirements for human oversight of high-risk systems. Gohel's framework goes further than most in the right direction: it explicitly separates the layer that produces work from the layer that judges it, on the reasoning that collapsing the two erodes the point of checking at all. That principle is exactly right, and it is the one I later found broken in my own code.
But hold the three side by side and one property is common to all of them.
Every layer they define is read by the model it is meant to constrain.
The numbered folders are markdown the agent reads. The declared transitions are instructions the agent reads. The recovery protocol, the attempt limit, the immutable plan: all of it arrives through the same channel as everything else the model is told, and all of it depends on the model choosing to comply. The same is true of the pattern most often proposed for catching bad outputs mid-run, a checker node sitting between parallel work and the point where it converges. It is a node, in a structure the model reads and executes.
The structure is real. The enforcement is not.
That distinction does not matter much when the output is a research summary. It matters enormously when the last step in the sequence moves money, files a report, or serves a decision to a customer.
The test that separated my two systems
The question I put to both systems was blunt: what happens if the model simply does not follow the control?
In the trading system, every control is written in markdown and read by the agent at the start of each session. Verify the risk file's checksum before use. Never place an order without a signed, single-use approval. Halt immediately if the circuit breaker flag is set. The agent has honoured all of it across months of sessions, and the audit log shows it.
But it honours them. Nothing stops it.
And when I looked properly, I found something worse than a theoretical gap. In one automated mode, the agent updates its own risk parameters file as part of the run, then recomputes the checksum that is supposed to protect that file. The verification step still runs. It still passes. It is checking a file against a hash the same actor generated moments earlier.
A control that the controlled party can re-sign is not protecting anything. This is precisely the builder-and-judge collapse Gohel warns about, and I had built it into a system I considered careful, without noticing.
The history bears this out, and more usefully than a misbehaviour would have. One commit moved an actual risk constant rather than the ticker allowlist: a live order had been rejected by the broker for falling under its minimum size, the agent correctly identified which constant was the binding one, raised it by the smallest amount that cleared the floor, left the underlying risk-per-trade percentage untouched, and recorded the change as human-approved.
That is careful, well-reasoned work. It is also not evidence. Human-approved is a string the same actor wrote in the same commit that made the change. Nothing independently attests it. The change, the justification, and the approval all come from one source, and the checksum then certifies the result. Good behaviour with no proof of good behaviour is the distinction this piece is about, and it is more persuasive than a misbehaving system would have been, because there is nothing here to excuse.
I had built a genuinely careful system and left a door in it, and I found the door by auditing my own work against someone else's post.
ComplyAI answered the same question differently, and not because the code is more careful. It is because the model is never the thing running the pipeline.
In ComplyAI, Python orchestrates. It calls the model to trace figures in a credit decision back to the source documents, and to write a plain-language explanation. The model returns a structured result against a fixed schema, and that result is verified against the source text. It never decides what happens next, never chooses which layer runs, never touches the audit chain. There is nothing for it to route around, because it is not driving.
Underneath that, integrity verification is designed to run on a schedule outside the application entirely (cron, systemd, whatever the deployment already trusts), with the exit code as the alerting contract. A failed integrity check is an incident, not a log line. The anchor it verifies against is deliberately specified to be stored where the process that writes the log cannot reach it, because an anchor kept next to the log protects nothing. The mechanism and the command-line tooling exist; the scheduling and off-host anchoring are deployment work that happens with a client's own infrastructure.
The enforcement floor
This is the tier none of the three frameworks describes, and it is the one that decides whether the rest is real.
Call it the enforcement floor: the layer beneath every layer the model can read. It is not instructions. It is scheduled jobs, wrapper processes, exit codes, file permissions, and storage the application cannot write to. Its defining property is that the model cannot perceive it, cannot reason about it, and cannot be argued out of it, because it was never addressed to the model in the first place.
Everything above the floor is architecture. The floor is what makes the architecture load-bearing.
I wrote in an earlier piece about the FCA's recent enforcement pattern (Metro Bank, Starling, Monzo) and the thread running through all of it: the controls were not absent, they existed and ran, and the gap was between what a control actually did and what the institution assumed it did. Nobody was checking the checker.
The AI version of that failure is subtler and arrives faster. The control is not misconfigured. It is present, well written, and read aloud to the system it governs at the start of every run. It works, until the run where it does not, and there is no structural reason it should have worked in the first place.
Chris Knight, the FCA's Director of Insurance, set the standard in a line published this July that has nothing to do with AI and applies to all of it: firms need "controls that actually work in practice, not just on paper."
Most AI governance I am shown is on paper. Thoughtfully written, genuinely well intentioned, and read by the very system it is meant to restrain.
What this does not fix
Three honest limits, because a governance argument that claims too much is the thing it is arguing against.
An enforcement floor does not authenticate anyone. A gate can record with cryptographic certainty that a named individual approved a decision and that the record was never altered afterwards, and still be relying on the calling application to have established that the person was who they said they were. That boundary has to be closed separately, and firms should ask where it sits.
Nor does it force good composition. Layers that can each be deployed independently can also be deployed incompletely, and a system assembled with a gate but no tamper-evident record will fail closed if it is well built, but nothing at the architectural level obliges anyone to assemble it correctly.
And the central claim here should be treated as a hypothesis rather than a settled result, on exactly the terms Gohel applies to his own. The proposition is that moving enforcement below the model changes outcomes. The way to test that is to measure it: find out whether the floor ever actually catches something, or whether instruction-following was sufficient all along. Cheap insurance that never pays out is still worth holding. But you should know which one you have, rather than assume.
The question worth asking
You do not need a new framework to apply any of this. You need one question, put to every AI-assisted control in your firm.
What happens if the model simply does not follow it?
If the honest answer is it would follow it, because it always has, because the instruction is clear, because the system prompt is emphatic, then what you have is a policy.
If the answer is it cannot, because the control does not run inside anything the model orchestrates, and it fires whether the model cooperates or not, then you have a control.
Only one of those is evidence.
Sources: Interpretable Context Methodology, Van Clief and McDermott, arXiv:2603.16021. Rakesh Gohel, "The Loop Era Is Over: The Shift From Loop Engineering to Graph Engineering," 1 August 2026, x.com/rakeshgohel01. Chris Knight, "Managing conflicts of interest in insurance," FCA blog, July 2026.