Two years ago, connecting an AI model to a company’s systems meant writing custom integration code for every pairing of model and tool. Each team built its own connectors to the CRM, the ticketing system and the data warehouse, and each new model or framework meant doing it again. By late 2026 that picture has changed. Two open protocols, the Model Context Protocol (MCP) for connecting agents to tools and data, and Agent2Agent (A2A) for connecting agents to each other, have moved into neutral governance at the Linux Foundation and into the products of every major cloud and AI vendor.
For anyone responsible for an enterprise AI platform, this is the most consequential architectural shift since the arrival of retrieval-augmented generation. It changes what the platform should provide, where the security boundaries sit and how much vendor lock-in is necessary. This article explains what happened, how the two protocols fit together and how to design a platform around them.
What Changed in the Last Twelve Months
On December 9, 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. Anthropic, Block and OpenAI co-founded the foundation, with support from Google, Microsoft, Amazon Web Services, Cloudflare and Bloomberg. MCP joined two other founding projects: Block’s goose agent framework and OpenAI’s AGENTS.md convention. At the time of the donation Anthropic reported more than 10,000 active public MCP servers and more than 97 million monthly SDK downloads across Python and TypeScript, with adoption in ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.
In parallel, A2A, originally introduced by Google and contributed to the Linux Foundation, marked its first anniversary in April 2026 with the release of version 1.0, its first stable specification. The Linux Foundation reported more than 150 supporting organizations, including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow, and integrations into Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore Runtime.
The practical consequence is that enterprise buyers no longer have to bet on a single vendor’s proprietary agent ecosystem. Tools exposed via MCP can be used by agents from different vendors, and agents that speak A2A can delegate work to each other across platforms.
How MCP and A2A Fit Together
The two protocols address different relationships and are complementary rather than competing.
MCP: Agent to Tool
MCP standardizes how an AI application (the client) discovers and uses capabilities exposed by a server: tools it can call, resources it can read and prompts it can use. A finance team might expose an MCP server offering “get invoice status” and “list overdue accounts” on top of its ERP. Any MCP-capable agent, whether an IDE assistant, a chat assistant or a custom agent, can then use those capabilities without bespoke integration.
The November 25, 2025 specification release, as summarized by identity vendor WorkOS, added several features aimed at enterprise use:
- Tasks (experimental): long-running requests can return a handle that clients poll, rather than holding a connection open.
- Client ID Metadata Documents: clients identify themselves via an HTTPS URL they control, replacing dynamic client registration as the recommended approach.
- Enterprise-managed authorization (Cross App Access): the corporate identity provider applies policy and issues short-lived assertions, so administrators can see and govern which AI apps reach which tools.
- Machine-to-machine OAuth: a standard client-credentials flow for headless agents with no user session.
- URL-mode elicitation: servers can send users to a browser for sensitive steps such as OAuth consent or payment, so the client never handles those secrets.
- Extensions: a formal mechanism for optional capabilities without changing the core specification.
A2A: Agent to Agent
A2A standardizes how one agent discovers another, describes what it can do and delegates a task to it, without the two sharing internal memory, prompts or tools. Each agent publishes an Agent Card describing its skills and endpoints. Version 1.0 introduced signed Agent Cards for cryptographic identity verification, multi-tenancy support and updated security flows. A procurement agent built on one framework can ask a supplier-risk agent built on another to assess a vendor, and receive a structured result.
A useful mental model: MCP is how an agent uses its hands; A2A is how agents talk to colleagues. Most enterprise workflows will need both, and most platforms will implement MCP first because tool access delivers value even with a single agent.
Open agent standards turn integrations into reusable enterprise assets. Build each tool once as a governed MCP server, publish each agent once with an A2A card, and let any approved client use them.
The Enterprise Agent Platform: Reference Layers
With standard protocols in place, the job of an enterprise AI platform shifts from building integrations to providing shared, governed infrastructure. A practical reference architecture has six layers:
- Model access layer. Approved models from multiple providers, accessed through a gateway that handles routing, quotas, cost attribution and failover.
- Tool layer. A catalog of MCP servers wrapping enterprise systems, each owned by the team that owns the underlying system, with documented scopes and data classifications.
- Agent layer. Agents built with whichever framework fits, registered in an agent directory with A2A cards, owners, risk tier and lifecycle status.
- Identity and policy layer. Integration with the corporate identity provider so that every agent and every tool call carries an identity, with policies deciding which agents may use which tools on behalf of which users.
- Observability and evaluation layer. Traces of model calls, tool calls and agent-to-agent delegations, plus offline and online evaluation of quality, cost and safety.
- Developer experience layer. Templates, SDKs, local testing harnesses and a self-service portal for publishing tools and agents.
This is essentially platform engineering applied to agents: a paved road that makes the secure, observable path the easiest one.
Build Versus Buy, Layer by Layer
Open standards make it reasonable to mix commercial and in-house components, so the build-versus-buy decision is best made per layer rather than for the platform as a whole. Model access, identity and observability are usually bought or adopted from existing enterprise tooling, because they are commodity capabilities with mature products and the cost of building them is high. The tool layer is almost always built in-house, because only your teams understand your systems, data classifications and business rules; it is also where the lasting value accumulates. The agent layer is mixed: buy agents embedded in SaaS products you already use, and build agents for workflows that differentiate your business. The developer experience layer is typically a thin internal product on top of the others. The test for any purchase is portability: if the vendor disappeared, could your MCP servers, agent definitions and traces move elsewhere with modest effort?
Identity and Security: The Hard Part
Protocols solve connectivity, not trust. The most serious risks in agent platforms come from three sources: agents with overly broad permissions, untrusted content steering agent behavior (prompt injection through documents, emails or tool outputs), and unvetted servers installed by individuals. A platform should address each explicitly.
Least Privilege by Design
- Give every agent its own non-human identity, never shared service accounts.
- Scope tool access per agent and per user context, using OAuth scopes and short-lived tokens; the MCP enterprise-managed authorization pattern lets the identity provider enforce this centrally.
- Separate read tools from write tools and require stronger controls, such as human approval, for irreversible actions.
- Prefer machine-to-machine flows for background agents so they never borrow a human’s session.
Controlling the Supply Chain of Tools
- Maintain an internal registry of approved MCP servers; block installation of arbitrary public servers on managed devices.
- Review third-party servers like any other software dependency: provenance, maintainer, permissions requested and update cadence.
- Verify agent identity using signed A2A Agent Cards before delegating tasks to external agents.
Containing Prompt Injection
- Treat all tool outputs and retrieved content as untrusted data, never as instructions.
- Limit what an agent can do after reading untrusted content, for example by preventing it from sending data externally in the same session.
- Log and alert on unusual tool-call patterns, such as a summarization agent suddenly calling an export tool.
Observability and Evaluation for Agents
When an agent produces a wrong answer, you need to see which model calls, tool calls and delegations led there. OpenTelemetry’s generative AI semantic conventions, now maintained in a dedicated repository, define spans, metrics and events for GenAI clients and include conventions for MCP. Adopting them early gives you vendor-neutral traces that work across frameworks and observability back ends. At minimum, capture for each interaction: the agent and version, the model and parameters, token usage and cost, each tool call with arguments and results (redacted where sensitive), latency, and the final outcome with any human feedback.
Traces tell you what happened; evaluation tells you whether it was good. Maintain a curated set of representative tasks for each agent, with expected outcomes or grading criteria, and run it whenever the model, prompt, tools or agent code changes. In production, sample real interactions for review and track task success, escalation rate, tool-error rate and cost per completed task. Treat a drop in any of these like a failed deployment.
A Worked Example: Customer Onboarding Across Three Teams
Consider a generic B2B software company whose onboarding process touches sales operations, finance and IT provisioning. Today, a coordinator copies data between the CRM, the billing system and the identity platform, and onboarding takes several days.
- Each system owner publishes an MCP server: sales operations exposes contract and account data; finance exposes customer billing setup; IT exposes tenant provisioning. Each server declares scopes, such as read-only contract access versus billing write access.
- The platform team registers these servers in the internal catalog, connects them to the corporate identity provider and applies policies: only the onboarding agent may call the provisioning tool, and only for accounts with a signed contract.
- An onboarding agent is built in the team’s preferred framework. It reads the signed contract via MCP, drafts the billing configuration and requests provisioning.
- For credit checks, the onboarding agent delegates via A2A to an existing risk agent owned by finance, which returns a structured risk rating without exposing its internal data.
- Billing setup above a contract-value threshold pauses for human approval in the finance queue. Everything else proceeds automatically.
- Every call is traced with OpenTelemetry. When an onboarding goes wrong, the team can see whether the contract data, the risk assessment or the provisioning call caused it.
The MCP servers built for this flow are immediately reusable by a support assistant, an account management agent and developer tools, which is where the platform economics come from.
Adoption Roadmap
- Inventory. List agent and assistant initiatives already running, including shadow usage of public MCP servers, and the systems they touch.
- Set the guardrails. Define identity, approval and logging requirements for tools and agents by risk tier before scaling.
- Build three to five high-value MCP servers. Choose systems many teams need, such as CRM, knowledge base and ticketing, and build them to production standards with scopes and tests.
- Stand up the catalog and gateway. Provide discovery, policy enforcement, cost attribution and tracing from day one.
- Pilot one cross-team agent workflow. Use A2A where an existing agent owned by another team can be reused rather than rebuilt.
- Measure and expand. Track reuse of tools, time to publish a new tool, incident rates and business outcomes; use them to prioritize the next wave.
Decision Criteria and Pitfalls
When evaluating vendors and frameworks, ask the following:
- Does it support current MCP authorization features, including enterprise-managed authorization, or only static API keys?
- Can its agents publish and consume A2A cards, including signed cards?
- Does it emit OpenTelemetry traces using the GenAI conventions, or only proprietary logs?
- Can tools and agents be moved to another platform without rewriting them?
The most common pitfalls are building MCP servers as thin, over-permissive wrappers around entire APIs instead of task-shaped tools; letting every team run its own unregistered servers; treating protocol compliance as proof of security; and assuming standards are static. Both specifications are evolving, so pin versions, track release notes and plan for upgrades.
Outlook and Conclusion
The move of MCP and A2A into neutral foundations makes it likely that agent interoperability will follow the path of earlier web standards: rapid convergence, then a long period of hardening around identity, security and operations. Expect more enterprise identity integration, richer long-running task support, and catalog and registry tooling to become standard features of AI platforms. Expect, too, that regulators and auditors will ask for the traceability these standards make possible.
For platform teams the message is clear. Stop building one-off integrations. Invest in a governed catalog of tools, a directory of agents, identity for every actor and observability for every call. Open standards make those investments portable across models and vendors, which is exactly what an enterprise platform should deliver.
How Hanoi Technology Can Help
Hanoi Technology designs and builds governed agent platforms, including MCP tool catalogs, identity integration and observability, as projects or managed services.