Agentverse - The Summoner's Concord - Architecting Multi-Agent Systems
Architect a Multi-Agent System on Google Cloud — The Summoner's Concord
Most people building with AI are still thinking in terms of a single agent. One prompt, one model, one response. That's fine for demos. It doesn't survive contact with real problems.
Real systems are composed. They delegate. They coordinate. They enforce rules. They remember. This session is about building exactly that — a fully orchestrated, multi-agent system deployed on Google Cloud, where agents talk to other agents, enforce their own policies, and adapt based on what just happened.
Here's what you actually build.
You start by designing the tooling layer — not by stuffing tools into an agent, but by building independent MCP (Model Context Protocol) servers that agents can discover and call remotely. One server wraps an external API with custom Python logic. Another exposes a PostgreSQL database through a declarative YAML config. No hardcoded function calls. No spaghetti. Each tool server is its own deployed microservice, and any agent in the system can use it. This is the architectural foundation that makes the whole thing scale.
Then you build the agents. Three of them, each with a fundamentally different operational strategy. The Fire Elemental runs Sequential — step one feeds step two, strict ordering, clear dependency chain. The Water Elemental runs Parallel — three simultaneous attacks fan out at once, results fan back in, combined into a final strike. The Earth Elemental runs on a Loop — repeatedly accumulating energy across iterations until a condition is met. These aren't arbitrary patterns. They map directly to how you'd model invoice processing pipelines, customer onboarding workflows, or campaign optimization loops in production.
Then you wire them into an orchestrator. The Summoner Agent doesn't know the other agents' code. It discovers them at runtime by fetching their Agent Cards — machine-readable service contracts published via the A2A protocol. It reads what each agent can do, decides who should handle the incoming request, and delegates. This is service discovery for AI. You update a Familiar, redeploy it, and the Summoner just picks up the new capabilities automatically. No hardcoded routing logic.
Then you make the system stateful. You implement the Interceptor pattern — first as a callback on a single agent, then refactored into a Plugin that attaches at the runtime level and applies to every agent universally. The plugin enforces a cooldown rule: each agent has a recovery period tracked via an external API. If you try to call a Familiar that's still cooling down, the interceptor fires before any LLM call is made and returns an explicit block. This is how you enforce real business policy in an agentic system without stuffing rules into a prompt and hoping.
Finally, you give the orchestrator memory. An after_tool_callback fires every time a Familiar is successfully invoked, writing the Familiar's name into session state. The Summoner can now see its own history mid-conversation and adapt — if the ideal agent was just used, it picks the next best available one instead of repeating itself. That's the difference between a tool-caller and a strategic reasoner.
Everything deploys to Cloud Run. Every component — the MCP servers, the three Familiars, the Summoner orchestrator — is an independent containerized service. Live URLs, real traffic, real architecture.
Why this matters right now.
The industry is racing toward multi-agent systems and most of the content being produced about them is conceptual. Architecture diagrams. Blog posts. Framework comparisons. Very little of it is "here is the exact code, here is the deployment, here is the running system."
This session is the running system. You leave with a working A2A-compliant multi-agent deployment, a concrete mental model of how workflow patterns map to agent behavior, and direct experience with the two hardest parts of building agentic systems at scale: enforcing rules without hardcoding them, and making agents that actually remember what they just did.
Who this is for.
You don't need to be a distributed systems engineer. You need to be curious about how agent systems are actually assembled — not theoretically, but structurally. If you've built a single agent and wondered "how do I make this work with five agents working together" — this is that answer, built step by step.
What you leave with.
A deployed multi-agent orchestration system. A concrete understanding of MCP, A2A, ADK workflow patterns, the Interceptor pattern, and short-term agent state. And the specific architectural vocabulary to go design these systems yourself.
The era of the single agent is ending. Come build what comes next.
Host Community
This event is hosted by Orca AI Club in collaboration with Amrita Vishwa Vidyapeetham, Faridabad, supported by Google Developer Groups.
🎁 Note: Attendees will receive $5 in Google Cloud credits upon joining the session, which can be used to follow along with the hands-on codelab directly on Google Cloud — no setup cost, no barriers.