A2A for Enterprise-Scale AI Agent Communication: Architectural Needs and Limitations
The enterprise is on the cusp of a new era of automation, powered by a rapidly growing ecosystem of specialized AI agents. From sales forecasting agents in Customer Relationship Management (CRMs) to supply chain optimizers in Enterprise Resource Planning (ERPs) and engineering co-pilots in Product Lifecycle Management (PLM) systems.
These intelligent actors promise to revolutionize business processes. However, this transformative potential is constrained by a fundamental challenge: how do we make these disparate agents communicate, coordinate, and collaborate effectively at an enterprise scale?
Initial attempts to solve this, like Linux Foundation’s A2A protocol (formerly Google’s Agent-to-Agent protocol), have provided a valuable foundation for semantic interoperability, standardizing how agents describe their capabilities and format messages. Yet, they are built on an architectural paradigm, direct, point-to-point communication using HTTP and gRPC, that is fundamentally mismatched with the demands of a complex, distributed enterprise. This request-response model creates brittle, tightly-coupled systems where the number of connections explodes quadratically, operational complexity becomes unmanageable, and a single agent failure can trigger cascading disruptions.
Welcome to our blog series, An MQTT Architecture for Scalable Agentic AI Collaboration. In this series, we discuss how the path to scalable, resilient, and truly autonomous agent collaboration lies in a paradigm shift: from direct, request-response interactions to a decoupled, event-driven architecture. By replacing point-to-point connections with a central message broker, agents can communicate asynchronously by publishing events and subscribing to topics of interest. This approach eliminates architectural rigidity, enables dynamic workflows, and ensures reliable communication across complex and unreliable networks.
We will demonstrate that the MQTT protocol, with its lightweight design, robust publish-subscribe capabilities, and proven scalability in mission-critical IoT deployments, is the ideal communication fabric to act as the central nervous system for this new generation of enterprise AI. This blog series will deconstruct the limitations of HTTP-based protocols, detail the benefits of an event-driven model, and provide a concrete example for layering A2A semantics over MQTT. The result is a blueprint for building a truly interoperable AI agent ecosystem that is not only intelligent but also scalable, flexible, and resilient enough for the modern enterprise.
In Part 1 of this series, we begin by unpacking the current architectural limitations of the A2A protocol and establishing the case for an event-driven alternative.
The Foundation: The Promise and Principles of the A2A Protocol
When it comes to inter-agent communication, several approaches exist, including IBM’s Agent Communication Protocol (ACP) and efforts to treat agents as tools, utilizing frameworks such as the Model Context Protocol (MCP), developed by Anthropic. However, Linux Foundation’s A2A protocol (formerly Google’s Agent-to-Agent protocol) stands out as a well-defined and scalable approach for building enterprise-grade multi-agent systems.
To address the challenge of AI agent interoperability, the Agent-to-Agent (A2A) protocol is a standardized framework that enables AI agents from different vendors to communicate and collaborate consistently. Each agent using A2A exposes standardized metadata and a common set of public methods, making it possible for any other agent to interact with it, whether to delegate tasks, request updates, or coordinate workflows.
A2A follows a request-response model, where a client agent initiates a request (typically tied to user interaction), and a server agent responds by taking action or returning information. Importantly, any agent can act as both a client and a server, and internal implementation details remain abstracted behind the protocol.
At its core, A2A defines five key capabilities:
Standardized Message Formats and Transport Mechanisms: A2A uses JSON-RPC 2.0 over HTTP(S), gRPC, and HTTP+JSON/REST to ensure consistent communication across agents. It provides schema-based message definitions for semantic interoperability, allowing agents from different vendors to exchange structured, typed data without prior integration.
Dynamic Discovery via Agent Cards: Agents publish Agent Cards, JSON-based documents that advertise their identity, capabilities, supported tasks, and endpoint details. These cards make it possible for other agents to discover, authenticate with, and interact with them dynamically.
Built-in Task Management Workflows: Recognizing that tasks may involve multi-step interactions or take time to complete, A2A includes a task orchestration framework. It supports initiating, tracking, and resolving long-running or multi-turn interactions between agents.
Support for Multi-Modal Data Exchange: Communication is not limited to plain text. Agents can exchange documents, structured data, and even rich media, enabling broader and more flexible collaboration.
Security and Asynchronous CommunicationA2A includes encryption guidelines for secure communication. It also supports asynchronous processing and streaming updates using Server-Sent Events (SSE), allowing agents to deliver incremental results or status updates in real time.
How AI Agent-to-Agent (A2A) Protocol Works
To understand how A2A works in practice, let's examine a critical enterprise scenario. A Sales Forecasting Agent from the CRM system needs the Supply Chain Planning Agent from the Enterprise Resource Planning (ERP) system to adjust inventory levels based on predicted demand spikes.
In this case, the Sales Forecasting Agent acts as the client agent and the Supply Chain Planning Agent serves as the remote agent.
Discovering an AI Agent
How does the Sales Forecasting Agent even find the Supply Chain Planning Agent and understand its capabilities?
The Supply Chain Planning Agent publishes an agent card, a standardized JSON document served at a well-known URI on the agent's domain. This card provides everything the Sales Forecasting Agent needs to initiate collaboration.
{
"protocolVersion": "0.2.9",
"name": "Supply Chain Planning Agent",
"description": "Optimizes inventory levels and manages supplier relationships based on demand signals. This agent can adjust stock levels, coordinate with suppliers, and provide real-time supply chain visibility.",
"url": "https://globalindustries.com/agents/supply-chain/a2a/v1",
"preferredTransport": "JSONRPC",
"provider": {
"organization": "Global Industries",
"url": "https://globalindustries.com"
},
"version": "2.1.0",
"capabilities": {
"streaming": true,
"pushNotifications": false,
"stateTransitionHistory": true
},
"security": [{ "oauth2": ["supply_chain:read", "supply_chain:write"] }],
"defaultInputModes": ["application/json", "text/plain"],
"defaultOutputModes": ["application/json", "text/plain"],
"skills": [
{
"id": "inventory-optimizer",
"name": "Inventory Level Optimizer",
"description": "Adjusts inventory levels based on demand forecasts, analyzing current stock, lead times, and supplier capacity to prevent stockouts while minimizing excess inventory.",
"tags": ["inventory", "optimization", "forecasting", "supply-chain"],
"examples": [
"Adjust inventory for product WIDGET-A100 based on 15,000 unit Q4 forecast",
"{\"products\": [{\"id\": \"WIDGET-A100\", \"predicted_demand\": 15000, \"confidence\": 0.85}], \"time_period\": \"2024-Q4\"}"
],
"inputModes": ["application/json", "text/plain"],
"outputModes": ["application/json"]
},
{
"id": "supplier-coordinator",
"name": "Supplier Capacity Coordinator",
"description": "Verifies supplier ability to meet demand, negotiates delivery schedules, and identifies alternate suppliers when primary sources cannot fulfill requirements.",
"tags": ["suppliers", "procurement", "capacity-planning"],
"examples": [
"Check if suppliers can fulfill 10,000 additional units of WIDGET-A100 by September",
"{\"product_id\": \"WIDGET-A100\", \"quantity\": 10000, \"needed_by\": \"2024-09-15\"}"
],
"inputModes": ["application/json"],
"outputModes": ["application/json"]
}
]
}Sending a Request
Once discovered, the Sales Forecasting Agent initiates communication via A2A using JSON-RPC 2.0 over HTTPS. For example, it might send a method call to request inventory optimization as below.
{
"jsonrpc": "2.0",
"method": "messages/send",
"params": {
"message": {
"role": "user",
"content": {
"parts": [{
"data": {
"skill": "inventory-optimizer",
"products": [
{
"id": "WIDGET-A100",
"predicted_demand": 15000,
"confidence": 0.85,
"current_inventory": 5000
}
],
"time_period": "2024-Q4"
}
}]
}
}
},
"id": "req-12345"
}This message is encapsulated in an A2A Message Object that includes the role and parts that contain the actual content.
Getting a Response
If the supply check is quick, the Supply Chain Planning Agent responds directly with:
{
"jsonrpc": "2.0",
"result": {
"message": {
"role": "agent",
"content": {
"parts": [{
"data": {
"status": "success",
"adjustments": [{
"product_id": "WIDGET-A100",
"action": "increase_order",
"quantity": 10000,
"supplier": "ABC Manufacturing",
"delivery_date": "2024-09-15"
}]
}
}]
}
}
},
"id": "req-12345"
}Handling Long-Running Operations
What if the Supply Chain Planning Agent needs to coordinate with multiple suppliers, check global inventory, and run optimization algorithms? This could take minutes or hours. The Sales Forecasting Agent can't simply wait for one request.
This is where the task object becomes essential. A task represents a job the agent needs to complete. So, when the Sales Forecasting Agent sends its initial request, the Supply Chain Planning Agent immediately responds:
{
"jsonrpc": "2.0",
"result": {
"task": {
"id": "task-supply-adjust-789",
"status": "working",
"created_at": "2024-08-01T10:30:00Z",
"description": "Optimizing supply chain for Q4 demand forecast",
"estimated_completion": "2024-08-01T11:00:00Z"
}
},
"id": "req-12345"
}The Sales Forecasting Agent now has the task ID and can periodically check status by calling the tasks/get method:
{
"jsonrpc": "2.0",
"method": "tasks/get",
"params": {
"task_id": "task-supply-adjust-789"
},
"id": "req-12346"
}Eventually, the task completes with the full supply chain optimization plan:
{
"jsonrpc": "2.0",
"result": {
"task": {
"id": "task-789",
"status": "completed",
"artifacts": [{
"type": "supply_plan",
"content": {
"product_id": "WIDGET-A100",
"orders": [{
"supplier": "ABC Manufacturing",
"quantity": 10000,
"cost": "$45,000",
"delivery": "2024-09-15"
}],
"warehouse": "Northeast DC - Expanded capacity"
}
}]
}
},
"id": "req-12346"
}Real-Time Updates with Streaming
Polling works, but it’s not efficient for real-time coordination. If the Supply Chain Planning Agent's card indicates streaming support, the Sales Forecasting Agent can use the messages/stream method:
{
"jsonrpc": "2.0",
"method": "messages/stream",
"params": {
"message": {
"content": {
"parts": [{
"data": {
"skill": "inventory-optimizer",
"products": [{
"id": "WIDGET-A100",
"predicted_demand": 15000
}]
}
}]
}
}
},
"id": "req-12347"
}The HTTP connection remains open, and the Supply Chain Planning Agent pushes updates as Server-Sent Events.
Through A2A, these agents from completely different systems work together seamlessly. The sales team's AI-driven forecasts automatically trigger supply chain optimizations, preventing stockouts during peak demand while minimizing excess inventory. This integration happens without human intervention, API development, or manual data transfers, just two specialized agents speaking the same language to solve a critical business problem.
The Architectural Limits of A2A for Enterprise-Scale AI Agent Communication
While the A2A protocol effectively handles semantic interoperability between AI agents, it overlooks the deeper challenge. The protocol treats agent interaction as a simple API integration problem rather than the complex distributed systems challenge it actually is.
By relying on HTTP and gRPC, A2A inherits all the limitations of direct point-to-point architectures. While this may work in small, isolated systems, it becomes brittle, complex, and unsustainable in large-scale, enterprise environments where AI agents span CRMs, ERPs, support tools, and external APIs.
Let's examine six critical challenges that emerge when attempting to scale A2A beyond proof-of-concept deployments.
1. The N-Squared Connectivity Problem
A2A and similar protocols like IBM’s ACP introduce tight coupling between agents through direct HTTP connections. The most immediate problem with this model is the quadratic scaling of complexity, otherwise known as O(n²). Which means that, as the number of agents increases, the number of required connections grows quadratically. In a system with 4 agents, you need 6 bidirectional connections; with 50 agents, that number balloons to over 1,200. Each connection must be configured, maintained, and secured.
This N-squared growth in complexity makes scaling nearly impossible and introduces significant operational overhead. Even when using Server-Sent Events (SSE) for communication, the architecture remains fundamentally point-to-point and one-directional, leading to brittle topologies and duplicated effort for bidirectional interaction.
2. Tightly Coupled Architecture
Direct agent-to-agent connections create rigid dependencies that break modern development practices. Each agent must know the exact endpoint, authentication method, and availability status of every peer it might interact with. When an agent updates its interface, moves to a new server, or experiences downtime, every dependent agent requires reconfiguration. This tight coupling prevents the flexibility and resilience enterprises need for onboarding, managing, and scaling their AI agent networks.
AI Agent outputs should flow seamlessly into multiple consumers, including other AI Agents, analytics systems, and operational platforms. Instead of enabling dynamic, adaptable agent networks, A2A locks organizations into fragile architectures difficult to manage and where a single change can cascade into system-wide failures.
3. Orchestration Complexity
A2A allows agents to discover one another through Agent Cards, but it stops there. It provides no mechanism for coordinating when and how agents should interact. For example, when should agents communicate? How do you enforce permission boundaries between agents? What prevents circular dependencies or infinite loops? How does the system choose between multiple agents offering similar capabilities?
Without built-in orchestration primitives, developers must build custom workflow engines, control planes, or state machines, solutions that add complexity, introduce new failure modes, and aren’t interoperable across environments. A2A becomes a thin protocol layer requiring heavy infrastructure scaffolding to be usable at scale.
4. The State Management Challenge
HTTP's stateless nature fundamentally conflicts with the reality of AI agent interactions. Consider a supply chain optimization that unfolds over hours or days, with multiple agents contributing analysis, awaiting approvals, and coordinating with external systems. HTTP connections timeout, clients disconnect, and the state is lost. There is no inherent mechanism for durable state management, resumable conversations, or persistent messaging.
Developers must construct elaborate state management systems, typically involving databases and custom correlation logic, just to handle basic conversation continuity that message-oriented protocols provide natively.
5. The User Interaction Challenge
Modern AI systems must deliver results not only to other AI Agents, but back to users, wherever they are. A user might initiate a task through a web interface but expect to receive the result via email, Slack, or WhatsApp. In A2A's RPC-style architecture, responses can only return through the original request path. If the browser is closed or the session has expired, the response vanishes.
This approach doesn't match real-world user behavior. Supporting multi-channel delivery in A2A requires complex custom routing logic embedded in each agent, an unscalable nightmare as agent ecosystems and user expectations grow.
6. Security Boundaries Across Agent Chains
Perhaps the most challenging aspect of A2A's point-to-point model is maintaining security context across agent delegations. When a user with limited permissions initiates a request that flows through multiple agents, each link in the chain must preserve and respect those original constraints.
This requires proof of the original requester's identity, their permission scope, the specific authorized operation, and which agents can participate in the workflow. Without centralized policy enforcement, each agent becomes responsible for complex authorization logic. In practice, this leads to either overly permissive systems that leak sensitive data or overly restrictive systems that block legitimate operations.
These challenges reveal a fundamental architectural mismatch. A2A attempts to solve a distributed systems problem with tools designed for simple client-server interactions. Enterprise agent ecosystems need capabilities that HTTP/RPC simply cannot provide: automatic flow control, message persistence for reliability, publish-subscribe patterns for flexibility, resilient coordination, and unified observability across complex agentic workflows.
Next Steps: Adopt the Right Architecture
To move beyond the limitations of A2A’s tightly coupled, point-to-point model, we need an event-driven architecture. In this model, agents don’t call each other directly. Instead, they publish their outputs to a shared event backbone (message broker) and subscribe only to the data they need. It enables scalable, decoupled communication and supports standardization for seamless agent interoperability. MQTT is a natural fit for this, offering the flexibility and reliability needed at enterprise scale.
Curious to understand why event-driven design matters, why MQTT is the right foundation, and why standardization is essential for building interoperable agent ecosystems? Stay tuned for Part 2 of this blog series, The Benefits of Event-Driven Architecture for AI Agent Communication, or download the whitepaper.
Kudzai Manditereza
Kudzai is a tech influencer and electronic engineer based in Germany. As a Sr. Industry Solutions Advocate at HiveMQ, he helps developers and architects adopt MQTT, Unified Namespace (UNS), IIoT solutions, and HiveMQ for their IIoT projects. Kudzai runs a popular YouTube channel focused on IIoT and Smart Manufacturing technologies and he has been recognized as one of the Top 100 global influencers talking about Industry 4.0 online.
