Book TOC · Previous · Chapter 5 of 8 · Next

Chapter 5: Multi-Agent Topologies & Agentic Protocols (MCP vs. A2A)

Subsections Covered: 3.3 (2 Considerations · 4 Custom Visual Diagrams)

Chapter Focus: Distinguishing MCP (agent-to-tool) from A2A (agent-to-agent), Agent Cards, asynchronous long-running task lifecycles, and coordinating Sequential, Parallel, Router, and Cyclic Graph multi-agent handoffs.

Chapter 5 covers Subsection 3.3: how multiple agents and tools communicate across an enterprise. Instead of building one giant 'god agent' with 60 tools that gets confused and runs out of context, production architectures split work across smaller specialist agents coordinated via Agent2Agent (A2A), Model Context Protocol (MCP), and ADK workflow topologies.

Subsection 3.3: Orchestrating and Coordinating Agentic Workflows

Section 3: Developing Custom Agents

The Big Picture

The two most important questions in multi-agent design are: (1) Which protocol should I use—MCP or A2A? and (2) Which workflow topology matches my task dependencies—Sequential, Parallel, Router, or Cyclic Graph? Understanding these two decisions provides a clear foundation for designing multi-agent topologies in Subsection 3.3.

Consideration 3.3a: Orchestrating Agents Using Agentic Protocols (MCP and Agent2Agent [A2A])

A common architectural mistake is confusing Model Context Protocol (MCP) with Agent2Agent (A2A). Here is the simple rule to tell them apart:

MCP vs. A2A: Which Protocol Do You Need?

• Model Context Protocol (MCP — Agent-to-Tool / North–South):
• Use MCP when an agent needs to interact with a deterministic tool, database query, API, or read-only file/resource.
• The MCP server exposes a strict JSON Schema (tools/list, tools/call, resources/read) over local stdio or remote HTTP/SSE (Streamable HTTP).
• If you need to pass multi-tenant metadata or authentication tokens to an external MCP server, configure them in the MCP client's HTTP transport headers—never inside the LLM text prompt!
• Agent2Agent (A2A — Agent-to-Agent / East–West):
• Use A2A when a coordinating agent needs to delegate an open-ended goal to another autonomous reasoning agent (which may be built in a different framework or owned by another team).
• Every A2A agent publishes a machine-readable Agent Card (in Agent Registry or at /.well-known/agent.json) describing its skills, input/output modalities, and authentication requirements.
• Peer agents do not expose their internal prompts, memory, or tool implementations to each other—they collaborate by exchanging structured A2A tasks and artifacts.

Handling Long-Running Tasks Asynchronously in A2A

• What happens when an orchestrator agent delegates a deep research or compliance audit job to a specialist A2A agent that takes 45 minutes to finish?
• Never hold a synchronous HTTP connection open for 45 minutes—load balancers and gateways will time out and drop the connection.
• Instead, use A2A's asynchronous task pattern:
• The orchestrator submits the task and immediately receives a task_id with status WORKING / SUBMITTED.
• The orchestrator releases the connection (or suspends its session state).
• When the specialist agent finishes 45 minutes later, it publishes a completion event via Cloud Pub/Sub or a push notification webhook so the orchestrator can resume and deliver the final result.

Key Takeaways (3.3a)

• Connect an agent to a stateless REST API or SQL query → Use MCP (never wrap a simple SQL query in an A2A agent).
• Delegate a goal across two independent autonomous agents → Use A2A with Agent Cards registered in Agent Registry.
• Sub-agent task takes 30+ minutes → Use Asynchronous A2A (return task_id immediately + notify via Pub/Sub or webhook).

Consideration 3.3b: Selecting and Coordinating Multi-Agent Handoffs and Workflows (Parallel, Sequential, and Graph Workflows)

When designing multi-agent workflows in ADK and Agent Runtime, always choose the topology that matches how your subtasks depend on each other:

Choosing the Right Multi-Agent Topology

1. Parallel (Scatter-Gather / ParallelAgent):
2. When to use: You have 3 or more subtasks that do not depend on each other's outputs (for example, researching a company's financials, news sentiment, and patent filings simultaneously) and you need to minimize total latency and token accumulation.
3. How it works: Fan out all subtasks concurrently with isolated prompts, then merge their structured summaries in a synthesizer step.
4. Sequential (Pipeline / SequentialAgent):
5. When to use: Strict stage-by-stage dependency where Step 2 requires the output of Step 1 (for example: Extract invoice fields → Validate against PO database → Schedule payment).
6. Router / Coordinator (Dynamic Dispatch):
7. When to use: An incoming request needs to be classified and routed to one specific specialist sub-agent (such as routing a legal claim either to a ComplianceSubAgent or a StandardClaimsSubAgent).
8. Cyclic Graph / Loop (Generator–Critic / LoopAgent):
9. When to use: Iterative refinement—such as Write code → Run unit tests & security critic → Fix errors until tests pass.
10. Mandatory Guardrail: Always enforce a hard maximum iteration count (max_iterations) and termination condition so two agents cannot argue in an infinite loop and burn through your token budget!

Passing State & Enforcing Least Privilege Across Handoffs

• Shared Session State & The Claim-Check Pattern (gs:// URIs):
• Within an ADK workflow, sub-agents share small structured variables using the shared session.state context object (avoiding redundant database lookups).
• However, if Agent A generates a 25MB PDF report or high-res image for Agent B, never stuff raw megabyte blobs into session.state or the LLM prompt. Save the file to Cloud Storage and pass only the lightweight gs://bucket/file.pdf URI in session.state (the Claim-Check pattern).
• Per-Agent Least Privilege (Agent Identity + Agent Policies):
• In a sequential handoff (Triage Agent → Compliance Agent → Payment Agent), don't give all three agents the same super-admin service account. Assign each specialist its own Agent Identity so only the Payment Agent has permission to call the payment API.

Key Takeaways (3.3b)

• Independent subtasks + reduce latency/token bloat → ParallelAgent (Scatter-Gather).
• Iterative code review or draft-critique loop → Cyclic Graph / LoopAgent with a strict max_iterations cap.
• Share small variables between ADK sub-agents → Use session.state; share large files → Pass Cloud Storage (gs://) URIs.

Quick Decision Cheat Sheet (Subsection 3.3)

Further Reading (Subsection 3.3)

• Agent2Agent (A2A) Protocol Specification — Open protocol for peer-to-peer autonomous agent discovery (Agent Cards) and asynchronous task handoffs.
• Model Context Protocol (MCP) Overview — Standardized protocol for connecting AI agents to data resources and deterministic tools.

Book TOC · Previous · Chapter 5 of 8 · Next