Six planes: how an AI company's infrastructure is layered

Picture a company handing more and more of its work to AI. At first it is simple. Marketing wires up a chatbot, sales builds a small quoting tool, and the delivery team writes a few flows that tidy up data. Each one works and solves the problem in front of it. Six months later the trouble starts. The three tools each keep their own copy of the client list, and the copies disagree. Each tool has its own permission settings, so nobody can say which AI is allowed to touch which data. Then a flow sends an email to the wrong person, and the team has to dig through three systems to piece together what happened.

No team did anything wrong. The infrastructure simply had no shape. Everyone built what they needed without a shared map, one that would say which layer a piece belongs to, whom it reports to, and where it must never reach. This article describes the map we use to give infrastructure a shape: six planes.

One thing to be clear about first. The six planes are a set of rules for classifying pieces and constraining them. They are not a finished piece of software. Some parts already run as code, such as the checks on registration and permissions. Others are still only specifications, or are still being observed. We try to keep the two apart throughout.

Why layer by plane rather than by system

The intuitive way to divide things up is by system: a quoting system, a support system, a project system. That suits the people who use them, but it is dangerous for infrastructure. Every system needs permissions, memory and storage, and every system needs to be audited. If you divide by system, each of those capabilities gets built once inside every system. The copies are never quite identical, so the company ends up with several versions of the truth.

Planes ask a different question. The question is not which product a piece belongs to, but what kind of question it answers. Who has the final say is one kind of question. What the rules are, and who may do what, is another. Actually doing the work is a third. When the pieces that answer the same kind of question share a layer, each capability is built once and everyone uses it.

We settled on six planes, and each one can be described in a single sentence:

• Human decision: who decides. Which people hold seats, who can sign off, and who gives final confirmation.
• Control: rules, registry and permissions. Which rules the company has, what has been registered, and who may do what.
• Execution: doing the work. Agent capabilities, flows, and connections to outside systems.
• Knowledge and artefacts: facts, memory and deliverables. What the company knows, what it has done, and what its outputs look like.
• Quality and trust: evaluation, audit and recovery. How we know the work is right, and how we investigate and roll back when it is not.
• Platform base: machines, storage, models and cost. The bottom layer that makes everything run.

The planes have a direction built in. Upper planes may depend on lower ones, but lower planes know nothing about the planes above them. An agent on the execution plane can read facts on the knowledge plane and run on machines from the platform base. The storage base, however, should never know what quote a particular agent is working on. Reverse that direction and the lower layer gets tied to one particular use. Replacing the upper layer then forces changes to the lower one too, and the structure loses the property that makes layering worth having: that a layer can be swapped out.

One piece, one home

The strictest plane rule is that each piece of infrastructure lives on exactly one plane. That can feel rigid. Memory and feedback, for example, seems to belong to knowledge and to quality alike. Why not let it sit on both?

The reason is ownership. If a piece belongs to two planes, then when it breaks each side expects the other to fix it, and when it needs a new version each side has its own release rhythm. One home means one clear scope of responsibility, one versioning rhythm, and one place to go when something fails. Other planes using the piece is normal. Using a piece is not the same as owning it.

So when we classify a piece, we ask what its core responsibility is. Memory and feedback exists mainly to keep handoff cards and reflection records, so that the next piece of work can pick up where the last one stopped. That is about what the company knows and has done, so it lives on the knowledge and artefacts plane. The quality plane reads those records but does not own them.

Everything registers with the governance base

Planes are not enough on their own. We also need one place that records what actually exists. That place is the governance base. It sits at the centre of the control plane and has two jobs: registry and gateway. As a registry it records each piece of infrastructure, its version and its plane. As a gateway it is the point every person and every AI must pass through before touching data.

Registering means something concrete. Before a piece can be used anywhere else in the company, it must have a record in the governance base saying what it is, which plane it belongs to, which version is current and who is responsible for it. Anything unregistered does not exist as far as the company is concerned, and nothing else should depend on it. The payoff is that we can always answer the question "what infrastructure do we have right now?" without relying on memory or searching old chat threads.

The governance base is also the single source of permissions. Who may do what is written down in one place only, its binding table. When a piece of infrastructure needs to act, it asks the governance base for permission rather than deciding for itself. The reasoning is simple. As soon as permissions have two sources, the two will drift apart sooner or later, and the places where they disagree are exactly where incidents happen.

One kind of thing is deliberately drawn outside the ring: cases, meaning the actual work stores, such as a client project, an internal project or a product's workspace. Cases are not infrastructure. A case uses infrastructure: it pins an interface version, cites fact identifiers from knowledge, and runs a particular version of an agent capability. The reverse is never allowed. No piece of infrastructure may depend on any case.

Five directions that are never allowed

We have found that rules about which connections are forbidden protect the structure better than rules about which ones are allowed. The red box lists five forbidden directions, and each one guards against a specific kind of harm:

• Infrastructure must not read client data. Infrastructure is shared, so once it has seen one client's data, that data can leak into another case. Client data lives only in that client's case.
• Nothing may grant itself permission. If an agent could edit its own permissions, every permission check would be meaningless. Permissions come only from the governance base.
• Nobody writes rules around the base. Once rules are scattered across many places, nobody can say which one is in force.
• Infrastructure must not store the body of a fact. It cites the fact's identifier. The text itself lives in one place, on the knowledge plane, or the same fact ends up in several versions.
• No piece of infrastructure may depend on a case. The interface, for example, must not depend on a particular product. If it did, a change to that product would break the shared interface.

A structure is not held together by everyone remembering how things connect. It is held together by the lines nobody is ever allowed to draw.

These five rules are not all enforced in the same way. Two are already enforced in code: permissions can only come from the governance base, and any subcommand that is not on the allowlist is refused. The rest rely partly on checks made at registration time and partly on written rules that review has to uphold. We record that difference openly rather than pretending all five are automated.

Nine domains share one set of planes

Once infrastructure has its planes, the business needs its own divisions too. The company's work falls into domains: governance, strategy, core engine, research and development, methodology, delivery, brand, growth and product. One further domain builds and maintains the planes themselves. It is left out of the table below because it builds the house rather than living in it.

The key point of the table is that no domain owns a separate set of infrastructure. Each domain only draws on capabilities from different planes. Governance relies most on human decision, control and quality, because its job is to make decisions, set rules and check that they are followed. Delivery relies mainly on execution and quality, because its job is to produce work and to get it right. Brand relies mainly on execution and knowledge, because it produces content, and that content has to rest on correct brand facts.

What happens if every domain builds its own? The brand domain keeps one copy of the brand facts and the growth domain keeps another, and the two soon diverge. Delivery has its own permission settings, product has another, and those diverge too. Nine domains end up with nine sets of permissions, nine memories and nine ways of auditing. On the table they look like nine tidy columns. In practice they are nine systems, each maintained separately and each failing in its own way.

Three fates for a candidate: keep, merge, move out

In practice the plane rules are used most when deciding whether something should become infrastructure at all. As work moves forward, someone always proposes a new piece: client management, finance and cost, evaluation. Each proposal starts out in an observation area as a candidate, and then it goes through a filter.

• Keep and register: several domains share it, and it fits clearly on one plane. Memory and feedback is an example. Almost every domain needs to pick up where the last piece of work stopped, and the responsibility clearly belongs to knowledge and artefacts.
• Merge into an existing piece: its responsibilities overlap one that already exists, and keeping them separate would create two versions of the truth. Evaluation and quality was first proposed as a piece of its own. But what it evaluates is mostly agent capability, and the two have to evolve in step, so it was merged into agent capability and is managed with it.
• Move out as a domain need: it serves a single domain, or it is really business content rather than a foundation. Clients and partners, legal compliance and assets, and finance and cost were all moved out in the end. Each became a need of the domains concerned.

Moving a candidate out does not mean the work is unimportant. Client relationships, legal matters and finance obviously matter. But they are what the business does, not the foundation that lets the business run. Turning client data into a piece of infrastructure would break the rule that infrastructure must not read client data. Turning finance into infrastructure would teach the foundation business logic, and the lower layer would then know about the upper one. Handing them back to the domains, which then draw storage, permissions and audit from the planes, keeps the structure clean.

The filter is also honest about what is still undecided. Agent capability, for example, is itself still under observation, and its scope will be adjusted as real use shows what it needs. We would rather leave a piece in observation for a while longer than register it as official infrastructure too early and pay much more to take it apart later.

Walking through it: a weekly report from request to delivery

Here is a made-up but typical scenario that runs through all six planes. A company's delivery team produces a weekly campaign-performance report for a retail brand client. Until now someone has put the report together by hand. From now on an agent drafts it, and a person reviews it and sends it.

The first step happens on the human decision plane. Who confirms this report? Who has the authority to decide that it can go to the client? That information lives in people and seats. At no point is the agent treated as the person who confirms. It can only draft.

Step two is the control plane. When the schedule triggers, the agent first identifies itself to the governance base and then asks what it is allowed to do. The binding table says it may read campaign data inside this client's case and write the report draft, but it may not send email. This is also where the report pins a version of the interface, so this week's layout matches last week's.

Step three is the execution plane. The agent starts work using a specific version of agent capability. It pulls last week's campaign data from the outside data system through a connector registered under integrations. The connector can read only the scope it was registered for. However curious the agent is, it will not read another client's data.

Step four is the knowledge and artefacts plane. The agent needs the brand's official name and approved wording. It does not copy that text and keep it. It reads the facts from the knowledge plane by their identifiers. The report follows a fixed delivery template. The handoff card from last week tells the agent which metric the client cared about last time.

Step five is the quality and trust plane. The finished draft is evaluated first: do the numbers match the source, and does the format follow the template? Every action is written to an append-only event log. If the draft fails evaluation, it is sent back and never reaches a person.

Step six is the platform base. The whole run happens on the runtime's schedules and machines. Data is stored in the storage base according to its sensitivity level, and the cost of models and compute is recorded on this layer too. Finally, the person who confirms reviews the draft and decides to send it. A person signs off on the outbound email; the agent never makes that decision itself.

Seen from the domains, this work belongs to delivery, which mainly uses the execution and quality planes. The brand wording comes from knowledge that the brand domain maintains. No domain built a separate set of permissions, memory or storage for this report. They all drew on the same planes.

What this costs, and what is not done yet

Every layering has a cost. The most obvious one is extra steps. A small tool used to read the database and send email directly. Now it has to register, request permission and cite fact identifiers. For a one-off task that really is slower. We accept the cost because of what it saves: tracing every future mistake, and rewriting whenever a layer is replaced.

Finally, an honest note on where things stand. Registration and permission checks already run as code. Some of the forbidden directions are enforced in code, and the rest depend on rules and review. Agent capability is still under observation. Full state tracking for outbound actions exists only as a specification so far. The six planes give us a clear map, but not every road on that map has been built yet.

In short

• Infrastructure is layered into six planes according to the kind of question each piece answers: human decision, control, execution, knowledge and artefacts, quality and trust, and the platform base. Upper planes depend on lower ones, and lower planes know nothing about the planes above.
• Each piece has exactly one home and registers with the governance base. Permissions come from a single source, and five forbidden directions protect the structure.
• The nine business domains do not build their own foundations. They draw on the same set of planes.
• A candidate is kept, merged or moved out. Anything that serves a single domain, or is really business content, goes back to the domains as a need.
• The rules are only partly in place. Some are enforced in code and some are still specifications, and we record which is which.