Beyond AI protocols: Preparing for MCP and A2A in production
The future of enterprise architecture is increasingly being written by AI, but not the kind you access through a single prompt and wait for an answer. The next wave of AI is agentic: composed of distributed, autonomous processes that perceive, reason, and act across enterprise environments.
New protocols like MCP (Model Context Protocol) and A2A (Agent2Agent) have drawn excitement with their promise of standardizing how AI agents autonomously discover and interact with enterprise systems, and even other agents. But protocols are just the beginning for enterprises figuring out how to prepare their data and application infrastructures for an agentic future.
We’ve seen this movie before. A decade ago, we were grappling with how to modernize large applications for the cloud. The shift from monoliths to API-driven microservices brought promise, but also a degree of confusion. People debated what made a service truly “micro.” Coordination and orchestration patterns were unclear.
So what can we learn from the microservices transformation that might help us best position our infrastructure for the agentic wave? To answer that, we first need to understand where we stand today.
Where are we now in the agentic architecture journey?
Agentic AI is still in its formative stages. Most organizations are discovering and experimenting. Some are just beginning to understand what agent-to-agent communication could enable. Others are starting to build bridges between AI models and enterprise systems.
Between MCP and A2A, MCP is the more readily adopted standard so far. Marketed as the “USB-C for enterprise data access,” MCP is open, practical, and already seeing early adoption from hundreds of companies and technology providers. A2A is more ambitious, and less mature. While MCP focuses on agent-to-system integration, A2A tackles the harder problem of autonomous agent coordination.
But here’s the limitation early adopters are discovering: both protocols are stateless by design. Once an agent sends or receives a message, the interaction is gone. There is no durable memory, no record, no lineage. That’s fine for experiments. But try to run a multi-agent workflow in production—say, a financial planning agent coordinating with a risk assessment agent and a compliance agent—and you’ll quickly hit walls trying to troubleshoot, test new agent versions, or audit decision-making.
As a community, we had to address this lack of transaction records previously, before microservices could be widely adopted. While stateless services can scale easily and are simple to manage, they ultimately offload the burden of memory, history, and coordination to external systems, creating bottlenecks or deficiencies for complex, distributed environments. Today’s stateless agentic AI systems face the same challenge: they lack the ability to retain context across interactions, making them brittle and hard to coordinate at enterprise scale.
Data infrastructure must become a first-class participant
Making agentic architectures work in production is not merely a protocol problem; it’s a data architecture problem. Agents are not just consumers of static prompts. They’re autonomous decision-makers that react to their environment. This means your data infrastructure needs to support real-time decisions informed by the business environment, not just batch processing and static queries.
Consider the example of an e-commerce company deploying agents for inventory management, customer service, and fraud detection. These agents need to share context. When the inventory agent sees unusual demand patterns, the fraud detection agent should know immediately. When customer service resolves a complaint, both inventory and fraud agents should have that context for future decisions. Without machinery to share this state, each interaction starts from zero.
You may have heard the phrase “agents are microservices without guardrails.” That’s exactly why event-driven design has become essential. It’s what allowed microservices to evolve beyond brittle, point-to-point architectures. Stateless APIs gave way to event streaming because developers needed the ability to revisit past interactions. They needed causality. They needed to reason about time and context.
Apache Kafka was the technology that made that shift real, bringing state, observability, and decoupling to microservices and enabling them to scale reliably. Each message isn’t passed by API, but rather transmitted via a Kafka-based event stream. Applying this pattern to modern agent design means that the MCP calls, A2A messages, and generated side effects are all choreographed as events in Kafka logs, creating a record that can be inspected for troubleshooting, audited against policies, or replayed as service improvements pass quality control.
Kafka topics give agents a shared memory space where they can react to events, share observations, and make decisions. Kafka provides the durable, reactive substrate that stateless protocols like MCP and A2A require. This infrastructure becomes the “memory layer” that neither MCP nor A2A provides by itself.
Implementation patterns that work (and those that don’t)
We are seeing familiar patterns emerge as enterprises begin serious MCP and A2A implementations. Here are two key lessons learned so far:
- Protocol-first implementation: One common mistake is starting with MCP or A2A integration without considering the underlying data architecture. This often leads to agents that work in isolation but fail when they need to coordinate or remember context across interactions.
- The big bang approach: Another mistake is building a large agentic platform before solving any real problems. This can lead to slow progress, high costs, and growing skepticism when results don’t appear quickly.
What works instead is focusing on the foundational systems that allow agents to communicate reliably and maintain state across interactions. In the early days of microservices, that meant going beyond simple APIs and adopting tools like Kafka. These platforms introduced event streaming as a way for services to communicate, share state, and work independently while staying in sync. Today, successful MCP and A2A implementations follow the same pattern.
Here are two key patterns that do work:
- Start with your infrastructure: Before implementing MCP or A2A protocols, establish a foundational data substrate where data is a discoverable, trustworthy asset. This gives agents a place to store and retrieve context, log decisions for audit trails, and coordinate without tight coupling. My experience has been that data streaming technologies like Kafka are helpful here at the scale that enterprises commonly need.
- Implement statefulness gradually: Begin with simple MCP integrations for data access, then gradually add A2A coordination as your event infrastructure matures. Each agent interaction should generate events that other agents can consume and react to.
Invest in data readiness, not model glory
Oftentimes, great data with off-the-shelf models outperforms great models with poor data. This principle becomes even more critical when implementing MCP and A2A in production environments, where the quality and availability of real-time context determines how well agents can reason and act.
Here’s what this means in practice: the choice of LLM (large language model) provider behind your MCP implementations — be it OpenAI, Anthropic, or open-source models — often matters far less than data quality. Even the most advanced models will make poor decisions based on stale or incomplete data.
The microservices era taught us that simplicity is easy to lose. Teams over-engineered systems into “microliths.” Services became too chatty. Data consistency broke down without clear ownership. We’re seeing the same risks emerge in early agentic implementations, especially when coordination, memory, and control flow are left as afterthoughts.
The bottom line is, you don’t need to build your own foundation model, but you do need an architecture that delivers high-quality, contextualized, and trustworthy data to the agents and models you choose. For MCP and A2A implementations specifically, an event streaming infrastructure can handle real-time agent coordination, persistent context storage, and reliable message delivery between autonomous systems.
Start creating that foundation now, because your future agentic AI implementations depend on it.
—
Generative AI Insights provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss the challenges and opportunities of generative artificial intelligence. The selection is wide-ranging, from technology deep dives to case studies to expert opinion, but also subjective, based on our judgment of which topics and treatments will best serve InfoWorld’s technically sophisticated audience. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Contact doug_dineley@foundryco.com.
Original Link:https://www.infoworld.com/article/4046484/beyond-ai-protocols-preparing-for-mcp-and-a2a-in-production.html
Originally Posted: Tue, 09 Sep 2025 09:00:00 +0000
What do you think?
It is nice to know your opinion. Leave a comment.