Agentic platform governance guidelines

2.1 The problem, and the value at stake

Industry research indicates that a substantial share of agentic AI projects are cancelled or stall before reaching production, citing escalating costs, unclear business value, and inadequate risk controls, rather than model quality, as the primary causes. This framework exists to remove exactly those three causes at the platform level: it fixes the contract and integration cost of building a new capability, it makes reusable capabilities discoverable through a registry instead of anecdotal, and it makes risk controls such as identity, authorization, audit, and human approval mandatory rather than optional per team.

The value at stake is real: independent industry research estimates trillions of dollars in annual value from generative AI across the use cases studied, with meaningful productivity gains in customer-facing operations. That value is only realized when individual capabilities are trustworthy and composable enough to be put into production and reused across journeys. That is the condition this governance framework is designed to create.

2.2 How these guidelines help

Governance helps in four concrete ways, each implemented by a specific set of standards later in this document:

• Reduces duplication and rework: A shared capability skill contract and a central registry let teams discover and reuse existing capabilities instead of rebuilding them.
• Makes capabilities composable across domains: Standardized A2A interaction and declared orchestration topologies let capabilities from different teams work together without bespoke point-to-point integration.
• Builds in the risk controls that are most commonly missing from ungoverned agentic deployments: Mandatory identity, authorization, audit, and HITL standards are non-negotiable at integration boundaries, not left to individual teams to remember.
• Keeps change safe at scale: Versioning, deprecation, and compatibility rules mean a capability can evolve without silently breaking every consumer that depends on it.

2.3 What this framework will not do

Governance changes the conditions under which agentic capabilities are built; it does not, by itself, guarantee the outcomes above:

• It does not guarantee ROI or business value. Realizing that value still depends on adoption, execution quality, and domain-specific value capture.
• It does not improve reasoning or model quality. Output accuracy is a model, prompt, and data-engineering concern owned by the domain team.
• It does not replace funding decisions, organizational change management, or platform investment prioritization.
• It does not remove the need for domain judgment. Segmentation strategy, HITL thresholds, and agent vs. tool trade-offs remain domain decisions; the framework sets mandatory boundaries, not the decisions themselves.

3.1 Objective and scope

Objective: Enable distributed domain teams to build, expose, and scale agentic capabilities in a consistent, interoperable, governed, and enterprise-compliant manner.

In scope: Microdomain agents, which handle reasoning and orchestration; microdomain MCP tools, which handle deterministic execution; capability skill contracts; and domain user journeys orchestrated through the supervisor. Governance applies to platform contracts and integration boundaries, not internal implementation details, unless implementation choices affect compliance obligations, such as personally identifiable information (PII) handling or auditability.

3.2 Architecture principles

The platform architecture is guided by five principles:

• Built on open standards: Adheres to open and interoperable architectures, incorporating standards and protocols such as A2A [1] and MCP [2] to promote flexibility and portability.
• Built to be tech-agnostic: Any language, framework, or large language model (LLM) can be used.
• Built for distributed ownership: Each domain owns its capabilities.
• Built to scale: Modular boundaries, one domain per module.
• Built on a single registry: Capabilities integrate via governed contracts.

Together, these principles map to concrete outcomes: open standards and tech-agnosticism give portability across languages, frameworks, and vendors; modular, domain-owned boundaries give composability, since capabilities can be recombined without cross-domain rework; and the single governed registry gives operational consistency as the platform scales to additional domains and markets.

3.3 Reference capability model and control boundary

A user request enters through the public interface. The supervisor receives the request's intent, selects the appropriate capabilities, and invokes the relevant agent, MCP tool, or both, using the A2A protocol, the MCP protocol, or both. Domain capabilities then execute under contract and return structured outputs, which the supervisor composes into the final journey outcome. On the control boundary, the supervisor controls orchestration, context, and routing, while domain teams control capability behavior and implementation within contract limits. Every exposed capability must be classified as an agent or an MCP tool and must publish a version-controlled capability skill contract that specifies a semantic description, input/output schema, constraints, identity requirements, exception behavior, service-level agreement (SLA), fallback, retry, and life cycle.

4.1 Decision framework: Agent vs MCP tool

Build as a domain agent when the capability requires reasoning, decision-making, multistep planning, conversational context, or orchestration of multiple tools, for example a product discovery agent or an order resolution agent.

Build as a domain MCP tool when the operation is deterministic, transactional, a direct application programming interface (API) call, requires no reasoning, and can be stateless and repeatable, for example an add-to-cart API, an inventory lookup, or a pricing calculation.

Decision rule: If business value depends on reasoning quality, build an agent; if it depends on execution certainty, build an MCP tool. Complex capabilities commonly combine both, with clear separation of concerns.

4.2 Agent and MCP tool design standards

Agents are contract-first: Externally observable behavior is bound to the published capability skill contract schema, and undeclared side effects are not permitted. Agents reason, plan, and orchestrate; deterministic execution is always delegated to an MCP tool. Agents are stateless-first; memory, if genuinely required, is declared in the contract and scoped to the journey. By default, agents do not call other agents directly; cross-capability interactions are routed through the supervisor using A2A. Direct agent-to-agent communication is permitted only in approved peer-to-peer (A2A collaborative) topologies as defined in Section 4.3. Agents must behave predictably under retry, partial failure, and timeout, with errors classified as validation, authorization, downstream, or internal, and with predefined fallback paths, and must emit a full observability signal: inputs, outputs, consequential reasoning decisions, every tool call, and end-to-end trace IDs.

MCP tools are the deterministic counterpart: Given the same input and authorized context, a tool returns the same outcome, and reasoning and decision-making stay in the agent layer. Tools execute; they do not decide. They expose a standard API surface, using OpenAPI 3.x [3] for REST-style tools and the MCP tool-schema for MCP-native tools, are stateless by default with idempotency for mutating endpoints, enforce their own authentication and authorization rather than trusting the caller, and emit the same structured logs, trace IDs, and latency, error, and throughput metrics as agents. Both agents and tools declare SLA, ownership, and version in the capability skill contract; behavior changes affecting consumers require an explicit version bump, never a silent rollout.

4.3 A2A interaction and orchestration governance

All cross-capability interactions use the approved A2A protocol, shared message schemas, and platform timeout and retry behavior, which is non-negotiable, since it is what makes capabilities composable across domains and markets. Within those guardrails, domain teams retain flexibility over when to invoke a tool versus delegate to another agent, how to batch or stream responses, and how to optimize for latency and cost.

The platform supports three orchestration topologies, and teams must declare their choice at workflow registration. Under the default, supervisor-orchestrated topology, the supervisor coordinates all agents and tools centrally, and domains never call each other directly. Under the hierarchical topology, a domain orchestrator agent manages its own subagents internally, and the supervisor coordinates only at the top level; teams use this pattern when a domain's internal reasoning is too complex to expose to the supervisor directly. Under the peer-to-peer, or A2A collaborative, topology, agents collaborate directly with one another for emergent or exploratory workflows; because this pattern removes central coordination, it requires an explicit architecture review before it can go to production, and one agent must be designated as the trace anchor for end-to-end observability. Regardless of topology, every governed workflow must register in the central registry with its topology declared, propagate a single end-to-end trace ID, declare an SLA and timeout with a fallback path, support idempotent re-execution of steps with side effects, avoid holding workflow state inside individual agent processes, and, for workflows exceeding 60 seconds, carry a durable workflow ID that supports resume from the last successful step.

4.4 HITL and approval governance

HITL is mandatory when financial impact exceeds a domain-defined threshold; the outcome is a regulated decision, such as a credit, medical, or compliance decision, requiring auditable sign-off; the action is irreversible; the agent's confidence falls below a declared threshold; or the action deviates from standard policy. Capabilities that trigger any of these must declare the HITL requirement in their capability skill contract.

Three interaction patterns are supported and must be declared in the workflow definition: approve-before-execute, used for irreversible or high-impact actions, where the agent proposes an action and waits for human approval before executing it; review-and-correct, where the agent executes and holds its output pending human review, approval, or correction before it is committed; and exception escalation, where the agent executes autonomously within confidence bounds and escalates to a human reviewer only when confidence falls below threshold or an anomaly is detected. Every HITL step emits a structured, traceable approval request containing the workflow ID, step ID, reasoning summary, proposed action, confidence indicator, and escalation deadline. Every approval step declares a response timeout with a predefined path on expiry; approver identity is authenticated and recorded in the audit log; and overrides are logged and flagged for periodic governance review. The internal tooling used to surface approval requests, such as task queues, notification channels, or review interfaces, is a domain or product decision, provided the structured contract and audit requirements above are met.

4.5 Capability registration, discovery, and experience layer

Every agent and MCP tool is registered centrally with its current capability skill contract, version, owner, status, and scope, whether global, market-specific, or segment-specific; capabilities outside the registry are not considered part of the platform, regardless of where they run. Centralized discovery reduces duplicate builds, accelerates reuse during journey design, and gives platform governance the operational picture it needs: who owns what, what version is live, and what is deprecated. User journeys integrate with capabilities through supervisor routing rather than bespoke point-to-point integrations from the frontend. How a capability visually surfaces to the user, for example through adaptive cards, conversational responses, or structured forms, remains a domain and product decision; the standard governs routing and contract, not visual treatment.

4.6 Operational governance and security

Every agent and MCP tool emits structured, machine-readable logs at every invocation, capturing trace and correlation IDs, sanitized inputs and outputs with PII masked per data classification policy, execution outcome and error classification, and latency. For agents, logs also capture reasoning decisions and tool invocations at decision boundaries. DEBUG-level logging stays disabled in production by default and is enabled only under an active incident ticket. The audit trail is distinct from operational logs: it immutably records capability invocations, data access and mutation, human approvals and overrides, security events, and life cycle events, retained per enterprise policy and itself access-controlled.

Observability operates at both the capability level and the workflow level. Capability-level signals include P50, P95, and P99 latency against declared SLA, error rate, throughput, and availability. Workflow-level signals include end-to-end latency, step-level failure rates, and HITL queue depth and timeout rate. Dashboards are provisioned as part of production promotion, not after go-live. A single trace ID is generated at entry and propagated unmodified through every hop; no capability may drop, replace, or regenerate it. Retry behavior is declared in the capability skill contract and applied consistently. Ad-hoc retry logic inside implementations is not permitted, and domain-level retries must never exceed supervisor timeout thresholds.

Security is a platform-level obligation every capability participates in. Identity flows end to end and is never fabricated within a capability; authorization and role-based access control (RBAC) [4] are enforced at both agent and MCP boundaries; personally identifiable information (PII) is handled per enterprise policy and applicable regulation, such as the General Data Protection Regulation (GDPR) [5] and the California Consumer Privacy Act (CCPA) [6]; and privileged operations are fully auditable. Authentication is standardized by hop: OAuth 2.0 [7] with proof key for code exchange (PKCE) [8] secures human-to-supervisor authentication; short-lived signed service tokens secure supervisor-to-agent calls; scoped bearer tokens propagated without re-issuance or elevation secure agent-to-MCP tool calls; and mutual transport layer security (mTLS) [9] or OAuth 2.0 client credentials secure external integrations. Hard-coded credentials, embedded shared secrets, and permanent non-expiring service tokens are prohibited; secrets live exclusively in the platform secrets manager and rotate on a defined schedule.

Domains decide how to segment capabilities, whether by geography, market, segment, or role, and how to apply least-privilege access within these mandatory controls. In multitenant deployments, every request carries a tenant context propagated unchanged through the call chain; cross-tenant data access is prohibited regardless of how the underlying data store is structured; per-tenant rate limits and resource quotas prevent one tenant from degrading service for others; and blast-radius containment, achieved through circuit breakers, bulkheads, and timeout enforcement at the supervisor boundary, is a mandatory platform control that domain teams must not bypass.

4.7 Life cycle, versioning, and deprecation

Every capability carries a semantic version number in the format MAJOR.MINOR.PATCH, for example 1.8.2, following the semantic versioning [10] scheme, in its capability skill contract and the registry. PATCH changes require no consumer action; MINOR changes are additive and backward compatible; MAJOR changes are breaking and require a versioned parallel release with a consumer migration plan. A breaking change may never replace a live version in place. During any transition window the prior major version remains fully supported for security and critical fixes; standard parallel operation runs for 90 days, or 180 days for regulated capabilities, with retirement gated on consumer migration reaching a declared adoption threshold that defaults to 95%. Every MAJOR change requires a breaking-change review confirming that all consumers have been notified, a migration guide is available, the parallel-operation window is sufficient, and rollback capability exists; the review is logged in the registry as an auditable governance event. Domain teams provide a conformance test suite per version, and consumers validate against a platform-provided sandbox before migrating. Emergency deprecation, triggered by a critical security or regulatory driver, compresses the timeline but still requires immediate consumer notification, architecture-governance approval within 24 hours, platform support for accelerated migration, and a post-incident review.

7.1 Known limitations

• No guarantee of reasoning quality. These guidelines certify an agent's contract, security posture, and operational behavior, not that its reasoning is correct, unbiased, or fit for purpose. Output quality remains a domain and model-owner responsibility.
• Assumes platform primitives already exist. The standards assume a functioning supervisor, identity service, secrets manager, central registry, and log aggregation platform; this document specifies integration with those primitives, not how to build or operate them.
• Compliance is currently self-attested, verified through the publication readiness checklist at promotion time. The framework does not yet mandate automated, continuous conformance scanning after go-live.
• Peer-to-peer topology guidance is intentionally light; it remains an emerging pattern, permitted only after case-by-case architecture review rather than under a fully codified standard.
• Business value realization is out of scope. Whether a capability delivers positive return depends on adoption, execution, and domain-specific factors this document cannot control.

7.2 Future work

• Automate capability skill contract linting and registry conformance checks in continuous integration and continuous deployment (CI/CD) pipelines, reducing reliance on manual checklist review.
• Define a formal maturity model, for example pilot, managed, or optimized, for assessing governance adoption consistently.
• Extend HITL and audit standards with quantitative model-risk monitoring, such as confidence drift and anomaly-rate tracking, as agentic reasoning surfaces mature.
• Develop cross-enterprise or cross-platform federation standards if the platform needs to interoperate with external partner agent ecosystems.
• Establish a recurring review cadence, recommended annually, to incorporate evolving A2A and MCP protocol versions and new regulatory requirements.

8.1 Recommended metrics

Each of the following key performance indicators (KPIs) traces back to a driver named earlier in this document: capability reuse rate and duplicate-build incidence, which tracks reduced duplication; capability onboarding lead time, which tracks whether contract-first design is reducing integration cost; contract compliance rate, meaning capability skill contract completeness and validity; P95 and P99 latency against declared SLA; error rate and retry success rate; security policy compliance rate and audit findings, which track whether mandatory risk controls are actually reducing risk, a leading cause of cancelled agentic AI projects; and version adoption and deprecation completion rate.

8.2 Publication readiness checklist

Before a capability is published, the following must be true: it is classified correctly as an agent or an MCP tool; the capability skill contract exists, is validated, and is versioned; input, output, and error schemas are complete; SLA, timeout, retry, and fallback are defined; security, RBAC, and identity propagation are verified; logging, traceability, and monitoring are operational; registry metadata is complete and discoverable; versioning and deprecation policy is documented; and user journey integration and the feedback loop are validated.