Professional Agentic Architect — Architectural Takeaways

Book TOC · Previous · Chapter 5 of 8 · Next

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

Official Exam Guide Subsections Consolidated: 3.3

Chapter Consolidation Telemetry: Synthesizes 28 architectural scenarios across 1 Exam Subsections and 2 Official Considerations into consolidated takeaway pillars, paired with 1 Reference Architecture Mermaid Diagrams and 6 Curated Visual Illustrations.

Chapter Focus: MCP (agent-to-tool) vs. A2A (agent-to-agent), Agent Cards, asynchronous task lifecycles, and Hierarchical/Swarm/Supervisor handoffs.

Subsection `3.3`: Designing multi-agent systems using agentic protocols

Section 3: Designing and Building Production-Grade Custom Agents (33%) · 2 Official Considerations · 28 Scenarios Consolidated

Domain Overview and Reference Architecture

The Monolithic Agent Wall vs. The Distributed Agent Mesh

A single "God Agent" equipped with 40 tools and a 12,000-word system prompt inevitably collapses in production: it confuses similar tool schemas, hallucinates intermediate steps, and burns massive input token budgets on every turn. The solution is multi-agent decomposition—breaking complex workflows into specialized sub-agents coordinated through deterministic orchestration patterns and standardized communication protocols.

On the Google Cloud PAA exam, Section 3.3 tests two critical architectural competencies:

Protocol Selection (3.3a — MCP vs. A2A): Knowing when an agent is invoking a deterministic capability (Model Context Protocol — North-to-South) versus delegating a goal to an autonomous peer reasoning agent (Agent2Agent Protocol — East-to-West), and securing remote protocol transports with short-lived OAuth 2.0 / OIDC Bearer tokens.
Multi-Agent Orchestration & Handoffs (3.3b): Matching the execution graph (Sequential Pipeline, Parallel Scatter-Gather, Coordinator/Router, Hierarchical Supervisor, Iterative Cyclic Graph / Evaluator-Optimizer Loop, or Human-in-the-Loop Interrupt) to the exact data dependency, latency, and governance requirements using Agent Identity, Agent Registry, and Agent Runtime.

Exam Scope Covered in This Chapter

3.3a Orchestrating Agents Using Agentic Protocols (MCP and Agent2Agent [A2A]): Standardized MCP client-server architecture (Tools, Resources, Prompts), local stdio vs. remote SSE / Streamable HTTP transports, securing remote MCP endpoints with short-lived OAuth 2.0 / OIDC Bearer tokens, and peer-to-peer A2A task delegation across autonomous agents.
3.3b Selecting and Coordinating Multi-Agent Handoffs and Workflows: Designing Parallel (Scatter-Gather), Sequential, Hierarchical, and Cyclic Graph (Iterative Evaluator-Optimizer) workflows with bounded max_iterations and state checkpointing using Agent Identity, Agent Registry (Agent Cards), Agent Runtime, and agent policies.

Core Foundational Primitives & Mental Models (`Subsection 3.3`)

Workflow showing a lead agent delegating a task to a specialist agent across a protocol boundary. — Agent2Agent enables cross-framework task delegation by establishing a common protocol boundary.

Core Concept / Service	Winning Architectural Rule & Default Behavior	Common Exam Trap to Avoid
Agent2Agent (Services: `vertex_ai:agent_builder`, `vertex_ai:agents`)	Agent2Agent (A2A) provides a standardized framework and communication protocol for autonomous agents to interact, exchange context, and perform task handoffs.	GRPC Web enables browser clients to call gRPC backend services but is not an agent-to-agent collaboration protocol.
Parallel agents (Services: `vertex_ai:agent_builder`, `vertex_ai:generative_ai`)	Parallel agents run subtasks concurrently across separate subagents when tasks do not depend on one another.	Sequential agents execute tasks one after another in order, not simultaneously.
Sequential agents (Services: `vertex_ai:reasoning_engine`, `vertex_ai:agents`)	Sequential agents execute tasks linearly in a step-by-step pipeline where each agent consumes the output of the preceding agent.	An asynchronous mesh is a decentralized and event-driven pattern rather than a strict step-by-step linear workflow.
Graph workflow (Services: `vertex_ai:agent_builder`, `vertex_ai:generative_ai`)	Graph workflows represent agent interactions as nodes and edges, naturally supporting conditional branching and cyclic execution loops.	A circular buffer is a bounded data structure for streams and queue management, not an agent workflow topology.
Agent Runtime (Services: `vertex_ai:agent_builder`, `vertex_ai:agents`)	Agent Runtime is the dedicated managed compute environment for hosting and running custom agent logic within Google Cloud.	Cloud Deployment Manager automates resource provisioning through infrastructure as code, not agent code execution.
Agent2Agent (Services: `vertex_ai:agents`, `vertex_ai:agent_builder`)	Agent2Agent (A2A) enables interoperability and cross-framework capability discovery and task delegation among autonomous agents.	Modbus is a legacy industrial automation protocol.

Official Exam Considerations & Consolidated Takeaways (`Subsection 3.3`)

Consideration `3.3a`: Orchestrating agents using agentic protocols (e.g., mcp and agent2agent [a2a])

When solving scenarios on Model Context Protocol (MCP) vs. Agent2Agent (A2A):

MCP Is North–South (Agent → Deterministic Tool/Data): Use MCP whenever an agent needs to invoke a deterministic function (tools/call), query a database, or read URI-addressed contextual data (resources/read). Do not wrap stateless database queries or REST API calls inside an autonomous A2A agent.
A2A Is East–West (Agent ↔ Peer Reasoning Agent): Use A2A when a coordinating agent delegates an open-ended, multi-step goal to a specialized autonomous agent (potentially built in a different framework like LangGraph, CrewAI, or ADK, or run by another business unit) without exposing its internal prompts, memory, or private tools.
Transport & Authentication (stdio vs. HTTP/SSE): Local IDE tools use stdio subprocess pipes. Production cloud agents communicate with remote MCP servers and A2A peers over HTTPS (Streamable HTTP / SSE) authenticated via short-lived OAuth 2.0 or Google-signed OIDC Bearer tokens in the Authorization: Bearer <token> header—never static keys inside the JSON-RPC payload. For long-running A2A tasks, use SSE streaming or async push notification webhooks.

Scaling agent capabilities via MCP — Implementing MCP servers enables the seamless addition of new microservices to the agent ecosystem without requiring supervisor redeployment.

Diagram illustrating how the context envelope is passed persistently across multiple agent hops. — Propagating the context envelope through every hop ensures persistent access to conversation state.

Takeaway 1: Dynamic Tool Discovery via Remote MCP Server (`vertex_ai:agent_builder` · `cloud_run`)

Core Concept: Dynamic tool registration and discovery using standard Model Context Protocol (MCP) endpoints in a microservices architecture.
Scenario Trigger & Requirement: The question tests how to connect an orchestration supervisor agent to microservices dynamically. Key constraints include the need for dynamic discovery and execution of logistics tools without redeploying supervisor agent code or hardcoding OpenAPI specifications.
Winning Architecture & Implementation: Implement Model Context Protocol (MCP) servers on the Cloud Run services, and configure the supervisor agent as an MCP client that calls standard tool discovery endpoints. Model Context Protocol (MCP) provides an open standard for generative AI applications and agents to connect with data sources and tools.
Exam Traps to Reject: Using Cloud SQL creates custom overhead instead of leveraging standardized agent tool discovery protocols like MCP. Requiring redeployments via Cloud Functions contradicts the goal of dynamic runtime tool discovery without code changes.

Takeaway 2: Context and State Propagation in A2A Communication (`vertex_ai:agents` · `vertex_ai:reasoning_engine`)

Core Concept: Maintaining conversational state, task parameters, and execution history across multi-hop Agent2Agent (A2A) invocations.
Scenario Trigger & Requirement: A multi-tier agent architecture (Customer Care -> Mortgage Specialist -> Credit Risk) communicating via an Agent2Agent (A2A) protocol. The problem is that downstream agents fail to resolve conversational references (e.g., pronouns from earlier turns) due to loss of contextual history during delegation hops.
Winning Architecture & Implementation: Propagate a contextual session thread and execution state metadata within the standardized A2A message context envelope across each delegation hop. In multi-hop Agent2Agent (A2A) architectures, sub-agents often lack the context of prior user interactions if each agent forwards only an isolated sub-task prompt.
Exam Traps to Reject: Adjusting model hyperparameters cannot resolve missing data that was never sent in the request. Direct database lookups create tight coupling and bypass standardized A2A message envelopes.

Takeaway 3: Securing MCP Server Access via IAM and OAuth2 (`vertex_ai:agents` · `gke:networking` · `iam:service_accounts`)

Core Concept: Authentication, authorization, and zero-trust perimeter enforcement for remote MCP tool execution.
Scenario Trigger & Requirement: The scenario requires connecting custom Vertex AI agents to internal Model Context Protocol (MCP) tool servers hosted on Google Kubernetes Engine (GKE). Key requirements are verifying caller identity (authentication) and enforcing least privilege for private customer data access.
Winning Architecture & Implementation: Configure the agents to pass Google Cloud IAM OAuth 2.0 Bearer tokens in the MCP authorization headers, and validate the tokens at the GKE ingress gateway. Passing OAuth 2.0 Bearer tokens or Google Cloud Identity and Access Management (IAM) identity tokens within the standard Model Context Protocol (MCP) authorization request header provides cryptographically verified, short-lived authentication for remote tool execution.
Exam Traps to Reject: Network-level firewalls alone do not provide identity-based tool authorization or zero-trust security. Static API keys in system instructions can leak through prompt injection and violate zero-trust security standards.

Consolidated Golden Rules (Consideration 3.3a):

Use Model Context Protocol (MCP) servers and clients for dynamic, decoupled tool discovery and invocation across microservices.
MCP tool discovery allows agents to inspect schemas and capabilities at runtime, eliminating the need to hardcode definitions or redeploy agents when microservices change.
Avoid coupling agents to custom database lookup tables or static OpenAPI redeployment pipelines when standardized agent protocols are applicable.
In nested Agent2Agent (A2A) delegations, context loss occurs if only isolated sub-task prompts are forwarded.
Always include session thread history and execution state metadata in the standardized A2A message payload envelope.
Avoid out-of-band database polling from downstream agents to maintain decoupling and clean protocol boundaries.

Consideration `3.3b`: Selecting and coordinating multiagent handoffs and workflows (e.g., parallel agents, sequential agents, and graph workflow) using google cloud tools (e.g., agent identity, agent registry, agent runtime, and agent policies)

Match the orchestration topology and Google Cloud governance tools strictly to the scenario's signals:

1. Parallel (Scatter-Gather / ParallelAgent): Choose when multiple sub-agents perform independent analyses on the same input (e.g., checking Legal, Finance, and Security policies simultaneously) and you need to minimize end-to-end latency ($T_{\text{total}} \approx \max(T_i)$ instead of $\sum T_i$).
2. Sequential Pipeline (SequentialAgent): Choose when Stage $B$ strictly requires the transformed output of Stage $A$ (e.g., Extract Entities → Enrich from CRM → Draft Contract).
3. Cyclic Graph / Iterative Evaluator-Optimizer (LoopAgent): Choose when output must pass a strict quality rubric or compiler check (e.g., Generator Agent \rightleftharpoons Critic Agent). Mandatory production guardrails: Always configure a deterministic max_iterations cap (to prevent infinite loops and runaway token bills), a structured pass/fail exit condition, and state checkpointing.
4. Coordinating Handoffs with Google Cloud Tools: Discover peer capabilities dynamically via Agent Cards in Agent Registry, authenticate cross-agent calls using dedicated Agent Identities, host stateful orchestrators on Agent Runtime, and enforce handoff guardrails via agent policies.

Dynamic intent-based routing workflow from entry-point agent to specialist agent — The entry-point agent performs a runtime lookup in the routing registry to map user intent to the correct specialist endpoint.

Parallel Fan-Out Pattern diagram showing an orchestrator dispatching to multiple subtasks simultaneously. — The parallel fan-out pattern optimizes performance by executing independent subtasks concurrently.

Takeaway 1: Least Privilege Delegation Using Agent Identity in Sequential Handoffs (`vertex_ai:agents` · `iam:service_accounts`)

Core Concept: Securing cross-agent handoffs using individual Agent Identities and IAM scoping in sequential execution pipelines.
Scenario Trigger & Requirement: A multiagent system involving a customer-facing agent and a sensitive backend processing agent. The core requirement is enforcing least privilege during sequential handoff so that upstream agents do not hold direct permissions to sensitive databases or external payment APIs.
Winning Architecture & Implementation: Assign a separate service account with invocation permissions to the Customer Support Agent, assign a dedicated service account with Cloud SQL and payment secret access to the Refund Processing Agent, and coordinate the handoff in Agent Runtime. Assigning dedicated service accounts to individual agents adheres strictly to the principle of least privilege. In this architecture, the Customer Support Agent only holds permissions to receive requests and invoke the downstream agent.
Exam Traps to Reject: Shared service accounts violate least privilege, and system instructions cannot serve as secure access boundaries. Passing credentials within prompt parameters exposes sensitive data across agent boundaries and breaches security policies.

Takeaway 2: Parallel Multi-Agent Fan-Out with Vertex AI Agent Runtime Aggregation (`vertex_ai:agents` · `vertex_ai:agent_runtime` · `vertex_ai:orchestration`)

Core Concept: Orchestrating concurrent domain-specific agents and synthesizing results with deterministic latency constraints.
Scenario Trigger & Requirement: The scenario requires querying three independent specialist agents concurrently (flights, hotels, excursions) to optimize response latency. It also requires synthesizing the results and gracefully handling partial timeouts.
Winning Architecture & Implementation: Implement a parallel fan-out workflow in the agent orchestrator, execute specialist agent calls asynchronously, and apply fallback policies to aggregate available responses if an agent times out. A parallel fan-out and fan-in workflow allows an orchestrator agent to dispatch multiple requests to independent specialist agents (flights, hotels, excursions) at the same time.
Exam Traps to Reject: Sequential execution runs tasks one after another, which significantly increases total latency. A monolithic agent increases prompt complexity and fails to provide concurrent specialist orchestration.

Takeaway 3: Dynamic Capability-Based Routing via Centralized Agent Registry (`vertex_ai:agent_builder` · `cloud_run`)

Core Concept: Decoupling orchestration from agent endpoints by utilizing an Agent Registry with capability schemas and semantic search.
Scenario Trigger & Requirement: A multiagent enterprise architecture with dozens of agents distributed across multiple projects. The primary challenge is avoiding hardcoded URLs and brittle static routing logic while enabling dynamic discovery and handoff based on capabilities.
Winning Architecture & Implementation: Register each specialist agent in a centralized Agent Registry with capability schemas and descriptions, and configure the entry-point agent to query the registry to discover and resolve endpoints dynamically. A centralized Agent Registry stores agent metadata, capability contracts (such as OpenAPI specifications), and semantic descriptions.
Exam Traps to Reject: Cloud DNS works at the network layer and cannot evaluate semantic agent capabilities or intent. A shared static file still relies on hardcoded URLs and lacks runtime capability discovery.

Takeaway 4: Cyclic Graph Workflows for Iterative Code Review and Verification (`vertex_ai:agent_engine` · `vertex_ai:agents`)

Core Concept: Implementing cyclic graph-based agent topologies with conditional loops and shared state persistence.
Scenario Trigger & Requirement: The scenario requires an iterative code generation and review workflow where an output is produced, evaluated, and sent back with feedback up to three times. This requires a cyclic multiagent topology with dynamic condition evaluation, retry limits, and shared state persistence.
Winning Architecture & Implementation: Implement a cyclic graph workflow on Vertex AI Agent Engine with conditional routing edges, persistent state checkpointing, and an iteration counter. A cyclic graph workflow engine (such as LangGraph hosted within Vertex AI Agent Engine) allows agents to pass control and context back and forth iteratively based on runtime evaluation.
Exam Traps to Reject: Stateless message queues lack built-in graph state management and bounded loop termination safeguards. Linear pipelines cannot dynamically route contextual review feedback in a loop between collaborating agents.

Consolidated Golden Rules (Consideration 3.3b):

Isolate agent permissions by attaching unique service accounts to each agent in a multiagent workflow.
Enforce least privilege at the IAM layer rather than relying on prompt engineering or system instructions.
Keep database and secret access restricted exclusively to the downstream agents that directly perform specialized operations.
Use parallel fan-out/fan-in multi-agent workflows when tasks are independent and low latency is critical.
Use sequential workflows only when downstream agents strictly require outputs from upstream agents.
Implement fallback policies and asynchronous timeouts to ensure orchestrators return graceful partial responses during specialist failures.

Multi-Constraint Production Architecture Scenarios (`Subsection 3.3`)

Diagram illustrating the flow of sentiment-aware conversation orchestration from an automated agent to a human escalate agent. — Sentiment-aware orchestration allows the supervisor to route interaction based on real-time emotional analysis.

Production Scenario & Hard Constraints	Winning Google Cloud Architecture	Why Look-Alike Alternatives Fail
Multi-agent orchestration pattern that centrally classifies user intent and delegates: The scenario requires designing a customer support system with distinct functional domains (billing, technical support, shipping) using the Agent Development Kit (ADK).	Implement a router agent pattern that classifies user intent and delegates execution to specialized sub-agents. The router agent pattern centrally classifies incoming user intent and dispatches tasks to the appropriate specialized sub-agents.	A monolithic prompt degrades accuracy, increases prompt size, and creates maintenance bottlenecks across distinct departments. A sequential chain forces all requests through every agent, which adds latency and incurs unnecessary token expenses.
Multi-agent design pattern that executes independent sub-agent tasks concurrently: A scenario where an autonomous travel planning system must run two independent tasks—a flight search and a hotel search—at the exact same time. The primary constraint is minimizing user latency. To solve this, you need to identify the agent workflow pattern that supports simultaneous, non-blocking execution across specialized sub-agents.	Configure a parallel multi-agent pattern that triggers both sub-agents concurrently and aggregates their results. Concurrent execution of independent sub-agents minimizes latency by overlapping task durations and aggregating outputs.	Sequential execution forces tasks to run one after another, which increases overall user latency. Monolithic prompts reduce modularity, impair tool execution accuracy, and do not provide concurrent execution.
Standard protocol that enables peer-to-peer negotiation, delegation, and stateful: A scenario where two autonomous agents reside in separate Google Cloud projects. The primary objective is to facilitate peer negotiation, collaborative task execution, and structured task management while avoiding asymmetrical patterns that degrade an agent into a basic function call or external tool.	Implement the Agent-to-Agent (A2A) protocol to standardize task delegation, status reporting, and collaboration. The Agent-to-Agent (A2A) protocol establishes a standardized specification for autonomous agents to delegate tasks, report status, and negotiate peer-to-peer.	MCP treats endpoints as server-side tools or contextual data sources rather than collaborative, negotiating peer agents. A shared database table creates an anti-pattern of polling and shared state rather than an agent-to-agent communication protocol.
Multi-agent architecture pattern for delegating sub-tasks, monitoring worker progress: An enterprise scenario where multiple agents must collaborate under centralized control. Key requirements include: (1) an explicit coordinator agent, (2) assignment of sub-tasks to worker agents, (3) real-time or stateful progress monitoring, and (4) synthesis of final responses for end users.	Implement a hierarchical supervisor agent pattern with the Agent Development Kit (ADK). The hierarchical supervisor agent pattern designates a coordinator agent that manages sub-agent task assignment, monitors progress, and synthesizes the final user response.	A peer-to-peer gossip network lacks centralized coordination, monitoring, and synthesis capabilities. A single monolithic agent lacks modularity and contradicts the requirement for worker delegation and multi-agent coordination.
Proper workflow architecture for an autonomous agent requiring dynamic search iteration: The scenario requires an automated agent workflow that can assess intermediate search results and dynamically decide whether to execute another search iteration. The key architectural requirement is cyclic execution with conditional checks rather than a purely linear execution path.	Design a loop-based agent pattern with conditional exit criteria based on information sufficiency. A loop-based design pattern allows dynamic re-prompting and repeated tool execution until specific quality or exit criteria are satisfied.	Sequential chains run in a fixed sequence and cannot loop back when additional search information is required. Setting temperature to zero increases determinism; temperature does not enable iterative loops or broaden web search actions.
Expose capabilities as direct model/tool extensions through MCP versus orchestrating: The core of this question lies in distinguishing between tool-integration standards and agent-collaboration standards in modern generative artificial intelligence (AI) systems.	Expose the capability as an MCP tool because it provides direct tool access and context retrieval. MCP is built specifically for exposing tools, context, and external data interfaces directly to agents without autonomous agent overhead.	Dedicated supervisor agents introduce excessive latency and complexity for simple stateless tool executions. A2A protocols manage communication between autonomous reasoning agents, not passive stateless data lookup services.
Agentic workflow pattern that performs automated self-critique, verification, and output: The scenario requires an automated mechanism where an agent critiques its generated solution and checks factual consistency against ground-truth documentation before presenting the result to an end user. The core challenge involves reducing hallucinations and enforcing grounding through workflow orchestration.	Implement an agent self-correction and reflection step before finalizing the output response. Reflection and self-correction design patterns allow an agent to evaluate and revise candidate answers against grounding data before presenting the final answer.	Increasing top-p increases randomness and hallucinations rather than enforcing factual accuracy. Averaging tokens across duplicate models is technically impractical for discrete generation and does not perform factual grounding or critique.
Standard multi-agent orchestration design pattern that executes parallel agent tasks: The scenario specifies that a master agent must distribute a single customer request to three distinct domain agents (marketing, legal, compliance) simultaneously and then aggregate their feedback.	Implement a fan-out fan-in orchestration pattern across the worker agents. Fan-out fan-in distributes tasks in parallel to multiple specialized agents and collects their responses into an aggregated outcome.	Linear chains execute sequentially, increasing latency and violating the requirement to process reviews simultaneously. Monolithic prompts fail to maintain strict domain boundaries, degrade accuracy, and violate multi-agent design principles.
Agentic architectural pattern that inspects generated output against structural rules: The scenario requires producing a legal contract summary under strict structural constraints (exactly five sections). Crucially, the system must inspect the generated text for missing sections and initiate regeneration if any are absent.	Implement an evaluator-optimizer reflection loop pattern that checks section headers before delivering the final response. An evaluator-optimizer loop validates the presence of required structural sections and iteratively regenerates or refines missing content.	A single prompt cannot verify compliance or detect and regenerate omitted sections. Running independent models without orchestration creates disjointed summaries and lacks an omission-detection feedback loop.
Standard orchestration controls required to prevent and break infinite handoff cycles: An anti-pattern in multi-agent orchestration: two or more collaborative agents continuously hand tasks to one another in an infinite loop. Identifying orchestrator-level execution controls resolves cyclic routing without breaking agent modularity.	Configure maximum delegation depth limits and cycle detection logic in the ADK orchestrator. Configuring recursion limits and cycle detection stops infinite handoffs reliably within multi-agent orchestration frameworks.	Relying on quota limits leads to high financial costs and bad user experience. Deleting sub-agents compromises modular design and does not solve the root routing failure.
Multi-agent routing pattern that classifies natural language queries and delegates work: An architecture challenge in multi-agent systems: handling divergent user requests that require domain-specific logic (language translation, code quality, and security auditing).	Deploy an Agent Development Kit (ADK) router agent with semantic routing capabilities. A router agent with semantic routing accurately inspects user intent and delegates tasks to the appropriate specialist without running unnecessary agents.	Sequential execution wastes compute and tokens while introducing high latency for requests that only need one specialist. Merging prompts degrades accuracy, increases maintenance complexity, and negates the benefits of modular specialized agents.
Multi-agent design pattern that executes sequential, interdependent steps across: A scenario with three specialized roles: an architect agent, a coder agent, and a reviewer agent. Each agent depends on the artifact produced by the previous agent: specifications precede code, and code precedes code review. Recognizing this ordered, feed-forward flow reveals the core orchestration pattern.	Sequential pipeline multi-agent orchestration pattern. A sequential pipeline coordinates specialized agents in a linear order, where each agent processes output from the predecessor.	Randomized routing executes agents arbitrarily, which disrupts the required linear progression of software tasks. The design involves multiple distinct agents rather than a single agent handling the entire task without role specialization.
Multi-agent design pattern suitable for decomposing goals, maintaining checklists: The scenario requires an AI agent to autonomously break down an extensive research assignment into actionable sub-goals, maintain an explicit checklist, and iteratively execute and track progress. This requires a workflow pattern that supports structured task decomposition and dynamic state management.	Implement a Plan-and-Solve / Task Decomposition pattern in ADK with dynamic task list management. The Plan-and-Solve pattern decomposes complex goals into manageable sub-tasks and dynamically tracks checklist state throughout execution.	Single one-shot completion cannot track multi-step progress and often fails on complex tasks. Manual user execution contradicts the requirement for autonomous agent decomposition and execution.
Multi-agent design pattern that uses sentiment analysis within an orchestrator to route: An autonomous customer support workflow with multi-agent orchestration. Key parts to analyze: * autonomous customer support system: Indicates a multi-agent system where different components (triage, troubleshooting, escalation) handle specific tasks.	Implement dynamic sentiment-based routing in the ADK supervisor orchestrator. Dynamic sentiment-based routing inside the supervisor agent dynamically detects negative emotional cues and transfers the session to a human agent.	Continuing technical troubleshooting fails to de-escalate the situation and ignores the customer's emotional state. Terminating the session frustrates the customer further and fails to resolve the issue.
Standard remote transport layer specification defined by the Model Context Protocol: The scenario requires selecting the correct transport layer for a remote Model Context Protocol (MCP) server hosted on Cloud Run that serves distributed agents across different cloud projects over HTTP. The key identifiers are 'remote Model Context Protocol (MCP) server', 'Cloud Run', and 'connect ... over HTTP'.	Server-Sent Events (SSE) over HTTP transport layer for the remote MCP server. The MCP specification defines SSE over HTTP as the official standard transport layer for remote network connections.	Stdio transport operates strictly over local process pipes and cannot be accessed remotely across network boundaries. UDP is neither supported by the MCP specification nor an appropriate transport protocol for secure Cloud Run ingress.

Head-to-Head Architectural Trade-Off Clinic (`Subsection 3.3`)

Scenario / Architectural Requirement	Winning Protocol / Pattern	Common Exam Trap (Reject!)
Agent invokes a stateless Cloud SQL order lookup or Jira ticket API	Model Context Protocol (`MCP`) (`North–South` tool invocation)	Wrapping a simple database query inside an autonomous A2A peer agent (adds double LLM reasoning latency & cost).
Travel Orchestrator delegates itinerary planning to an external partner's Hotel Booking Agent built in LangGraph	Agent2Agent (`A2A`) Protocol + Agent Card discovery in Agent Registry	Forcing the external partner to expose internal prompts/state via MCP or sharing a single monolithic memory store.
Run 4 independent compliance checks (GDPR, HIPAA, PCI, SOC2) on a document under a strict 3-second SLA	Parallel (Scatter-Gather) Pattern (`ParallelAgent`)	Sequential Chaining (sums the latency of all 4 agents: $4 \times 2\text{s} = 8\text{s}$).
Ensure generated SQL or Python code compiles and passes all validation rules before returning to the user	Cyclic Graph / Iterative Evaluator-Optimizer (`LoopAgent`) with a strict `max_iterations` cap	Single-pass generation with a longer prompt, or an unbounded retry loop without a maximum iteration counter.
Wait 12 hours for a VP to approve a $50,000 wire transfer initiated by an agent	Checkpoint State to Firestore/Managed Sessions + Suspend Execution + Async Webhook Resume	Keeping the Cloud Run container or Agent Runtime thread alive with `time.sleep()` or long-polling.

Rapid Pattern-Trigger Cheat Sheet (`Subsection 3.3`)

If the Exam Scenario Mentions...	Choose This Architecture / Configuration	Reject This Common Distractor Trap
"Standardize how an agent connects to 10 internal databases and REST APIs"	Model Context Protocol (`MCP`) servers exposing `Tools` and `Resources`	Agent2Agent (`A2A`) protocol (A2A is for autonomous peer agents, not stateless tools)
"Collaborate across autonomous agents built by different teams/frameworks without exposing internal state"	Agent2Agent (`A2A`) protocol using Agent Cards in Agent Registry	Sharing a single global prompt or using MCP `stdio` pipes across microservices
"Authenticate an agent calling a remote MCP server on Cloud Run"	Short-lived OAuth 2.0 / OIDC Bearer token in the HTTP `Authorization` header	Embedding static API keys in the MCP JSON-RPC body or opening `--allow-unauthenticated`
"Generator and Critic agents occasionally get stuck arguing forever, spiking token bills"	Enforce a hard `max_iterations` limit on the cyclic graph / `LoopAgent` + fallback escalation	Increasing context window size or lowering model temperature
"Independent subtasks executing one after another are violating P95 latency targets"	Refactor from Sequential to Parallel (Scatter-Gather) orchestration	Upgrading all sub-agents to a larger foundation model

Curated Official Google Cloud Documentation (`Subsection 3.3`)

Vertex AI Agent Builder Overview — Provides architectural guidelines and tools for building enterprise-ready autonomous agents and multi-agent workflows.
Multi-agent systems in Vertex AI — Details how agents collaborate, route queries, and handle task handoffs within Google Cloud.
Vertex AI Agent Builder Overview — Provides architectural and functional details regarding building, managing, and running custom agents within Vertex AI.
Model Context Protocol Documentation — Provides architectural guidelines and protocol specifications for connecting AI models and agents to external tools and data sources dynamically.
Multi-agent orchestration patterns — Explains best practices for passing context, state, and delegation envelopes across agent networks.
Model Context Protocol Documentation — Provides architectural guidelines for client-server protocol communication and tool integration.
Google Cloud IAM Workload Identity Overview — Details how applications running on GKE authenticate securely to Google Cloud services using IAM service accounts.
Google Cloud Service Accounts Overview — Explains service account principles, identity management, and how to apply least privilege across decoupled workloads.
Choose a design pattern for your AI agent — Compares agent design patterns, including parallel multi-agent execution and result aggregation approaches.
Multi-agent System Architecture Patterns — Explains design patterns for coordinating autonomous and semi-autonomous multi-agent workflows.
Build Multi-Agent Systems on Vertex AI — Covers design patterns for multi-agent workflows including routing, parallel execution, and sequential orchestration with Gemini models.
The Agent-to-Agent (A2A) Protocol Specification — Covers the open specification for standardized task delegation, lifecycle management, and communication across distinct agent platforms.

Book TOC · Previous · Chapter 5 of 8 · Next

AwesomeGCP.com Learning

The approach taken is a question-led learning approach: you explore realistic project scenarios where you need to make decisions or take actions to achieve business goals within specific constraints. Instead of passive learning, you are challenged to think and work through the options to master the Professional Agentic Architect (PAA) certification!

Practice PAA Questions

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

Subsection 3.3: Designing multi-agent systems using agentic protocols

Domain Overview and Reference Architecture

The Monolithic Agent Wall vs. The Distributed Agent Mesh

Exam Scope Covered in This Chapter

Core Foundational Primitives & Mental Models (Subsection 3.3)

Official Exam Considerations & Consolidated Takeaways (Subsection 3.3)

Consideration 3.3a: Orchestrating agents using agentic protocols (e.g., mcp and agent2agent [a2a])

Takeaway 1: Dynamic Tool Discovery via Remote MCP Server (vertex_ai:agent_builder · cloud_run)

Takeaway 2: Context and State Propagation in A2A Communication (vertex_ai:agents · vertex_ai:reasoning_engine)

Takeaway 3: Securing MCP Server Access via IAM and OAuth2 (vertex_ai:agents · gke:networking · iam:service_accounts)

Consideration 3.3b: Selecting and coordinating multiagent handoffs and workflows (e.g., parallel agents, sequential agents, and graph workflow) using google cloud tools (e.g., agent identity, agent registry, agent runtime, and agent policies)

Takeaway 1: Least Privilege Delegation Using Agent Identity in Sequential Handoffs (vertex_ai:agents · iam:service_accounts)

Takeaway 2: Parallel Multi-Agent Fan-Out with Vertex AI Agent Runtime Aggregation (vertex_ai:agents · vertex_ai:agent_runtime · vertex_ai:orchestration)

Takeaway 3: Dynamic Capability-Based Routing via Centralized Agent Registry (vertex_ai:agent_builder · cloud_run)

Takeaway 4: Cyclic Graph Workflows for Iterative Code Review and Verification (vertex_ai:agent_engine · vertex_ai:agents)

Multi-Constraint Production Architecture Scenarios (Subsection 3.3)

Head-to-Head Architectural Trade-Off Clinic (Subsection 3.3)

Rapid Pattern-Trigger Cheat Sheet (Subsection 3.3)

Curated Official Google Cloud Documentation (Subsection 3.3)