A2A Protocol and Multi-Agent Systems — When AI Agents Talk to Each Other

Why Do We Need Multi-Agent Systems?

A typical AI agent does one thing well: responds to customers, analyzes emails, or generates tasks. But in business reality, tasks are not isolated — handling an incoming email may require 6 distinct steps: email interpretation, customer identification, appointment search, booking, confirmation email, revenue prediction update.

If a single "super-agent" does all of this, it becomes too complex, doesn't scale, and is nearly impossible to debug. The solution: specialized agents that collaborate — just as microservices revolutionized backend development.

AI Monolith	Multi-Agent System
One "all-knowing" agent	Specialized agents
One system prompt for everything	Agent-specific prompts
"Why did it say that?" — hard to answer	Agent-level audit trail
Token limit = ceiling	Agent-level resource management

---

Two Protocols, Two Levels

Two open standards are shaping AI agent communication:

A2A (Agent-to-Agent) — Google's 2025 open protocol for inter-agent communication. Every agent publishes an "Agent Card" (JSON) describing its capabilities, endpoint, and authentication — similar to an OpenAPI spec. An unknown agent can reach another: it reads the Agent Card, understands its capabilities, and sends a request in a standardized format.

MCP (Model Context Protocol) — Anthropic's standard for the connection between agents and external tools. MCP tools (Gmail, Calendar, CRM) register dynamically — when a provider enables the Gmail connector, the agent automatically "learns" that it can send emails.

	MCP	A2A
What it connects	Agent ↔ Tool	Agent ↔ Agent
Analogy	USB cable	TCP/IP network
Example	Gmail tool, Calendar tool	CRM agent → Email agent

Using both together is where the real power lies: agents coordinate via A2A, and reach external tools via MCP.

---

The Evaluator-Executor Pattern

Production multi-agent systems often implement logical agent roles within a single system:

• Evaluator Agent (the "brain"): LLM-based with low temperature (T=0.3), returns structured JSON. Operates in two modes: event mode (incoming email, webhook → decision), and scheduled mode (proactive suggestions every 15 minutes: overdue tasks, stale deals, upcoming birthdays).

• Executor Agent (the "hand"): Deterministic code that carries out the Evaluator's decisions — 8 action types (create_task, send_email, create_event, etc.), each with precisely defined inputs.

• Chat Agent (the "voice"): The agent that speaks directly with users. Uses a different model (GPT-4o, Claude, Gemini), higher temperature (T=0.7), and tool calling.

Between them stands the Autonomy Gate — three-level control:

• notify_only: Log only, no execution
• suggest_and_wait: 24-hour approval window
• act_and_report: Automatic execution + logging

---

Security Controls

In a multi-agent system, cascade failure risk grows exponentially: if the Evaluator decides incorrectly, the Executor sends the wrong email. The defense layers:

Control	Effect
Daily limit (max 50 actions)	Prevents a "runaway" agent
Max 3 actions per evaluation	Limited scope of impact
Action filtering (allowed/blocked)	Granular permissions
Full audit trail	Post-mortem analysis, optimization
24-hour approval window	Human oversight

---

When Do You Need Multi-Agent vs. A2A?

Multi-agent architecture is needed when: the system prompt > 5,000 tokens and growing; the agent uses > 10 tools; different tasks require different LLM configurations; tasks naturally separate (chat vs. background analysis).

A2A protocol is needed when: agents run at different organizations; you want to integrate a third party's agent. If the system is closed and internal, shared state (DB + Queue) is sufficient.

The future vision for A2A: cross-business scenarios where one company's AI agent directly communicates with another's — for example, a medical AI assistant booking an appointment with a salon's AI, or an inventory agent automatically ordering from a supplier.

---