AI coding agents are about to act - they will open pull requests, bump dependencies, and ship deploys. They need a layer beneath them that governs what they act on, decides what they are allowed to do, and records why they did it.
Witold Reichhart · governedintelligence.eu · first published May 2026
Arrow keys to navigate · M for menu · T for theme · N for notes · scroll for depth
Capability is whether the agent can produce the change. Admissibility is whether the basis it stood on - the patterns, the contracts, the assumptions it relied on - can be defended and relied upon. The first is the model's job, and it is essentially done. The second is not the model's job at all.
The agents are about to act - not already acting - and that is the opening. Stand the admissibility layer up before they scale, and every consequential change is admissible from the first commit. Add it afterwards, and you inherit a backlog of changes nobody can defend.
Two halves to the case. The architectural half is a structural claim: one specific function goes un-owned the moment the human leaves the act, and each existing layer fails to adopt it for a reason that does not go away. The strategic half is the cost of leaving it un-owned - an AI portfolio that stalls at deployment, and a regulatory exposure that is turning from good practice into obligation.
Every consequential act rests on a basis - the facts, rules, interpretations, and authorities the actor relied on. In the tool world a person at the point of action held that basis: the senior engineer knew the auth pattern had changed, and which library version still carried the CVE. Delegated AI removes the person. The basis still has to be held. Walk the five layers the institution already runs and ask which one holds it.
Each layer governs a different object, at a different moment. Stack all five and the basis at the moment of action is still held by no one. A function with material consequence and no owner is not a process gap to close with effort - it is a missing architectural layer.
There is no third outcome in which delegated AI runs consequential actions and the basis has no home. The choice is the layer, or a human in every loop.
Three reasons the layer is worth building deliberately, and now.
Models perform. Pilots pass evaluation. Projects stall - and they stall at the deployment gate, not the build gate. The deployment gate is the admissibility gate. Without the layer, the portfolio is a row of pilots that never convert into operating systems.
Every competitor buys the same models - capability is a rented advantage that resets each release. A governed claim substrate is built from the institution's own knowledge and earns a longer track record with every action. It compounds, and it does not transfer. Durable advantage accrues in the layer, not the model.
Action-time evidence is moving from good practice to obligation - EU AI Act Article 12, DORA Articles 11-12, BCBS 239, SR 26-2, PRA SS1/23, in force or in transposition now. The institution will build this capability. The open question is whether it builds one architecture on purpose or reconstructs it in fragments under audit pressure.
These are not a vendor's checklist or this deck's invention. Write down what it takes to defend a delegated change after the fact, and these eight fall out. A competent reviewer, a security lead, or an architect names each one on their own. The three marked action-time are the requirements that decide admissibility at the instant the change is made.
Every fact the change relied on traces to a source. Which decision said this is the canonical pattern, authored by whom, and when.
The basis carries a computed confidence, not a binary "it exists." How much weight a claim bears is derived from evidence and track record.
The basis is checked at the moment of the change - is this claim fit to rely on now, for a change of this consequence. Not at build time; at the act.
Each claim has a named owner with the standing to author it. The canonical pattern is owned by the architecture board, not by whoever last edited the wiki.
The change carries a tamper-evident record of the basis it relied on - the claims, their standing, their authority - bound to the commit.
The basis as it stood at the moment of the change can be reconstructed afterward, when an incident surfaces weeks later.
Claims expire. A pattern is superseded, a library deprecated, an interface sunset - the basis must know a claim has aged out, not treat last quarter's truth as current.
The bar scales with consequence. A production deploy to a critical service is held to higher standing than a feature-branch merge. The gate is proportional.
The room cannot dismiss this list without dismissing one of its own seats. Each requirement is something a competent risk, security, or architecture function already asks of a consequential change. The next slide tests what you run against the eight; the slides after specify what clears all of them at once.
Each column is something an organisation already runs - on the left, the things people count on to govern knowledge; on the right, the tooling that keeps change safe. Each row is one of the eight requirements just established. Read down a column or across a row - the conclusion holds either way. The three shaded rows are the action-time requirements - admissibility, the signed manifest, and replay - and they are where the gap is.
| A1Data governance | A2Knowledge base | A3ADRs | A4Service catalog | A5AI governance | A6Code review | A7CI/CD | A8Static analysis | A9Dependency scan | A10Agent framework | A11Policy-as-code | A12Build provenance | A13Change advisory | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| R1 · Provenance | ◐ | ◐ | ◐ | ◐ | ✗ | ✗ | ✗ | ✗ | ◐ | ✗ | ✗ | ◐ | ✗ |
| R2 · Confidence / standing | ◐ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ◐ | ◐ | ✗ | ✗ | ✗ | ✗ |
| R3 · Action-time admissibility | ✗ | ✗ | ✗ | ✗ | ✗ | ◐ | ◐ | ◐ | ◐ | ✗ | ◐ | ◐ | ◐ |
| R4 · Named authority | ◐ | ◐ | ◐ | ◐ | ◐ | ◐ | ✗ | ✗ | ✗ | ✗ | ◐ | ✗ | ◐ |
| R5 · Signed manifest | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ◐ | ✗ | ◐ | ◐ | ◐ | ◐ | ◐ |
| R6 · Replay | ◐ | ◐ | ◐ | ✗ | ✗ | ✗ | ◐ | ◐ | ◐ | ◐ | ◐ | ◐ | ◐ |
| R7 · Currency / decay | ◐ | ✗ | ✗ | ◐ | ✗ | ✗ | ✗ | ◐ | ✓ | ✗ | ✗ | ✗ | ✗ |
| R8 · Tiered by blast radius | ✗ | ✗ | ✗ | ◐ | ◐ | ◐ | ◐ | ✗ | ✗ | ◐ | ◐ | ✗ | ◐ |
One full mark across the whole table. Dependency scanning tracking CVEs and outdated versions - the one thing it is built to do. A category-defining strength of a single column, and not coverage of the gap.
The action-time trio has no full coverage anywhere. The tools that gate at all - CI, policy-as-code, change advisory - gate the test result, the declared rule, or the change ticket. The knowledge stores - data governance, the wiki, the catalogs - hold content but gate nothing. None reaches the basis the change reasoned from.
Read it left to right. The strip below fixes where the layer sits - between the players who act and the systems that record. The machine under it is what the layer does: ungoverned knowledge as feedstock, four jobs that turn it into governed claims, and an action-time gate that hands the actor a basis it can stand behind. Every outcome writes back, so the layer compounds the more it runs.
For the architect. In standard policy-architecture terms the action gateway is the PEP, the layer's manifest service is the PDP, the claim graph is the PIP, and the standing-function-version registry is the PAP. The layer is a control plane that fits the pattern - not a paradigm to adopt wholesale.
The layer cannot lift its own gate. No retrieval routes around it. Evidence is produced at the act, not reconstructed after it. That is the whole of what makes a delegated action defensible - and the reason the gate has to be a layer, not a feature.
Agentic coding is moving IT from AI-as-tool to AI-as-operator. As agents take on pull requests, dependency bumps, and deploys with no human at the act, the basis they rely on - what is canonical, what is deprecated, what is fragile - is the same un-owned function the case for the layer describes. IT is the strongest first instance: the feedstock is already machine-readable, the outcome signal is fast and objective, and the estate is small enough to start without touching regulation or company-wide knowledge.
Repositories, CI logs, dependency manifests, and the service catalog sit below the layer. Aim the substrate at what the code says and it is retrieval over a repo - which the organisation already has. The layer governs the interpreted layer above the repo: what the institution is currently prepared to let an agent rely on.
The repository shows the codebase contains the old auth pattern and the new one. Which one is canonical is a claim - authored, dated, and decaying - and it is not in the code.
Only the second type is cheaply re-derivable from source. The other four decay, contradict each other, and carry authority - the test for whether the substrate earns its place. Architectural canon is the sharpest: the IT equivalent of a policy interpretation.
The consequential delegated action is an agent proposing a change. The gate fires at pull-request open and at deploy. The signed manifest records the claims the change relied on, at what standing, under whose authority. The consequence tier is blast radius.
This is the reason to start here rather than anywhere else.
Every change has a fast, objective outcome - a green build, an incident, a rollback, an error-rate spike. That outcome writes back as an operational-validation event. Claims relied on by changes that shipped clean accrue standing on the operational-validation dimension; claims relied on by changes that caused incidents lose currency. Within weeks the standing scores are a measured track record of which institutional knowledge is trustworthy.
The compliance domain waits for a supervisory examination to learn whether a claim was sound. IT learns from the next deploy. The slowest part of the architecture to prove anywhere else is the fastest part to prove here.
Shrink the claim count, the domain, and the action scope as far as is useful. Keep the gate and the encode-back loop. Drop either and it stops being the Knowledge Layer and becomes retrieval with extra steps.
Anticipated objection - "this is a better service catalog, or RAG, or policy-as-code." Catalogs and RAG return what exists, not what is admissible to rely on now. Policy-as-code gates the artifact, not the basis the agent reasoned from. The substrate's distinct contribution is standing - computed, decaying, outcome-validated - and the action-time manifest.
Capability is settled - the agents write code. These are the changes that show up when the basis they act on carries standing: in how much output you trust, in whether architecture decisions hold, in how institutional knowledge survives, and in what the organisation owns at the end.
Today the choice is binary - trust all agent output, or review all of it. Blanket trust ships confident garbage; blanket review reinstates the bottleneck delegation was meant to remove. Standing is the third path: a high-standing basis flows, a weak or decayed one routes to a human.
The senior reviewer is today's admissibility gate - the one who knows the threshold moved or the module is fragile. That person does not scale to the volume agents produce. The gate becomes machine-speed and consistent.
A board decision today lands in an ADR and a wiki page, then decays quietly while agents and engineers keep shipping the old pattern - it is still in the codebase, still in the training data. As a governed claim, that decision becomes a runtime fact: the gate refuses changes that relied on superseded canon.
Fragility, real blast radius, undocumented coupling - today this lives in a few senior heads and in postmortems nobody re-reads. As risk and operational-reality claims, it becomes part of the basis every agent and every new engineer acts on.
When a change causes an incident weeks later, you replay its manifest - which claim, at what standing, under what authority, on what date. You see at once whether the agent acted on a bad basis or a sound one overtaken by events.
Every competitor buys the same coding models - capability is rented, and it resets each release. A governed claim graph is built from your codebase, your decisions, and your incident history, and it earns a track record with every deploy.
The models give the organisation capability. The layer gives the agents a governed context and a governed memory - the institutional grounding that decides whether delegated coding becomes an asset or an exposure.
The way to get this wrong is to govern everything at once. The way to get it right is to shrink the scope hard and keep the architecture intact. Nothing in the first instance touches regulation, company-wide knowledge, or a new governance function.
The layer adds the claim model, the standing function, and the gate. It does not rebuild the plumbing - the prerequisites already run in your estate.
Shrink the claim count, the domain, and the action scope as far as is useful - but keep the gate and the encode-back loop. Drop either and it stops being the Knowledge Layer and becomes retrieval with extra steps.
Anticipated objection - "this is a better service catalog, or RAG, or policy-as-code." Catalogs and RAG return what exists, not what is admissible to rely on now. Policy-as-code gates the artifact, not the basis the agent reasoned from. The layer's distinct contribution is standing - computed, decaying, outcome-validated - and the signed manifest.
The previous slide is the shape of the pilot: one platform, six to eight weeks, the gate in shadow mode before it blocks. This slide is what the team does inside that shape - the order knowledge is ingested, the components built, the technology they map onto, and the handful of people who run it.
Order by authority and tractability. The board's decisions are the canon and are already written. Dependency feeds are structured and automatable. Tacit knowledge in runbooks and postmortems is the hardest to type, so it comes last - the first instance is steps one and two only.
Seven components. The architecture is fixed; the products are not - the Microsoft and AWS columns are examples of how each component lands on a stack a team already runs.
| Component | What it does | Microsoft stack | AWS stack |
|---|---|---|---|
| Capture connectors | Read each source and stamp provenance at intake. | Functions or Logic Apps, GitHub API | Lambda, EventBridge, GitHub API |
| Claim store | The typed, bitemporal graph of claims. | Azure SQL temporal tables, or Cosmos DB | Aurora PostgreSQL bitemporal, or Neptune |
| Event log | Append-only and ordered - the spine that makes replay possible. | Azure Event Hubs | Amazon Kinesis or EventBridge |
| Standing function | Scores each claim and recomputes standing as evidence moves. | Azure Functions or Container Apps | AWS Lambda or ECS |
| Manifest service | Assembles and cryptographically signs the Context manifest. | Functions with Key Vault | Lambda with KMS |
| The gate | A required check in the pull-request pipeline, an admission step at deploy. | GitHub Actions check, Azure Pipelines | GitHub Actions check, CodePipeline |
| Encode-back pipeline | Consumes build, incident, and rollback signals; recomputes standing. | Azure Monitor with Functions | CloudWatch with Lambda |
A pilot team is three to five people, plus the architecture board's time. A pilot, not a programme.
Owns the first-instance charter, the architecture-board liaison, and the go-live decision.
Build and run the claim store, the standing function, the gate, and the capture connectors.
Author and maintain the claims with the board. Usually senior engineers, not a full-time hire.
The authority that approves architectural canon. Already exists - no new headcount.
Across the three phases of the previous slide: the curators and the board lead the opening weeks - ingest and author the first claims; the layer engineers carry the middle - the store, the standing function, and the gate in shadow mode; the lead runs go-live and the tier-by-tier widening.
The stack columns are examples, not a mandate. The architecture needs a bitemporal claim store, an append-only event log, a signing service, and a gate in the pipeline - build each on the products your platform already runs.
The Knowledge Layer · IT projection · May 2026