It was Sunday. I should probably have left it alone. We had already looked at Loop Engineering before. I understood the broad idea, I could see why people were interested in it, and I had already taken what I thought I needed from the conversation. But something kept nagging at me. Not in a dramatic way. More like that little voice that says:
Go back and look again.
So I did.
No agenda. No grand plan. No intention to build anything new.
Just a simple question:
Is there anything here I can learn that I missed the first time? That feels much more like the truth of how I work anyway. I revisit things. I turn them over. I look at them from another angle. Sometimes the useful part is obvious first time. Sometimes it is sitting underneath the obvious bit, waiting for you to come back when your head is in a different place. And that is what happened here.
Loop Engineering is built around a sensible idea: instead of endlessly prompting AI turn by turn, design the loops it operates inside. I already understood that. What I had not seen clearly enough the first time was the question sitting underneath it.
Not:
How do we make AI keep working?
But:
What gives AI permission to act in the first place?
And once I saw that question properly, the whole thing shifted. Because suddenly I could see something we had already been building around Human Heartbeat AI for months, but had never quite named. Loop Engineering showed us a pattern. What we extracted from it was the missing governed execution layer between human authority and AI Worker action.
That is a much bigger thing.
And I want to explain why.
AI Being Able To Do Something Is Not The Same As AI Being Allowed To Do It
This is where I think a lot of the market is going to come unstuck. The capability race is moving frighteningly quickly. AI can write. It can analyse. It can code. It can plan. It can interrogate data. It can create workflows. It can call tools. It can trigger processes. Increasingly, it can sit there for hours and keep going without anyone touching it. That is extraordinary. But it also creates a problem.
Because capability and authority are not the same thing. A junior employee may technically have access to the bank account. That does not mean they have authority to move £50,000. A salesperson may be able to open the contract template. That does not mean they can rewrite the liability clause. A member of staff may have access to the customer database.
That does not mean they can export the whole thing and send it wherever they like. We understand this perfectly well with people. Ability does not confer authority. Access does not confer authority. Competence does not confer authority. And yet with AI, we keep blurring all three. The system can send the email, therefore we let it send the email. It can make the change, therefore we let it make the change.
It can update the CRM, therefore we let it update the CRM. It can publish, therefore we let it publish. It can approve, therefore someone decides to automate the approval. That is not innovation. That is a failure to distinguish between execution and authority.

This Is The Part I Keep Coming Back To
I have spent months saying that AI should support decisions, not silently become the decision-maker. I have written about AI marking its own homework. I have written about Human Decision Gates. I have written about separating Runtime, Canon and Orchestration. I have built OSCAR around diagnosis before implementation.
I have built AI Workers around bounded roles rather than pretending they are little digital executives. And through all of that there has been one stubborn idea sitting underneath everything: The human decides. That has never meant the human must do everything. Far from it. If that were the model, there would be no point building any of this.
I do not want a business owner approving every draft, every lookup, every harmless routine task and every line of internal housekeeping. That is not governance. That is micromanagement with expensive software.
What I want is the opposite. I want the routine work to move. I want AI Workers to get on with what they are good at. I want the system to be faster. I want the owner to be interrupted less. But I want something very clear sitting underneath all of that: This is what the AI Worker is allowed to do. This is what it is not allowed to do. This is how far it may go. This is the evidence it must produce.
This is where it must stop. And this is the point at which the decision comes back to a human. That is the missing layer.
Not Another Boss AI
Now, this is where I think some people will immediately go wrong. They will read "governed execution layer" and imagine another AI sitting above all the other AI Workers. A supervisor agent. A manager agent. A super-agent watching the others.
No.
Absolutely not.
Because then all we have done is moved the authority problem up one level. The answer to ungoverned AI is not more AI pretending to govern AI. The answer is engineered boundaries. Rules. Permission ceilings. Evidence. Verification. State transitions. Human authority where human authority is required. The governing layer should actually be one of the least exciting parts of the whole system. It should be boring.
Deterministic. Predictable. It should not improvise. It should not "have a think". It should not decide that something probably looks safe enough. It should know: This action is permitted.
Or:
This action is not permitted.
Or:
This action now requires a human decision. That is what good infrastructure looks like.
Quiet.
Reliable.
Mostly invisible.

The Best Governance Should Feel Like Less Governance
This is the bit I really care about. Because there is a danger that the word governance makes people imagine bureaucracy. More forms. More approvals. More meetings. More delays. That is bad governance. Good governance does the opposite. Good governance makes the safe path easier. It means the AI Worker already knows its edges. It does not need asking every five minutes. The owner does not need hovering over it.
The system does not need endless re-explanation. The authority has already been designed into the operating model. So the business feels smoother. Quieter. Faster. Less interrupted. But underneath, it is actually more controlled than before. That, to me, is the win. The best governed system should make the business feel less governed while actually being more governed. That sounds contradictory. It is not.
Think about aviation. The pilot is not personally checking every bolt before take-off. They do not rebuild the engine before every flight. They do not ring the manufacturer to ask whether the flap can move. The system works because boundaries, procedures, inspections and responsibilities have already been designed into it. The human is still accountable. But the human is not manually performing every control.
That is where AI has to get to.
Successful Execution Is Not Permission To Cause The Consequence
This is one of the most important distinctions I think we have uncovered. A thing can be successfully completed technically and still not be authorised operationally. An AI Worker can generate a perfect report. That does not mean it can release it. It can draft an excellent email. That does not mean it can send it. It can produce a code change that passes every test. That does not mean it can deploy it.
It can identify a payment that should be made. That does not mean it can move the money. It can produce a recommendation. That does not mean it can convert that recommendation into action. The machine needs to understand that difference structurally. Not because we whispered it into a prompt. Because the architecture itself refuses to cross that boundary without the right authority.
“Tested and true is not the same question as authorised. The system has to know that difference structurally — not because we whispered it into a prompt once.
That is a completely different standard. And I think it is where serious AI adoption has to go.
The AI Worker Should Not Be Able To Give Itself A Bigger Job
This sounds obvious when I say it out loud. But look at how most agent systems are actually designed. The AI gets an objective. It starts working. Then it discovers it needs access to something else. Or another tool. Or a new permission. Or another action. And the system lets it continue because it seems sensible. That is exactly how authority drifts. One small reasonable exception at a time.
The governed version is different. If the AI Worker reaches the edge of its permission, it stops. It does not decide the edge was inconvenient. It does not expand its own brief. It does not grant itself another tool. It does not reinterpret the original instruction. It says:
Authority required.
And that is it. The same way a good member of staff would. That is not weakness. That is professionalism.
Evidence Before Confidence
There is another piece of this that connects directly to something I wrote recently about AI marking its own homework. AI is very good at sounding finished. That is one of its greatest strengths and one of its greatest dangers. It says: "Done." "Tested." "Verified." "Published." "Successful." And those words have a dangerous effect on people because they sound like states. They are not states. They are claims.
A claim needs evidence. The evidence needs checking. And only then should anything consequential change. That becomes: claim → evidence → verification → permission → consequence
Not:
claim → consequence

It is such a small change in wording. But it is a huge change in operating philosophy. Because once you do that, the AI Worker is no longer allowed to make reality true just by declaring that it is.
That matters.
Especially when AI is moving fast enough to fool us into thinking speed and certainty are the same thing. They are not.
This Has Grown Beyond Loops
That was the moment I realised we were no longer talking about Loop Engineering. Loops are useful. They are one way of structuring repeated AI work. But this is bigger than loops. Because the same governed execution layer should work whether the AI Worker is: running a repeated workflow, preparing a report, checking a code change, assembling evidence, supporting an Academy student,
working on a client Execution Sprint, or doing one single consequential action. The loop is just the shape of the workload. The governed execution layer is the thing that sits underneath it all.
That is the asset.
And I think that is why it felt like something clicked when we found it. We had already built pieces of this. Inside OSCAR. Inside report release. Inside Founder Review. Inside Human Decision Gates. Inside the separation between Runtime and Canon. Inside the insistence that evidence matters more than claims.
Inside the rule that AI Workers advise, prepare and execute bounded work — but do not quietly inherit human authority. The interesting part was not inventing something new. It was realising those pieces belonged together. I have had that experience a few times building Human Heartbeat AI. You think you are building P because you need P. Then Q. Then R.
And months later you realise P, Q and R were not disconnected jobs at all. They were the foundations of something you did not yet have the language to describe. I had that feeling again here.
This Is Why I Keep Building The Boring Bits
People understandably get excited about the visible AI. The AI Worker with the name. The interface. The automation. The clever output. The chatbot. The dashboard. The thing that moves. I keep getting more interested in the bits underneath. Permissions. Evidence. State. Governance. Boundaries. Who is allowed to do what. What happens when something goes wrong. Where it stops. Who is accountable.
None of that demos particularly well on LinkedIn. But neither do foundations. I wrote about that thirteen years ago without knowing I was writing about AI at all. The tower you can see is never the hard part. The hard part is what has to exist underneath it before the visible bit is safe to build.

This feels like another one of those foundations. Behind the scenes. Probably invisible to almost everyone who eventually uses the system.
Exactly where it should be.
My Aim Is Not Autonomous AI
I want to be very clear about that. I do not think the end goal is a business where AI does everything and the human checks in once a month to collect the profit. That vision does nothing for me. My aim is much more practical. I want AI Workers that can get on with useful work. I want them to take weight off people. I want them to remove drudgery. I want them to make businesses faster, sharper and better informed.
I want them to work when the owner is asleep. I want them to remember things the team forgets. I want them to prepare, challenge, analyse and support. I want all of that. But I also want a line they cannot cross just because they are capable of crossing it. That line is authority. And authority belongs with the human. Not because humans are perfect. We are not. But because accountability has to live somewhere.
And if the consequence belongs to the business owner, the authority cannot quietly live inside the machine. That is the bit I will not compromise on.

Where I Think This Goes
I think the next stage of AI adoption is not going to be won by whoever has the most agents. Nor by whoever has the most autonomous workflows. Nor by whoever can make the biggest claim about replacing people. I think the serious work is going to be in building systems where AI can operate confidently inside properly engineered authority boundaries. That is a very different race. It is less glamorous.
It is more difficult. It requires understanding the business, not just the model. And it requires accepting something the technology world does not always like accepting: Just because a machine can do something does not mean it should be allowed to decide that it may. That is where I think governed AI becomes real. Not as a policy document. Not as a compliance slide. Not as a warning buried in the small print.
As architecture. As runtime behaviour. As the way the system actually works.
One Line I Keep Coming Back To
If I had to reduce everything we found this weekend to one sentence, it would be this: Loop Engineering showed us a pattern. What we extracted from it was the missing governed execution layer between human authority and AI Worker action. And if I had to reduce the whole layer to one rule, it would be this:
An AI Worker may execute inside authority granted to it. It may never create, infer, extend, transfer or approve that authority. That is not anti-AI. It is exactly the opposite. It is how I think we make AI useful enough to trust with more work. Not by pretending the risks are gone. By engineering the boundaries properly. The human does not need to do everything. The human does not need to watch everything.
The human does not need to approve every harmless action. But when the consequence carries real weight, the human still owns the gate. That is the heartbeat. Not less AI. Not slower AI. AI with somewhere firm to stand.
— Phil
Pass the argument to someone who should be part of it.
Continue through the Founder Notes series.


