1,000 agentes de IA en una maratón: qué nos enseña la arquitectura de Google Cloud sobre sistemas multi-agente a escala
Imagina que tienes que coordinar a mil personas al mismo tiempo, cada una tomando decisiones independientes, moviéndose a distintas velocidades, con distintos niveles de energía — y necesitas saber el estado de todas ellas en menos de 10 segundos. Eso, en esencia, es lo que Google Cloud construyó con su proyecto Race Condition: una simulación de 1,000 corredores de maratón, cada uno representado por un agente de IA independiente, corriendo virtualmente por Las Vegas en tiempo real.
Lo interesante no es el espectáculo visual del demo — aunque es llamativo. Lo interesante es la arquitectura que lo hace posible, los errores que cometieron en el camino, y los patrones de diseño que surgieron de esa experiencia. Porque esos patrones son directamente aplicables a cualquier sistema empresarial que necesite coordinar múltiples procesos autónomos a escala.
En este artículo vamos a desmenuzar cómo funciona Race Condition, qué decisiones arquitectónicas fueron clave, y qué pueden aprender de esto las empresas y equipos de tecnología en Perú y América Latina que están empezando a explorar sistemas multi-agente.
La arquitectura polyglot: la herramienta correcta para cada trabajo
Race Condition está construido sobre cuatro capas: un frontend en Angular, un gateway en Go, una red de agentes Python con ADK (Agent Development Kit de Google), y la infraestructura que los sostiene — principalmente Cloud Run, Redis (Cloud Memorystore) y Pub/Sub.
La pregunta obvia es: ¿por qué mezclar Go y Python en lugar de usar un solo lenguaje? La respuesta de Casey West, quien lideró el desarrollo, es directa: cada herramienta hace algo mejor que la otra. Go fue elegido para el gateway porque maneja miles de conexiones WebSocket simultáneas sin degradar el rendimiento — es lo que se llama un "traffic cop" de alta concurrencia. Python, en cambio, es donde vive toda la inteligencia artificial: el ecosistema de herramientas LLM, ADK, y la lógica de los agentes es mucho más madura y rica en Python.
Esta separación no es capricho de ingeniería. Es lo que permite que mil agentes estén "pensando" al mismo tiempo sin que el sistema se sienta lento. El gateway en Go absorbe toda la comunicación en tiempo real mientras Python se ocupa de la lógica compleja. Para equipos de desarrollo, esto significa que pueden aislar la lógica de agentes en módulos Python limpios, mientras Go maneja el peso de la comunicación.
El insight más valioso: no todos los agentes necesitan la misma infraestructura
Aquí está el hallazgo que más me parece transferible a proyectos reales. El equipo empezó haciendo lo que cualquier arquitecto haría: comunicación HTTP estándar entre todos los agentes siguiendo el protocolo A2A (agent-to-agent). Funcionó — hasta que intentaron escalar a 1,000 sesiones simultáneas con respuestas requeridas en menos de 10 segundos.
El problema fue la red. Con HTTP, cada mensaje tiene overhead de conexión. Multiplicado por mil agentes recibiendo actualizaciones simultáneas en cada "tick" de la simulación, la latencia acumulada hacía imposible cumplir el requisito de velocidad. La red se convertía en el cuello de botella, no los agentes.
La solución fue distinguir dos tipos de agentes con necesidades radicalmente distintas. Los agentes "doers" — los corredores — necesitan responder en sub-milisegundos a miles de actualizaciones simultáneas. Para ellos, implementaron un modo subscriber basado en Redis pub/sub: el agente simulador publica un mensaje de "tick" y todos los corredores despiertan al mismo tiempo, sin latencia HTTP, procesando el mensaje en paralelo. Cloud Memorystore (Redis administrado de Google) puede manejar aproximadamente 100,000 mensajes concurrentes en un solo nodo — mucho más de lo necesario.
Los agentes "thinkers" — el planner, el simulator — trabajan de forma diferente. No necesitan esa velocidad. Solo actúan cuando se les llama, esperan una solicitud HTTP, hacen su trabajo, y vuelven a dormir. Pueden escalar a cero cuando no se usan. Para ellos, HTTP estándar es perfectamente suficiente y más económico.
Esta distinción entre agentes de alta frecuencia y agentes de baja frecuencia es un patrón de diseño que vale la pena interiorizar. Aplicar la misma infraestructura a todos los agentes porque es más simple de implementar puede costar caro en rendimiento y en dinero.
¿Cómo aplica esto en empresas de Perú y América Latina?
Los sistemas multi-agente todavía están en etapa de adopción temprana en la región, pero los principios arquitectónicos de Race Condition son relevantes ahora mismo para cualquier empresa que esté construyendo o evaluando automatizaciones con IA.
Pensemos en casos concretos. Una empresa de logística que coordina rutas de reparto en tiempo real tiene el mismo problema que los corredores de maratón: muchos agentes tomando decisiones independientes que necesitan sincronizarse rápidamente. Una plataforma de e-commerce que gestiona inventario, precios y recomendaciones simultáneamente necesita distinguir qué procesos son de alta frecuencia (actualización de stock en tiempo real) y cuáles son de baja frecuencia (generación de reportes). Un sistema de atención al cliente con múltiples agentes especializados necesita un gateway que distribuya las conversaciones eficientemente.
Lo que enseña Race Condition es que la arquitectura de comunicación entre agentes importa tanto como la inteligencia de los agentes mismos. Puedes tener los mejores modelos LLM del mercado, pero si tu infraestructura de mensajería no está diseñada para tu caso de uso, el sistema fallará bajo carga real.
En la región, muchos proyectos de IA empiezan con arquitecturas que funcionan bien en pruebas con 10 o 20 usuarios concurrentes, y luego se rompen cuando llegan a producción real. El enfoque iterativo de Casey West — empezar con lo simple, identificar el cuello de botella real bajo carga, y optimizar solo donde es necesario — es exactamente la mentalidad correcta para equipos con recursos limitados.
¿Cómo aplica esto en tu empresa?
Si estás evaluando o construyendo sistemas con múltiples agentes de IA, estos son los pasos concretos que se desprenden de la experiencia de Race Condition:
- Clasifica tus agentes antes de diseñar la infraestructura. Identifica cuáles necesitan responder en milisegundos (alta frecuencia, alta concurrencia) y cuáles pueden trabajar de forma asíncrona ocasional. No uses la misma infraestructura para ambos.
- Empieza con HTTP estándar. No sobre-ingenierices desde el inicio. HTTP es suficiente para la mayoría de casos. Solo migra a pub/sub o eventos cuando tengas evidencia de que la latencia de red es tu cuello de botella real.
- Usa herramientas especializadas para cada capa. Si necesitas alta concurrencia en comunicación, considera Go o Node.js para el gateway. Si necesitas ecosistema de IA, Python con ADK o LangChain. No fuerces un solo lenguaje donde no encaja.
- Mide bajo carga real. Race Condition descubrió su problema solo cuando intentó escalar a 1,000 sesiones simultáneas. Haz pruebas de carga que simulen tu escenario real antes de ir a producción.
- Considera Redis pub/sub para coordinación de alta frecuencia. Cloud Memorystore en GCP, ElastiCache en AWS, o Azure Cache for Redis son servicios administrados que eliminan la complejidad operativa de Redis y escalan fácilmente.
El proyecto Race Condition es open source y está disponible para explorar. Si tienes un equipo técnico, revisar el código y la documentación es un ejercicio valioso para entender cómo se ve un sistema multi-agente bien diseñado en la práctica.
Conclusión
Race Condition demuestra algo importante: los sistemas multi-agente a escala no son magia — son ingeniería de software bien aplicada, con decisiones deliberadas sobre qué herramienta usar para qué problema. La distinción entre agentes "doers" y agentes "thinkers", el uso de Redis pub/sub para comunicación de alta frecuencia, y la arquitectura polyglot con Go y Python son patrones que pueden reutilizarse en proyectos empresariales reales.
En Consultoría-Ti trabajamos con empresas en Perú y América Latina que están dando sus primeros pasos en automatización con IA y sistemas multi-agente. Si estás evaluando cómo escalar tus procesos con inteligencia artificial o quieres entender qué arquitectura tiene sentido para tu caso específico, conversemos.
Escríbenos y con gusto revisamos tu caso sin compromiso.
Fuentes y Referencias
Google Cloud Tech — How we built 1,000 AI agents that run a marathon (YouTube)
✨ Contenido generado con ContentFlow — Consultoría-Ti