A production multi-agent system is an orchestration system

Google Cloud’s reference architecture places a coordinator between the user-facing frontend and specialised subagents. The coordinator selects an agentic flow based on intent rather than asking every agent to participate in every request.

The example combines sequential execution with iterative refinement. A quality evaluator can reject an intermediate result, a prompt-enhancing step can modify the next attempt, and a maximum iteration count bounds the cycle. A response generator then performs validation and grounding checks before the result returns through the coordinator.

The architecture uses Agent2Agent (A2A) for communication between agents and Model Context Protocol (MCP) for access to tools such as databases, file systems and APIs. Treating those as separate contracts improves clarity: one boundary is about delegation and interoperability between actors; the other is about invoking external capabilities.

This separation also makes security review more precise. An agent that may delegate a task does not automatically need direct credentials for every tool used by the delegated agent.

The source shows agents running on serverless Cloud Run, GKE or Agent Runtime on Gemini Enterprise Agent Platform. Those are not interchangeable labels; they represent different operational envelopes around scaling, container control, networking and platform-managed capabilities.

Production design should use the least complex runtime that satisfies execution, isolation and networking requirements. Model serving is another decision again, and the reference architecture allows model runtime choices to be separated from agent runtime choices.

The security guidance combines deterministic controls with agent-specific safeguards. Each agent should receive only the IAM permissions it needs to perform its role and communicate with required tools or peers. Business-critical flows should include a human path that can review, override or pause the system.

Input and response inspection, careful autonomy boundaries and tool-level access control are more useful than treating the model itself as the security boundary.

Multi-agent failures are distributed failures. A final bad answer may originate in routing, a tool call, an intermediate observation, evaluator logic or model output. Comprehensive traces need to make the execution path inspectable across those boundaries.

Reliability therefore depends on bounded retries, idempotent operations where applicable, explicit failure states and a record of which agent called which capability with what result. Without that evidence, debugging becomes reconstruction.

More agents and more refinement cycles increase model calls. Region selection, model choice, prompt length, context reuse and runtime allocation affect both cost and latency. The reference guidance recommends testing models iteratively and beginning with cost-efficient options rather than defaulting every task to the most capable model.

A production system should measure quality per unit of latency and cost at the workflow level. Individual agent benchmark scores do not describe the performance of the composed system.

Primary source: Google Cloud Architecture Center, “Multi-agent AI system”. Canonical source: https://docs.cloud.google.com/architecture/multiagent-ai-system . Source capture reviewed 7 August 2026.

This note preserves the source architecture’s coordinator, sequential and iterative-refinement flow, A2A/MCP separation, human-in-the-loop path and security/reliability/cost considerations, while expressing them as implementation principles rather than a Google Cloud deployment recipe.