Table of Contents
- The Two Protocols Shaping Agent Architecture
- What the Model Context Protocol Actually Is
- What A2A Brings to the Table
- The Boundary Diagram: Where Trust Ends and Negotiation Begins
- Transport, Auth, and Discovery Side by Side
- Decision Table: Which Protocol for Which Integration Type
- Building With Both: An Architecture That Ships
- What This Means for Your AI Roadmap
- Summary and Next Steps
The Two Protocols Shaping Agent Architecture
In the span of a single year, two open protocols—the Model Context Protocol (MCP) and the Agent-to-Agent Protocol (A2A)—have redrawn the map for how AI agents connect to tools, data, and each other. The question is no longer whether you need a protocol; it’s which protocol belongs at which boundary. Get the boundary wrong, and you bake in brittle integrations, ballooning token costs, and a security posture that keeps your CISO awake at night. Get it right, and you ship agentic systems that scale across teams, clouds, and organizational silos.
This guide is written for the operators—the fractional CTOs, platform engineers, and PE-backed portfolio leaders—who need to make a call this quarter. We’ll walk through exactly what MCP and A2A do at the wire level, compare their transport, auth, discovery, and failure modes, and give you a decision table you can take straight into an architecture review. Along the way, we’ll ground the conversation in the current model landscape: the Claude 5 family (Opus 5 and Sonnet 5 with 1M-token context windows, Fable 5 as the most capable widely released model, and Haiku 4.5 as the 200K-context fast tier) and their competitors—GPT-5.6 Sol and Terra, Gemini 3, Kimi K3, and the open-weight ecosystem.
If you’re leading a mid-market company or a private equity roll-up and you need to ship agentic AI that drives measurable EBITDA lift, the protocol layer is where the rubber meets the road. Let’s get into it.
What the Model Context Protocol Actually Is
MCP was introduced by Anthropic as an open standard for connecting AI applications to external tools and data sources. The official MCP documentation describes it as a client-server protocol that gives models a structured way to discover and invoke capabilities—think database queries, API calls, file system access, or even browser automation—without hard-coding every integration. The MCP specification lives on GitHub, and the broader docs hub provides quick-start guides and implementation references.
At PADISO, we treat MCP as the default wiring for any tool or data source that lives inside the agent’s trust boundary. When a Claude Opus 5 instance needs to pull a customer record from your Snowflake warehouse or trigger a workflow in your internal platform, MCP is the right answer. The protocol is designed for a single agent (the client) talking to multiple servers, each exposing a set of tools, resources, and prompt templates.
The Client-Server Mental Model
MCP is fundamentally a request-response protocol. The client—typically a language model hosted by an AI provider or run locally—sends a tools/list request to discover what a server offers, then issues tools/call to execute. Servers can also push notifications for resource changes, but the core interaction is synchronous and tightly coupled. This works beautifully when latency is low and the server is something you control: an internal API gateway, a vector database, or a platform engineering layer you’ve built on AWS or Azure.
What MCP does not do is negotiate. It doesn’t understand task delegation, multi-step handoffs, or agent identity beyond the client’s session. That’s by design. MCP is about giving a single, trusted agent superpowers—not about coordinating a swarm of independent agents across organizational boundaries.
Transport, Auth, and Discovery in MCP
MCP supports two primary transports: stdio (for local processes) and HTTP with Server-Sent Events (SSE) for remote servers. In practice, most production deployments use HTTP+SSE, which allows a long-lived connection for streaming responses. The protocol itself is transport-agnostic; you can run it over WebSockets or even inside a Kubernetes pod if you’re building a platform in San Francisco or New York where latency to your data plane is measured in single-digit milliseconds.
Authentication is deliberately not part of the MCP spec. The protocol assumes that auth happens at the transport layer—OAuth 2.0 bearer tokens, mTLS, or cloud IAM—and that the server trusts the client’s identity once the connection is established. This is a sharp boundary decision: MCP is not meant to handle cross-organizational trust. If you need Agent A from your supply chain platform to talk to Agent B running inside a partner’s ERP, MCP alone won’t give you the identity federation or policy enforcement you need. That’s where A2A enters the picture.
Discovery in MCP is straightforward: the client calls tools/list and gets back a JSON schema describing every available tool, its parameters, and its output shape. This static discovery model works well when the tool landscape changes slowly—say, when your fractional CTO has defined a stable set of internal services. It becomes painful when tools are added or removed dynamically across dozens of agents, which is exactly the scenario A2A was built for.
Failure Modes That Break MCP
MCP’s failure modes are, for the most part, the failure modes of any tightly coupled client-server system. If the server is unreachable, the agent stalls. If the tool schema changes without the client’s knowledge, calls fail with cryptic errors that the model may or may not recover from. If the server’s auth token expires mid-session, you get a 401 and a broken workflow.
These failures are manageable when you own the server and can monitor it with the same observability stack you use for the rest of your platform. They become unmanageable when you’re trying to connect to a third-party agent that you don’t control and can’t instrument. That’s the precise boundary where you should stop using MCP and start using A2A.
What A2A Brings to the Table
The Agent-to-Agent Protocol is a newer, complementary standard designed for a fundamentally different problem: enabling autonomous agents to discover each other, negotiate tasks, and exchange results across trust boundaries. The community specification organizes the core protocol, discovery mechanisms, data structures, and even MCP integration guidance into a coherent framework.
Where MCP says “here are my tools, call them,” A2A says “here is a task I can perform, negotiate with me.” This shift from tool exposure to task-oriented capability advertisement is what makes A2A suitable for multi-agent systems that span organizational silos—exactly the kind of architecture you need when you’re consolidating tech across a private equity portfolio or building a venture architecture that orchestrates agents from acquired companies.
Agent-to-Agent Negotiation, Not Tool Calling
A2A agents advertise “agent cards”—structured descriptions of the tasks they can perform, the inputs they expect, and the artifacts they produce. When Agent A wants to delegate work, it doesn’t call a tool; it sends a task proposal. Agent B can accept, reject, or counter-propose. This negotiation layer is what allows agents to operate autonomously without a central orchestrator.
For a concrete example, imagine a PE firm running a roll-up of three logistics companies. Each company has its own AI agent that manages route optimization. Using A2A, the parent entity’s agent can discover each subsidiary’s agent, propose a consolidated optimization task, and receive a negotiated plan—without ever exposing the internal tooling of any individual company. That’s a level of decoupling MCP simply cannot provide.
Transport, Auth, and Discovery in A2A
A2A is transport-agnostic as well, but the reference implementations lean heavily on gRPC and HTTP/2 for bidirectional streaming. This matters because agent-to-agent communication often involves long-running tasks with intermediate status updates—something that MCP’s request-response model handles awkwardly. A2A’s design anticipates that agents will be distributed across clouds, regions, and organizations, so it builds in support for asynchronous messaging patterns from day one.
Authentication in A2A is a first-class concern. The protocol defines an identity layer based on decentralized identifiers (DIDs) and verifiable credentials, allowing agents to prove who they are and what they’re authorized to do without relying on a shared transport-layer trust model. This is critical when you’re connecting agents that belong to different legal entities—say, a portfolio company’s agent and a third-party logistics provider’s agent. You can enforce fine-grained policies without exposing internal secrets, which aligns well with the SOC 2 and ISO 27001 audit-readiness posture that PADISO helps clients achieve through Vanta.
Discovery in A2A is dynamic. Agents can register with a discovery service, broadcast their agent cards, or use peer-to-peer protocols to find each other. This is a stark contrast to MCP’s static tool listing, and it’s the reason A2A scales to environments where the set of available agents changes by the hour.
Failure Modes That Break A2A
A2A’s failure modes are more complex because the protocol operates across trust boundaries. An agent may be unreachable, may reject a task after negotiation has started, or may return a partial result and then disappear. The protocol includes mechanisms for timeouts, retries with exponential backoff, and dead-letter queues, but these mechanisms assume that both sides are running compatible implementations—a big assumption in a multi-vendor ecosystem.
The bigger risk is semantic mismatch. Two agents may speak A2A fluently but disagree on what a “route optimization” task actually means. Resolving these mismatches requires a shared ontology or a human-in-the-loop, which is why PADISO’s AI Strategy & Readiness engagements always include a semantic mapping exercise before any multi-agent architecture goes live.
The Boundary Diagram: Where Trust Ends and Negotiation Begins
The cleanest way to think about MCP versus A2A is to draw a line around your trust boundary. Inside the boundary—your VPC, your Kubernetes cluster, your platform engineering environment—use MCP. Outside the boundary—partners, acquired companies, third-party SaaS agents—use A2A.
graph TD
subgraph TrustBoundary[Your Trust Boundary]
AgentA[Agent A<br/>Claude Opus 5]
Tools[Internal Tools & Data]
MCP_Server[MCP Server]
AgentA -->|MCP: tools/list, tools/call| MCP_Server
MCP_Server -->|Read/Write| Tools
end
AgentB[Agent B<br/>External Partner]
Discovery[A2A Discovery Service]
AgentA -->|A2A: task proposal, negotiation| AgentB
AgentB -->|A2A: agent card publication| Discovery
AgentA -->|A2A: agent card lookup| DiscoveryThis diagram captures the essential split. Agent A uses MCP to interact with internal tools—databases, APIs, file systems—that live inside the same trust boundary. When it needs to delegate work to Agent B, which sits outside that boundary, it switches to A2A for task negotiation, identity verification, and result exchange. The discovery service sits outside both agents, enabling dynamic lookup without compromising internal tool schemas.
For a mid-market company that has just completed a platform development project in Seattle and is now integrating an acquired subsidiary’s AI agent, this diagram is the blueprint. MCP handles the internal plumbing; A2A handles the cross-entity coordination.
Transport, Auth, and Discovery Side by Side
| Capability | MCP | A2A |
|---|---|---|
| Primary Transport | stdio, HTTP + SSE | gRPC, HTTP/2 bidirectional streaming |
| Communication Pattern | Synchronous request-response (with limited streaming) | Asynchronous, long-running task support with status updates |
| Authentication | Transport-layer only (OAuth 2.0, mTLS, cloud IAM) | Identity layer with DIDs and verifiable credentials; policy enforcement at agent level |
| Discovery | Static tool listing via tools/list | Dynamic agent card publication and lookup; supports centralized and peer-to-peer discovery |
| Capability Model | Tools, resources, prompts | Tasks, artifacts, negotiation primitives |
| Trust Model | Implicit trust within a single administrative domain | Explicit, verifiable trust across administrative domains |
This table makes the boundary decision concrete. If you’re wiring up a Claude Sonnet 5 instance to your internal PostgreSQL database, you don’t need DIDs and verifiable credentials—MCP’s transport-layer auth is sufficient. If you’re connecting that same instance to a partner’s GPT-5.6 Sol agent that runs inside their Azure tenant, you absolutely need the identity and negotiation primitives that A2A provides.
Decision Table: Which Protocol for Which Integration Type
The following table maps common agent integration scenarios to the recommended protocol, with a brief rationale. Use it as a starting point for your architecture review.
| Integration Scenario | Recommended Protocol | Rationale |
|---|---|---|
| Agent to internal database (Snowflake, PostgreSQL, BigQuery) | MCP | Single trust domain, low latency, static schema |
| Agent to internal API gateway (REST, GraphQL) | MCP | Tools map cleanly to API endpoints; auth handled at gateway |
| Agent to cloud services (AWS Lambda, Azure Functions, Google Cloud Run) | MCP | IAM-based auth aligns with transport-layer model |
| Agent to vector database (Pinecone, Weaviate, pgvector) | MCP | Resource exposure fits MCP’s resource primitives |
| Agent to browser automation (Playwright, Puppeteer) | MCP | Tight coupling, single-agent control |
| Agent to agent within same organization but different teams | A2A (with internal PKI) | Cross-team trust requires explicit identity; task negotiation avoids tight coupling |
| Agent to agent across legal entities (partner, subsidiary, third-party SaaS) | A2A | Cross-boundary trust, verifiable credentials, dynamic discovery |
| Agent to human-in-the-loop approval system | A2A | Long-running tasks with status updates; human can counter-propose |
| Agent to multi-agent swarm for complex workflow orchestration | A2A | Dynamic discovery, task delegation, failure isolation |
| Agent to legacy system without a modern API (screen scraping, terminal emulation) | MCP (via custom server) | Wrap legacy access in an MCP server; keep the ugly integration inside your boundary |
This table isn’t theoretical. When PADISO engages as a fractional CTO for a PE-backed roll-up, we use exactly this framework to decide which protocol goes where. The goal is to minimize the number of protocols in play while maximizing the autonomy and security of each agent.
Building With Both: An Architecture That Ships
The most common pattern we see in production is a layered architecture: MCP servers for internal tool access, wrapped by an agent that uses A2A to coordinate with external agents. The agent itself—running Claude Opus 5 or Fable 5 for complex reasoning—acts as a bridge, translating internal tool results into task proposals and negotiating with peers.
This is where tools like mcp-agent come in. The mcp-agent framework provides a higher-level abstraction for building agents that consume MCP servers, handle tool selection, and manage conversation state. When you combine mcp-agent with an A2A client library, you get a single agent process that can pull data from internal MCP servers and then delegate work to external A2A agents—all within a coherent execution loop.
For a concrete example, consider a platform development engagement in Sydney where a financial services client needs to build an agent that answers analyst queries by pulling data from an internal ClickHouse warehouse (via MCP) and then negotiating with an external research agent (via A2A) to incorporate third-party market data. The architecture looks like this:
- Internal MCP Layer: A ClickHouse MCP server exposes a
run_querytool. Auth is handled via AWS IAM, since both the agent and the ClickHouse cluster run in the same VPC. - Agent Core: A Claude Sonnet 5 instance, hosted on AWS Bedrock, uses mcp-agent to manage the MCP connection and tool calling.
- External A2A Layer: The same agent process includes an A2A client that discovers the research agent’s card, proposes a task (“fetch market data for AU equities”), and receives a stream of artifacts.
- Result Assembly: The agent merges internal and external data, formats the response, and returns it to the analyst.
This architecture ships. It’s not a slide deck; it’s running in production for clients who have moved beyond AI experimentation and are now measuring AI ROI in hard dollars. PADISO has helped 50+ businesses generate $100M+ in revenue through exactly this kind of strategic AI implementation, and the protocol layer is a big part of why those implementations stick.
What This Means for Your AI Roadmap
If you’re a CEO or board member of a mid-market company, the protocol decision may sound like an engineering detail. It’s not. It’s a strategic choice that determines how quickly you can integrate acquisitions, how securely you can partner with AI-native vendors, and how much of your AI investment turns into reusable platform assets versus one-off integrations.
For private equity firms running roll-ups, the stakes are even higher. Every acquired company comes with its own tech stack, its own data silos, and increasingly its own AI experiments. Without a clear protocol boundary strategy, you end up with a spaghetti of point-to-point integrations that destroy the very EBITDA lift you’re trying to create. With MCP inside and A2A outside, you get a repeatable pattern that turns tech consolidation from a cost center into a value driver.
PADISO’s CTO as a Service engagements typically start with exactly this conversation: mapping the trust boundaries across your portfolio, defining the protocol strategy, and then building the platform engineering foundation—whether in San Francisco, Sydney, or anywhere your operations run—that makes it real. The retainer model (typically $100K–$500K) gives you a senior operator who can make these calls without the overhead of a full-time CTO hire.
And if you’re staring down an enterprise deal that requires SOC 2 or ISO 27001 compliance, the protocol layer matters there too. A2A’s identity primitives align naturally with the access control and audit trail requirements that auditors look for. Combined with Vanta-driven audit readiness, you can go from zero to audit-passed in weeks, not months.
Summary and Next Steps
MCP and A2A are not competitors. They solve different problems at different boundaries, and the best agent architectures use both. MCP gives your agents secure, structured access to the tools and data you control. A2A lets those agents negotiate and collaborate with agents you don’t control, across organizational and trust boundaries.
The decision table and boundary diagram in this guide give you a concrete starting point. The next step is to apply them to your own architecture. Draw your trust boundary. Inventory your integrations. Decide which ones belong inside (MCP) and which ones cross the line (A2A). If you need a senior operator to help you make that call and then ship the result, PADISO’s fractional CTO and platform engineering teams are here to co-build with you.
Agent protocols are moving fast, but the boundary principle is stable. Get the boundary right, and everything else—scalability, security, audit readiness, AI ROI—falls into place.