01 / THE REQUIREMENT
What the system must handle
As agent use grows, fragmented credentials, logs, evaluations, memory, and model integrations create operational and governance risk
02 / THE ARCHITECTURE
How the pieces connect
Create shared identity, permissions, tool registries, observability, evaluations, deployment controls, and policy enforcement across agent workloads
03 / OPERATING MODEL
How the system behaves
Teams can build and operate agents on a common foundation while retaining system boundaries, auditability, and vendor flexibility
WHY THIS PATTERN EXISTS
The problem it solves
The first agent on a team is an engineering project. The tenth is an infrastructure problem. Left alone, every team invents its own credential handling, its own logging, its own definition of done, and its own opinion about which model to call, until nobody can answer what the organisation's agents are allowed to touch or whether last Tuesday's decision was correct. The control plane is the shared substrate that makes agent work auditable, replaceable, and safe to scale across teams.
COMPONENTS
What you are actually deploying
Central identity and secrets
Agent credentials are issued, scoped, rotated, and revoked centrally, with no long-lived keys living in application code. Every action is attributable to a human or a service identity, which is the minimum requirement for any audit that matters.
Governed tool registry
Tools are registered once with a declared schema, an owner, a risk classification, and an approval history. Agents discover capabilities from the registry rather than being handed whatever an engineer connected that week.
Policy enforcement
Policies are evaluated at execution time, not at review time. A tool call that violates policy is blocked before it runs, and the block is logged with the policy that fired. Controls written only in a prompt are advisory; controls written here are structural.
Observability and replay
Prompts, retrieved context, tool calls, and outputs flow through one trace store. Any execution can be replayed exactly, which turns incident review into a lookup rather than an archaeology project across three logging tools.
Evaluation and release gates
Task suites run before promotion and continuously afterwards. A model, prompt, or tool change that degrades measured quality does not reach production, so behaviour changes are gated like any other code change.
Model routing
Models are selected per task against measured reliability, latency, and cost, and can be swapped centrally. Model choice stops being a per-team debate and becomes an operational decision with evidence attached.
FAILURE MODES
How these systems break
Every one of these has been found in production during an incident review. They are listed here because the design is only credible if it names what it defends against.
Credential sprawl
API keys pasted into repositories and environment files cannot be rotated quickly or attributed in an audit. Short-lived, scoped credentials issued by the control plane remove both problems at once.
Governance by documentation
A written policy nothing enforces produces agents that technically comply and operationally drift. Policy has to run at the point of action.
Unreplayable decisions
When prompts, context, and outputs are logged in three places with different retention, nobody can reconstruct why an agent acted. One trace store with replay is the requirement.
Untracked quality drift
Model providers update models without notice. Without evaluation gates, an agent's behaviour changes under you and the first signal is a customer complaint.
FIT
When to use this, and when not to
Use it when
- More than one team ships agents, and each one currently solves identity, logging, and evaluation differently.
- Someone will eventually be asked to prove what an automated decision did and who authorised it.
- You are paying multiple teams to re-solve the same infrastructure problem in different stacks.
- Regulated or high-volume work requires controls that survive staff turnover and vendor changes.
Do not use it when
- You have one agent and one operator. A control plane is overhead with no return at that scale.
- You cannot commit to maintaining it. An unowned control plane becomes another thing that is documented and bypassed.
QUESTIONS
What teams ask before building this
Do we need this before our first agent ships?
No. With one agent, the control plane is pure overhead. It becomes worth building when a second team appears, when credentials start multiplying, or when someone needs to prove what an automated decision did. The trigger is organisational scale, not enthusiasm.
Does this lock us into one vendor?
The opposite. Central model routing and a governed tool registry exist so individual components can be replaced without rewriting the system. The dependencies we standardise on are the ones we have measured, and the abstraction layer is where substitution happens.
How is a policy actually enforced?
At the tool layer, at execution time. A call that violates policy is blocked before it reaches the system, and the block is logged with the policy that fired. Controls implemented only in a prompt are advisory, which is why we do not rely on them.
Who maintains it?
A small platform team owns the control plane; product teams own their agents and their task suites. The split matters, because the alternative is a control plane that every team resents and nobody keeps current.
DEPLOYED THROUGH
Capabilities that build it
APPLIED IN