Readable
Sign up freeRun AI report

MCP And A2A Are Becoming The Business Plumbing

Published 5/26/2026 • 18 min read • Ankit Biyani • Kaushik B

MCP And A2A Are Becoming The Business Plumbing

About the authors

Table of contents

There is a category of infrastructure that only becomes visible to business leaders after it has already reshaped the competitive landscape. TCP/IP was invisible until the internet was not. RSS was invisible until content distribution was not. APIs were invisible until every SaaS company either had one or was losing deals to companies that did.

MCP and A2A are in that same early window right now.

The Model Context Protocol and the Agent-to-Agent Protocol are not, on the surface, the kind of topics that belong in a CMO's weekly reading. They sound like engineering specifications. They have version numbers and JSON schemas. Developers argue about them on GitHub.

But the strategic logic underneath them is not technical at all. It is about distribution, access, and competitive positioning in a world where software is increasingly operated by agents rather than humans.

If you are a founder or a marketer, the question is not whether you need to understand the protocol mechanics. You do not. The question is whether you understand what these protocols make possible, and whether your product is positioned to benefit from that shift or be bypassed by it.

This article is written for the second group: the people who need the strategic picture without the engineering detour.

The Protocol Layer Is Now a Strategic Layer

For most of the last decade, the protocol layer was genuinely a developer concern. If your engineering team chose REST over GraphQL, or decided how to structure your webhooks, those were implementation details. They affected developer experience and integration speed, but they did not typically show up in board decks or growth strategy conversations.

That is changing, and the change is happening faster than most business leaders realize.

The clearest signal came when Anthropic acquired Stainless, a company known for building SDKs, CLIs, and MCP server tooling. Stainless was not a flashy AI product. It was infrastructure for making APIs easier to consume. The acquisition logic is straightforward: agents are only as useful as the systems they can reach. If more APIs can become agent-accessible, more work can move from human-operated software into agent-operated workflows. Anthropic did not acquire Stainless because it needed another product. It acquired Stainless because agent accessibility is now a product priority, not a side project.

That is a signal worth reading carefully. When a frontier AI lab spends acquisition capital on API tooling, it is telling you something about where the leverage is.

The broader shift is this: software is becoming less isolated. For most of the SaaS era, applications were designed around human users. You logged in, you navigated a dashboard, you clicked buttons, you exported data. The interface was a screen, and the assumption was that a person was on the other side of it.

That assumption is breaking down. Workflows are increasingly being delegated to agents. Agents do not log in. They do not navigate dashboards. They call capabilities directly, retrieve data programmatically, and hand off tasks to other agents. The interface they need is not a UI. It is a protocol.

This mirrors a shift that happened before. When the web emerged, companies that had been distributing information through brochures and printed catalogs had to decide whether to build a website. The ones that moved early captured organic traffic, built brand presence, and established distribution advantages that compounded over years. The ones that waited found themselves playing catch-up in a channel that had already been claimed.

The shift from pages to capabilities is the same transition, one layer deeper. In the SaaS era, every company wanted users inside its dashboard. In the agentic era, every company will need to decide which parts of its product, content, data, and workflows can be safely exposed to agents. The companies that make that decision early will build distribution advantages that compound. The ones that wait will find the channel already claimed.

The protocol layer is no longer just an engineering concern. It is becoming distribution infrastructure.

MCP and A2A Solve Two Different Problems

One of the most common mistakes in conversations about agentic AI is treating MCP and A2A as competing standards or as interchangeable terms. They are neither. They solve fundamentally different problems, and confusing the two leads to bad architecture decisions and, more importantly for business leaders, bad strategic decisions.

Here is the clearest way to hold the distinction.

MCP is about how agents connect to tools and data.

The Model Context Protocol, introduced by Anthropic in late 2024, standardizes the way AI agents connect to external systems: databases, APIs, file systems, SaaS platforms, and any other tool or data source an agent might need to do its work. Before MCP, every integration was bespoke. If you wanted to connect Claude to a database, you wrote custom code. If you wanted to connect a different model to Slack, you wrote different custom code. If you wanted to reuse any of that work across models or platforms, you largely could not. As the DEV Community's comprehensive breakdown of both protocols puts it: every AI provider had its own way to connect to external tools, each requiring different JSON schemas, different response formats, and different error handling.

MCP eliminates that fragmentation. It creates a standard interface so that a tool built once can be used by any agent that speaks MCP. The USB-C analogy is imperfect but useful: just as USB-C standardized how devices connect to power and peripherals regardless of manufacturer, MCP standardizes how agents connect to tools and data regardless of which model or platform is running the agent.

The Firecrawl breakdown of MCP vs A2A describes MCP's architecture as a host-client-server model: the AI application acts as the host, an MCP client handles the protocol communication, and MCP servers expose the actual tools and data. This separation means the agent does not need to know anything about the underlying system. It just needs to know how to speak MCP.

MCP A2A are different

A2A is about how agents coordinate with each other.

The Agent-to-Agent Protocol, announced by Google in April 2025, solves a different problem entirely. As multi-agent systems became more common, there was no standard way for agents to discover each other, negotiate capabilities, or hand off tasks. If you had a research agent and a writing agent, getting them to collaborate required custom orchestration code that was brittle, hard to maintain, and impossible to reuse across different agent frameworks.

A2A standardizes agent-to-agent communication. It gives agents a way to advertise their capabilities through what the protocol calls an Agent Card, discover other agents that can handle specific tasks, delegate work, and receive results. The HTTP analogy is apt: just as HTTP created the basic rails for web communication regardless of what server or browser was involved, A2A creates the basic rails for agent collaboration regardless of which framework or vendor built each agent.

As Aishwarya Srinivasan's detailed protocol analysis frames it: MCP is vertical, connecting agents downward to tools and data. A2A is horizontal, connecting agents sideways to other agents. Together they form the two axes of the agentic stack.

The practical implication for non-technical readers is this: if your product needs to be reachable by agents, MCP is the relevant protocol. If your product involves agents that need to coordinate with other agents, A2A is the relevant protocol. Most sophisticated agentic workflows will eventually need both, but they are solving different problems and should not be conflated.

Before these protocols existed, every integration was custom code. Both protocols eliminate that fragmentation, but in different directions. Removing either one breaks a different part of the workflow.

Why 150 Organizations Backing A2A Is a Signal Worth Reading

Protocol adoption follows a familiar pattern. A standard emerges, a small group of early adopters builds on it, and for a while it looks like an interesting experiment. Then a critical mass of production deployments accumulates, enterprise vendors start building native support, and the standard stops being optional infrastructure and starts being table stakes.

A2A has crossed that threshold faster than most observers expected.

The Linux Foundation recently announced that A2A has passed 150 supporting organizations, with production use cases documented across multiple industries. That number matters not because of its size in isolation, but because of what it represents: the standard is no longer being evaluated. It is being deployed. Companies are not running pilots to see if A2A is viable. They are running production workflows that depend on it.

The Zendesk adoption is the more instructive data point for business leaders. Zendesk is not a startup experimenting with emerging protocols. It is an established enterprise software vendor with a large customer base and significant switching costs. When Zendesk builds both MCP client and server capabilities into its core product, it is making a statement about where enterprise software is heading.

In plain terms, Zendesk's MCP client capability means Zendesk agents can reach into external systems to retrieve data and trigger actions. Its MCP server capability means external agents can reach into Zendesk data and workflows. Both directions matter. The first makes Zendesk agents more capable. The second makes Zendesk data and workflows accessible to any agent ecosystem that a customer is running.

That bidirectional model is the right mental model for every product team. Your product is not just a tool your agents use. It is also a capability that other agents might need to access. Building MCP server support means you are making your product callable by the broader agent ecosystem, not just by your own users.

When enterprise software vendors build protocol support into their core product, the protocol is no longer optional infrastructure. It is becoming the expected interface. The companies that have not built it yet are accumulating a kind of technical debt that will eventually show up as a distribution disadvantage.

The standards race is not approaching. It is already underway. The 150 organizations backing A2A are not waiting for the protocol to mature. They are the ones making it mature.

Brett Willms, writing on LinkedIn about the significance of these protocols, described the moment clearly: beneath the noise of AI hype, the most important work happening right now is not flashy. It is plumbing. Foundational infrastructure that will determine which systems can participate in the agentic economy and which cannot.

The Question Every Product Team Now Has to Answer

There is a strategic question that every product team needs to put on the table, and most have not asked it yet.

Should your product only have a UI, or should it also be callable by agents?

UI alone is not enough. Be Agent Ready.

This is not a rhetorical question. It has a concrete answer that depends on your product, your customers, and your competitive position. But the default assumption, that a UI is sufficient, is no longer safe.

In the SaaS era, the goal was users inside your dashboard. Engagement metrics, session duration, feature adoption, monthly active users: all of these were proxies for the same underlying assumption that value was created when humans interacted with your product through its interface. The stickier the UI, the stronger the moat.

In the agentic era, that assumption inverts. Agents do not care about your UI. They cannot be retained by good UX. They will not recommend your product to colleagues because the onboarding flow was smooth. What agents care about is whether your product is callable, reliable, and well-documented at the protocol level.

The companies that are building MCP server capabilities now are not doing it because they have solved all their other product problems. They are doing it because they understand that agent-accessible capabilities are a new form of distribution. If your product can be called by an agent, it will appear in more automated workflows. If it cannot, it will not.

Every company needs to audit which parts of its product, content, data, and workflows can be safely exposed to agents. This audit has several dimensions:

What can be exposed without risk? Public data, documentation, product catalogs, knowledge bases, and read-only capabilities are typically safe starting points. Making these MCP-accessible is low-risk and high-value.

What requires authentication and permissioning? Customer data, transactional capabilities, and anything that can modify state needs careful access control. MCP supports authentication, but the design of your permission model matters.

What should never be agent-accessible? Some capabilities are too sensitive, too consequential, or too context-dependent to delegate to agents. Knowing what to exclude is as important as knowing what to include.

As the enterprise localization analysis from Intento illustrates, even specialized industries are working through this audit. Localization teams are asking which parts of their translation workflows can be exposed to agents, which require human review, and how MCP and A2A change the role of the localization team within the enterprise. The same questions apply in every vertical.

This is not a future decision. The companies adopting MCP server capabilities now are building early distribution advantages. The window for being an early mover is open, but it will not stay open indefinitely. Once the major platforms in your category have built agent-accessible interfaces, the baseline expectation will shift, and catching up will be harder than leading.

If you want to understand how your current content and product documentation would perform in an agent-accessible world, analyzing your existing assets is a useful starting point. The same clarity that makes content readable to humans makes it callable by agents.

How MCP and A2A Work Together in Practice

The complementary relationship between MCP and A2A becomes intuitive when you trace a real workflow from start to finish.

Consider a customer support scenario. A customer contacts a company about a billing dispute. In a human-operated workflow, a support agent logs into the CRM, pulls up the order history, identifies the billing issue, transfers the customer to the billing team, and the billing team resolves the dispute. Each handoff involves a human reading data from one system and entering it into another.

In an agent-operated workflow, the same process looks different at every step.

How MCP and A2A Work Together in Practice

The orchestrating support agent receives the customer's message. It uses MCP to connect to the order management system and retrieve the customer's order history. It uses MCP again to pull the customer's previous support interactions from the CRM. It uses MCP to check the billing system for the specific transaction in question. All of this data retrieval happens through standardized MCP calls, not through custom integrations or human navigation.

Now the agent has enough context to understand the dispute. But resolving a billing dispute requires specialized knowledge and potentially specialized authority. The support agent is not the right agent for that task. This is where A2A enters.

The support agent uses A2A to discover a specialized billing agent that has the capabilities and permissions to resolve billing disputes. It hands off the task through an A2A message that includes the relevant context: the customer ID, the transaction in question, the nature of the dispute, and the conversation history. The billing agent receives the handoff, processes the dispute, and returns a resolution. The support agent communicates the resolution to the customer.

The TDeFi analysis of MCP and A2A describes this pattern clearly: MCP handles the vertical connections to tools and data, while A2A handles the horizontal connections between agents. Neither protocol replaces the other. Removing MCP means the agents cannot access the data they need to do their work. Removing A2A means the agents cannot delegate to specialists or coordinate across systems.

The three-layer protocol stack maps cleanly onto this workflow. At the bottom layer, MCP handles tool and data access: databases, APIs, file systems, and external services. At the middle layer, individual agents use that data to reason and act. At the top layer, A2A handles orchestration: task delegation, capability discovery, and cross-agent coordination.

This architecture is not hypothetical. The DEV Community's implementation guide documents production patterns for exactly this kind of multi-agent workflow, including the message formats, authentication flows, and error handling that make it reliable in practice.

For business leaders, the key insight is not the technical architecture. It is the strategic implication: workflows that currently require human coordination across multiple systems and teams can be delegated to agents, but only if the underlying systems are accessible through protocols like MCP and A2A. The protocol layer is the prerequisite for workflow delegation.

What This Means for Distribution and Competitive Moats

The competitive moats of the SaaS era were built on UI stickiness, data lock-in, and network effects. Users stayed because switching was painful, because their data lived in your system, and because their colleagues were already using your product. These moats were real and durable, but they were built on the assumption that humans were the primary operators of software.

That assumption is shifting, and the moats are shifting with it.

In the agentic era, the next competitive moat may be how easily trusted agents can work with your product, not how sticky your UI is. This is a different kind of moat, and it requires a different kind of investment.

Consider what agent-accessibility means for distribution. In the web era, organic distribution meant appearing in search results when users searched for relevant terms. In the agentic era, organic distribution means appearing in automated workflows when agents are looking for capabilities to call. If your product is MCP-accessible and well-documented at the protocol level, agents will find it, call it, and route work to it. If it is not, agents will route to competitors that are.

This is a new form of organic distribution, and it compounds in the same way that search rankings compound. The products that agents call repeatedly become the products that agents trust. The products that agents trust become the default choices in automated workflows. The default choices in automated workflows become the products that appear in more and more agent-operated processes over time.

Companies that become agent-accessible early will appear in more automated workflows by default. This is not a prediction about a distant future. It is a description of what is already happening in the organizations that have deployed production agentic workflows.

Content, data, and knowledge assets take on a different character in this context. In the web era, a well-written knowledge base article was a passive page that users might find through search. In the agentic era, a well-structured knowledge base that is MCP-accessible becomes a callable capability. An agent can retrieve exactly the information it needs, in a structured format, without navigating a UI. The knowledge base stops being a destination and becomes a service.

This has implications for how companies think about their content strategy. Content that is structured, accurate, and accessible is not just good for human readers. It is good for agents. The same properties that make content readable and useful to humans make it callable and reliable for agents. If you want to understand how your content performs on those dimensions, TryReadable's analysis tools can help you identify where your content is working and where it is creating friction.

Brand trust will also extend to agent trust. In the human-operated web, brand trust meant that users chose your product over competitors because they believed in its quality and reliability. In the agentic era, brand trust means that agents route to your product because it is reliably callable, consistently accurate, and well-behaved at the protocol level. If your MCP server returns reliable data and handles errors gracefully, agents will route to it repeatedly. If it is unreliable, agents will route to alternatives.

This is a new dimension of brand reputation, and it is one that most marketing teams have not started thinking about yet. The Aishwarya Srinivasan analysis frames the ecosystem implication clearly: the protocols are not just technical standards. They are the infrastructure on which the agentic economy will be built. The companies that build on that infrastructure early will have structural advantages that are difficult to replicate later.

For CMOs and founders who want to understand what this means for their specific competitive position, the starting point is the audit described in the previous section: what can your product expose to agents, what requires careful permissioning, and what should remain human-operated. That audit is not a one-time exercise. It is an ongoing strategic conversation about how your product participates in an increasingly agent-operated world.

If you want to explore what agent-accessible positioning looks like for your brand specifically, talking to the TryReadable team is a useful next step. The companies that are thinking about this now are the ones that will have the distribution advantages in two years.

The Window Is Open, But Not Indefinitely

The pattern of infrastructure adoption is consistent across technology cycles. There is a window when the infrastructure is real but not yet ubiquitous, when early movers can build advantages that compound, and when the cost of moving is lower than it will ever be again. After that window closes, the infrastructure becomes table stakes, and the advantage shifts to execution rather than positioning.

MCP and A2A are in that window right now.

The 150 organizations backing A2A are not the entire market. They are the early movers. The Zendesk adoption is not the end of enterprise protocol adoption. It is the beginning of the wave that will make protocol support an expected feature rather than a differentiator.

For founders, the question is whether your product roadmap includes agent-accessibility as a first-class concern, not a future consideration. For marketers, the question is whether your content and knowledge assets are structured in ways that make them callable by agents, not just readable by humans.

The protocol layer is becoming the distribution layer. The companies that understand this early will build moats that are genuinely difficult to replicate. The companies that treat it as developer trivia will find themselves on the wrong side of a distribution shift that has already begun.

The next competitive moat may be how easily trusted agents can work with you. The time to start building it is now.

TryReadable helps marketing and content teams understand how their content performs for both human readers and AI systems. Explore the analysis tools, see how other brands are approaching this, or read more guides on content strategy for the agentic era.

Sources

Continue in Docs.

Related posts