Building a governed enterprise agent runtime
MCP Is an Interface, Not an Operating Model
MCP standardizes access to capabilities. An enterprise runtime must still own identity, policy, orchestration, evidence and accountability.
Model Context Protocol solves an important interoperability problem: it gives AI applications a consistent way to discover and invoke tools, resources and prompts.
That is a major building block. It is not, by itself, an operating model for a company.
MCP standardizes capabilities. The enterprise runtime must govern execution.
The boundary MCP intentionally does not own
Suppose a server exposes a tool called approve_payment. The protocol can describe its arguments and carry the call. The company must still decide who may request it, under which business objective, within what limit, using which evidence, with whose approval, and how the result changes organizational state.
These are not transport concerns. They are governance and execution concerns.
Interface vs. runtime
Discovery, schemas, resources, prompts and standardized tool invocation.
The human, agent, service, organization and delegated authority behind a request.
What the actor may do in this context, with these limits and approval requirements.
Why the action is needed, how it relates to a plan and what should happen before and after it.
The inputs, decisions, tool results and state transitions that make the action auditable.
Every tool call needs an execution envelope
Passing only the tool name and arguments is insufficient for consequential work. The runtime should construct an execution envelope that travels with the request and remains attached to the result.
- Actor identity and delegated role.
- Organization, workspace and data boundary.
- Goal, task and step that justify the action.
- Risk class and policy decision.
- Budget, time, data and retry limits.
- Required approval and separation-of-duty rules.
- Idempotency key, correlation ID and evidence references.
- Expected state transition and rollback or compensation path.
The MCP call is one part of that envelope. The operating system around it decides whether the call should exist at all.
A governed runtime has six control planes
1. Capability registry
Discovery must become curated inventory. The registry records owners, versions, environments, data sensitivity, side effects, cost characteristics, health and allowed consumers for every capability.
2. Identity and delegation
An agent should never inherit unlimited authority from the human who created it. Delegation is explicit, scoped, time-bound and revocable. The runtime resolves both the technical identity and the business role.
3. Policy decision and enforcement
The policy engine decides. The enforcement point ensures the decision cannot be bypassed. High-risk actions may require human approval, dual control or a constrained execution environment.
4. Orchestration and state
Tool calls belong to durable tasks with owners, dependencies, retries and outcomes. If a process stops, another actor must be able to resume it without reconstructing intent from a chat transcript.
5. Observability and evidence
Logs show that a request occurred. Evidence explains why it was allowed, which inputs mattered, what changed and how the outcome relates to the business objective.
6. Evaluation and learning
Successful execution is not the same as a useful outcome. The runtime evaluates quality, cost, policy compliance and downstream effects, then proposes changes to skills, prompts, routes or controls.
Risk classes make autonomy practical
Not every action needs a human. Treating all calls equally creates either unsafe autonomy or unbearable approval fatigue. A simple classification makes the trade-off explicit.
Example action classes
Bounded retrieval with no external side effect; generally automatic and fully logged.
Drafts, internal updates and actions that can be safely undone; automatic within policy.
External communication, spending, access changes or commitments; approval or dual control.
Irreversible, regulated or high-impact operations; strict authorization, evidence and supervised execution.
The architecture that scales
Use MCP at the capability boundary. Put an enterprise runtime between autonomous actors and those capabilities. Connect the runtime to tasks, organizational memory, approvals, observability and outcome evaluation.
This keeps MCP simple and portable while giving the company something the protocol should not attempt to provide: a coherent model of authority and responsibility.
A tool can be interoperable without being safe. A runtime turns interoperability into governed work.
