The governance gap is at the orchestration layer. That is where we need to start.

Your AI agent just made a decision. It routed a request, invoked a tool, produced an output, and moved on. Somewhere in that chain, it exercised authority. The question worth asking, and the one most organisations cannot currently answer,

is: what was it actually authorised to do?

This is not a hypothetical. Enterprises across every regulated sector are deploying AI agents at pace, and the design conversations happening inside those organisations are almost entirely about capability. What can the system do? How does it connect? What does the flow look like? Those are reasonable questions. They are just not the only questions that matter.

The orchestration layer is where AI systems exercise judgment. An agent decides whether to escalate or proceed autonomously. It decides which tool to call, which data to pass, whether a confidence threshold has been met. Each of those moments is, in effect, a governance moment.

The system is acting on behalf of someone, within some boundary, under some set of rules. The problem is that those boundaries and rules are rarely written down anywhere that connects to the actual system design.

Instead, they live in a risk register written by someone who has never seen the flow diagram. Or in a policy document reviewed annually by a committee that does not know what an orchestration layer is. Or they do not exist at all, because the team moved fast and assumed governance would follow.

It will not follow. It does not follow automatically. It has to be designed in.

The reason existing tools cannot solve this is that they treat design and governance as separate activities, which means they produce separate artefacts. The architecture diagram lives in one place. The risk assessment lives in another. The audit trail, if it exists, lives somewhere else entirely. When a regulator or an internal audit team asks how a decision was made, someone has to stitch those artefacts together by hand, under time pressure, hoping the diagram still matches the deployed system.

That is the documentation debt the industry is accumulating right now, one AI deployment at a time.

There is a different way to approach this. If you design an AI system using a language that is expressive enough to capture not just the flow but the intent behind it, the authority each component holds, the conditions under which a human must be in the loop, and the sensitivity of the data moving through it, then the governance record is not a separate document you produce after the fact. It is the design itself. The diagram and the governed artefact are the same thing, because the design language forces you to make governance decisions at the point where they actually matter: when you are designing the system.

This is what we mean when we talk about governance as a byproduct of design. Not governance bolted on afterwards. Not a compliance step that happens when someone from legal gets nervous. Governance that emerges from the act of designing the system properly, using a language that demands precision about what each component is, what it can do, and where its authority ends.

The orchestration layer is the right place to start, because that is where authority is exercised. That is where the gap between what a system was supposed to do and what it actually does becomes consequential. And that is where design and governance have to meet, if they are going to meet at all.

The posts that follow will work through what that design language looks like, why it has to be purpose-built for AI systems rather than adapted from existing architecture tools, and what it means in practice to treat a diagram as a governed record rather than an illustration.

We are starting at the orchestration layer because that is where the problem is.