Explore a high-scale agentic AI-powered simulation sandbox with Gemini Enterprise Agent Platform

Hi, I'm Tom Greenaway. And I'm Casey West. And we're lead developer advocates at Google Cloud. Casey, have you ever run a marathon? Absolutely not. I'm a backpacker and I'll happily hike hundreds of miles, but the longest I've ever run is 10K and honestly that was enough for me. Well, it is a massive undertaking, but I imagine actually planning a certified marathon is even harder. You have governing bodies with strict core standards, city logistics, road closures, and medical tent placements. Exactly. And if you get one variable wrong, the whole thing can fall apart. And this complexity is exactly why we built Race Condition. Race Condition is a deployable reference architecture for orchestrating, scaling, and securing autonomous AI agents using Gemini Enterprise Agent Platform. And it is fully open source. It's a multi-agent simulation that models a marathon through Las Vegas, where we hosted Google Cloud Next this year. And we created this developer solution alongside Race Condition to help you explore the system's architecture, the demo experiences, and inspect the code directly. Tom, I know you built some great games over the years, so your expertise was super important to the user experience. And for this project, you oversaw building the front-end visualization using TypeScript, 3.js, and Google's Angular framework. And my background is in platform engineering and distributed systems, so I led the back end and infrastructure. Yeah, thanks Casey. I I think the 3D front-end and the back-end system have come together really well. And today, we're not just going to show you a cool simulation, we're going to show you how the patterns we use to simulate thousands of runners translate directly to the enterprise cloud architectures you are building right now. So, let's get nerdy. The back end is a polyglot by design. We have Go lang handling high concurrency infrastructure and web socket messaging, while Python hosts the AI ecosystem, which we built with Gemini Enterprise Agent Platform. Hey Casey, what is Gemini Enterprise Agent Platform exactly? That's a great question, Tom. Gemini Enterprise Agent Platform is a collection of platform services like agent runtime, where we run our agents, agent registry to allow them to connect to one another, protocols like A2A, frameworks like Agent Development Kit, and standards like A2UI. And I know that was a lot of acronyms, but we will explain all of this right now. Well, sounds handy. Okay, now let's look back at the front-end itself. When we need to plan a route, we prompt our planner agent. And for it to make good decisions, it needs real-world context. So, we use Google Cloud's MCP service to connect the agent to services like Google Maps, allowing it to pull live weather and traffic data to anticipate the event's impact on the city. But one agent can't run a whole city event. You need a team. And traditional enterprise software microservices often talk to each other through rigid, hard-coded REST APIs. On the other hand, AI agents can make decisions when they have the right context. So Tom, how do agents collaborate when their needs are constantly shifting? Well, in our case, we use the A2A or agent-to-agent protocol. And instead of static APIs, we use the Gemini Enterprise Agent Platform's agent registry, where every agent publishes an agent card detailing its skills and capabilities. Okay, so when the planner agent designs a route, it doesn't simulate the race itself. It needs to delegate to the simulator agent. It doesn't call hard-coded endpoint. It queries the agent registry to discover the simulator dynamically. It's essentially a real-time context mesh for your agents. Yeah, think about this for a supply chain application, for example. You could have an inventory agent dynamically discover and negotiate with a logistics agent to reroute shipping containers during a storm, completely autonomously, without a developer writing a custom integration. That makes sense and that can be very flexible. So, once the agents agree on a plan, they need to show it to us. Usually, AI spits out walls and walls of text and that isn't really helpful in an enterprise context. Right. To fix that, we use the A2UI or agent-to-user interface protocol. Instead of raw markdown, the agent generates structured component trees and then the front-end renders those native components dynamically. It's an open standard for AI-generated UI. And in our case, we render that generated UI with Angular. This completely changes human-in-the-loop workflows. So, imagine a fintech application. An agent is investigating a loan application and it doesn't just give you a summary, it can dynamically render a custom dashboard showing a knowledge graph of the applicant's risk factors, and complete that interactive uh system with an approval button for a loan officer. And to make these workflows useful, the agents need to remember what they're doing. So, we use the Gemini Enterprise Agent Platform's session store to keep track of the immediate active conversation state. And for deeper context, we connected the agents to LODB and Memory Bank. LODB allows the agents to ingest and search on structured information like Las Vegas laws and regulations with automatic embeddings for vector search. Meanwhile, Memory Bank allows the agents to remember important details and context over time. And that can bridge the gap across multiple different simulation runs. Casey, how about we run the simulation itself? Let's do it. It's really pretty. Okay, so now the simulation is running. And as we can now see, we have a thousand independent runner agents moving concurrently through the city. Managing that much state across the network usually causes bottlenecks. And keeping the back end and the front end in sync is a really common problem. Tom, this is where your game development background really saved the architecture. Yeah, that's true. In games, it's always important to decide where the authority of the game state is managed. For us, the back end is really holding the authoritative state, but the front end's runners still calculate their local position based on known velocity, a classic dead reckoning design pattern in multiplayer games. And some events that are more spatial in the world, such as the runners reaching a water station, originate their events from the front end and send them back up to the back end, so the user experience stays as smooth as possible. I loved seeing how the game development concepts map perfectly to modern agentic architectures. Using Agent Development Kit or ADK as our agentic framework made it simple to build a game loop with the loop agent workflow. Agent registry made it easy for the front end to communicate water and cheering events directly to the runner agents. Yeah, this allowed us to implement a massive fan-out architecture. One simulation agent session can communicate with thousands of individual runner agent sessions instantly, completely bypassing the overhead of HTTP. For our customers, this is the exact blueprint for handling high-volume transaction processing in domains like online retail or ingesting millions of telemetry events from an IoT fleet at scale. But building at this scale means things do occasionally break. During development, our simulation crashed because the agents generated too much data, exceeding their token limits. Yeah, debugging a distributed multi-agent system is tough, but we have AI developer tools now to help. And we integrated Google Cloud Assist directly into our developer environments. For example, we experiment with using harnesses like anti-gravity and Claude code. So, Google Cloud Assist autonomously investigated the crash, identified the token limit bottleneck, and even suggested a context compaction patch to fix it, right in the IDE. It's incredible to have an AI operated debugging your AI agents. And finally, we know security is always an important consideration. What stops a compromised agent from going rogue and exposing customer data, Casey? Well, we use a shift-down security model. So, general-purpose service accounts are really dangerous here. Instead, every agent is assigned a unique, immutable agent identity. We enforce strict IAM policies down at the platform layer within Agent Gateway. So, even if an agent is tricked by a prompt injection into trying to alter a financial database, our policies block that unauthorized API execution at the network level. It gives CISOs peace of mind that their AI is operating within a zero-trust architecture. Race Condition is a high-scale sandbox designed to push the boundaries of what's possible, but you don't need a massive budget to try it out. Yeah, in the developer solution, you'll explore several demos that each showcase a different configuration of the planner agent, ranging from a planner using Google Maps data for traffic and weather to one that adds real-time LLM evaluation, A2A and A2UI, and lastly one that includes long-term memory. And you can also leverage Google Kubernetes Engine to deploy fleets of compute with open weight Gemma models included to simulate individual agentic brains for the runners. But the best experience, of course, is to get the sandbox running in your hands yourself. The entire code base is open source. We want you to check out the GitHub repo, fork it, break it apart. You'll find links to the code, Agent Development Kit, and the protocol specifications down below. So, download the code to deploy a lightweight version of this exact architecture to your own Google Cloud project. We've even included a link for some free Google Cloud credits, giving you enough credits to spin this up and test the A2A and A2UI protocols yourself. So, that's Race Condition, a high-scale agentic AI-powered simulation sandbox. What problems will you solve next? Let's get started.