Governed agent platforms on one page
The argument of the eight field notes, condensed for a board, a CIO or an architecture review. Print it, or read the notes behind each line.
Governance is not a layer you add to an agent platform. It is the platform. Everything else is sourced.
What one governed agent action looks like
The pattern behind the platform I built. Every box is a place where the organisation, not the model, decides.
- 01Request. A user or event starts a run. The run is durable and inspectable from the first step.
- 02Policy gate. Rules are enforced outside the prompt. The model cannot talk its way past them.
- 03Model call. Through a gateway with a qualified, pinned route. Output is treated as an untrusted candidate.
- 04Tool action. Default-deny allow-list, enforced twice: in the runtime and at the gateway.
- 05Human approval. High-stakes actions wait for a named person. Everything else is supervised on the loop.
- 06Evidence. Hash-chained record of what applied, who approved, what happened. Cannot be edited afterwards.
Illustration of the design, not a client result
Five decisions every agent platform makes, whether or not anyone chose
- 01
Identity and delegation
Who is this agent, on whose behalf does it act, and what may it do that the person may not? Agents are principals with their own revocable identity; effective rights never exceed the sponsoring human.
- 02
Policy enforcement
Where do the rules run? Outside the prompt and outside the runtime, by a component that executes no agent code. A rule inside the thing it governs is a convention, not a control.
- 03
Approval binding
What exactly is the human approving? A specific plan revision and evidence state, with a freshness window. If anything changed, the approval is stale and the run asks again.
- 04
Tool mediation
Who decides whether a tool call executes? A deterministic component, default-deny, enforced twice. Model output is a proposal, never an instruction.
- 05
Evidence
What record survives? One written by the component you own, hash-chained, never edited. Provider logs and traces are raw material, not evidence.
The eight notes, one line each
- 01The trust rootNo model provider, runtime or cloud may be the thing you cannot question. Own a small governance spine; source everything else. Apply the exit test.
- 02Connected is not sovereignTwo assurance classes, and the second never implies the first. A model route is an immutable contract. No automatic failover across classes.
- 03What frameworks governFrameworks govern what lives inside the run. Identity, policy, approval and evidence are left to you. Buy the runtime, build the spine.
- 04MCP gatewaysA gateway mediates tools and forwards identity. It cannot bind approvals or make tool servers safe. Evaluate it as a security component.
- 05The run is the unitDurable execution is a governance requirement before a reliability one. Without a run, nothing can be approved, audited or stopped.
- 06Prove or hopeEvaluation proves behaviour on chosen cases. Guardrails check one request. Observability shows what happened. "Safe to use" belongs to a person with a date.
- 07Evidence against enthusiasmEvidence that the field has a capability never proves that you have it. Name the subject and time scope of every claim. Regrade yourself first.
- 08Rules for coding agentsDeclared write sets, forbidden decision fields, "not established", named sign-off. Validators detect; humans prevent.
Four questions for your next architecture review
- Which component is our trust root, and did we choose it?
- When the sovereign route goes down on a Friday afternoon, what does the system do?
- For each framework or gateway on the diagram: which of the five decisions does it take, and which say "us"?
- What was our human override rate last month, and who holds the mandate at each gate?