Building Multi-Agent AI Systems: What Google's Lab Reveals

Google engineers Annie Wang and Ayo Adedeji recently walked developers through building a multi-agent system from scratch. The hour-long tutorial uses an RPG game metaphor—complete with a promised "boss fight"—to explain concepts that remain murky in most enterprise AI discussions. What emerges is less a sales pitch than a technical blueprint for how these systems actually work.

The architecture they present operates in three layers. At the bottom sits the tooling layer, where MCP (Model Context Protocol) servers act as universal adapters between agents and external resources. The middle layer contains domain-specific workflow agents, each handling sequential, parallel, or looped tasks. At the top, an orchestrator agent routes work between the specialized agents below it.

This isn't theoretical. The lab requires actual Google Cloud configuration—enabling APIs, setting permissions, deploying containers to Cloud Run. The setup alone occupies the first twenty minutes of instruction.

Why MCP Servers Matter

The Model Context Protocol represents Google's bet on standardization in agent tooling. Wang explains it plainly: "MCP server is like this universal adapter. So whatever tools you're connecting to... that MCP server wrap this tool can basically connect into any type of agent no matter it's ADK or with a different agent framework on different cloud."

The comparison to electrical adapters holds. Different agent frameworks—ADK, LangChain, others—can plug into the same MCP server without custom integration code. This matters because the alternative is brittle: every new tool requires framework-specific wrapper code, multiplying maintenance burden.

The tutorial demonstrates three MCP server types. One wraps external APIs, another implements general functions (the example is a calculator for mathematical operations that language models handle poorly), and a third connects to databases through what Google calls "data toolbox." Adedeji notes: "While these agents may be powered by something like Gemini which is really powerful and really good for multi-step reasoning, it doesn't have access to real world information."

That gap—between what models know and what they can do—drives the entire architecture.

The Development Environment

Google chose Cloud Shell as the development environment, described by Wang as "basically like VS code on cloud." The choice carries implications. Cloud Shell is a remote VM with persistent storage, meaning developers can stop work and resume days later without losing state. It also means Google controls the runtime environment completely.

The lab requires enabling multiple Google Cloud APIs: SQL Admin, Storage, AI Platform, Cloud Build. Adedeji addresses the obvious concern: "One question that comes up often is when you enable APIs, are you going to start incurring cost? Just by enabling APIs does not mean you're going to have a cost in your project. Essentially just makes sure that these services are available for use."

This matters because cloud billing anxiety runs high among developers testing new architectures. The tutorial includes scripts for redeeming free credits, but the billing model remains consumption-based. Scale the multi-agent system and costs scale with it.

Agent Workflow Types

The middle architecture layer—domain workflow agents—comes in three flavors. Sequential agents execute tasks in order. Parallel agents handle multiple tasks simultaneously. Loop agents repeat operations until conditions are met.

This taxonomy addresses a practical problem: different workflows require different orchestration patterns. A data pipeline might need sequential processing. A monitoring system might benefit from parallel execution. A convergence algorithm requires loops.

The tutorial doesn't explain when to choose which pattern. That's left as an exercise for developers, which seems reasonable. The choice depends on specific use cases Google can't anticipate.

What the lab does provide is working code for each type. Developers clone two GitHub repositories—one containing the multi-agent system template, another containing the "dungeon" environment for the boss fight. The separation suggests Google expects developers to modify the agent code while leaving the test environment unchanged.

What's Missing

The first hour covers setup and MCP servers but stops before agent-to-agent communication. That's reserved for part two, which promises coverage of the A2A (agent-to-agent) protocol. Adedeji teases it: "Agent-to-agent protocol... is a really good way of connecting agents with remote agents, kind of going across organizational boundaries."

This matters more than it might appear. Multi-agent systems within a single organization face different constraints than agents communicating across organizational boundaries. Authentication, authorization, rate limiting, data residency—all become harder problems when agents cross trust boundaries.

The tutorial also doesn't address failure modes. What happens when an MCP server times out? How do you debug an orchestrator agent making poor routing decisions? When should parallel agents fail fast versus retry?

These aren't oversights. Hour-long tutorials have limits. But they're the questions that separate working demos from production systems.

The RPG Metaphor

Google's choice to frame this as an RPG game—summoning agents, fighting bosses—reads as an attempt to make infrastructure patterns more approachable. Whether it succeeds depends on the audience. Developers comfortable with distributed systems might find the metaphor unnecessary. Those newer to agent architectures might appreciate the narrative structure.

What the metaphor obscures is cost. The "boss fight" runs on Cloud Run, which bills by request and compute time. A game metaphor makes it easy to forget you're deploying containerized services that meter usage.

The tutorial requires a personal Gmail account specifically to avoid corporate or educational restrictions. Wang emphasizes this twice. The implication: institutional accounts often block the API access required. This positions the lab as a learning resource, not an enterprise deployment guide.

What Developers Actually Get

By the end of part one, developers who follow along have: configured a Google Cloud project, enabled necessary APIs, deployed a containerized application to Cloud Run, cloned template code for multi-agent systems, and begun implementing MCP servers.

That's more than most vendor tutorials deliver. The code works. The architecture is explained. The pattern is repeatable.

What developers don't yet have: agent-to-agent communication, state management details, memory implementation, or production deployment guidance. Those come in part two, or don't come at all.

The tutorial represents Google's current thinking on multi-agent architecture. Whether that thinking proves durable depends on factors the tutorial doesn't address—cost at scale, debugging complexity, failure recovery patterns. The lab shows how to build the system. It doesn't yet show whether you should.

Bob Reynolds is Senior Technology Correspondent for Buzzrag.