Google Cloud dotó a Agent Runtime de versiones inmutables y enrutamiento basado en porcentajes.

Why it matters

Agent deployments need the same rollback and canary-release controls as other production software. Google is building those controls into its managed runtime, with Preview-stage limits and added capacity costs.

Google Cloud añadió revisiones inmutables y división porcentual del tráfico a Agent Runtime para el 6 de julio, dando a los desarrolladores una forma de publicar nuevo código de agente sin reemplazar el motor en ejecución, el nombre del recurso o el endpoint.

La función reapareció el lunes en una publicación de Google Cloud Tech en X, casi un mes después de que Dani Zamora publicara un recorrido técnico. El momento importa porque Google está posicionando su infraestructura de agentes gestionada para cargas de trabajo que necesitan los controles de lanzamiento que ya son estándar en las aplicaciones convencionales en la nube.

La implementación de Google crea una instantánea inmutable cada vez que un desarrollador cambia un campo versionado. Esos campos incluyen código empaquetado, dependencias, versiones de Python, variables de entorno, límites de escalado, concurrencia de contenedores, configuración de identidad y tarjetas de agente. Las revisiones antiguas permanecen disponibles hasta que se marcan como obsoletas o se eliminan.

El endpoint permanece fijo mientras el tráfico se mueve entre las revisiones detrás de él. Los desarrolladores pueden dirigir todas las solicitudes a la versión más reciente o configurar una división porcentual manual, siempre que las asignaciones sumen 100%. Un equipo podría enviar el 10% de las solicitudes al código nuevo, comparar su comportamiento con la versión existente, aumentar la proporción gradualmente y revertir el tráfico sin crear otro despliegue.

Ese mecanismo convierte las actualizaciones de agentes en experimentos de producción medibles. El comportamiento del agente puede cambiar de manera significativa cuando un equipo intercambia modelos, reescribe instrucciones, agrega herramientas o cambia el código de orquestación. Un endpoint estable y revisiones concurrentes permiten a los desarrolladores comparar latencia, finalización de tareas, fallas de herramientas y preferencias de usuarios con tráfico en vivo en lugar de hacer un reemplazo inmediato en toda la flota.

Un sistema de lanzamiento construido alrededor del estado del agente

Agent Runtime, anteriormente llamado Agent Engine, empaqueta el código del agente en contenedores mientras Google Cloud maneja la infraestructura, incluidas sesiones gestionadas, memoria, escalado, ejecución de código, identidad, observabilidad y redes privadas. Las revisiones extienden esa capa gestionada hacia la entrega de software.

El ejemplo de Zamora desplegó dos versiones de un agente de investigación en el mismo engine. La primera usó Google Search para producir un informe rápido. La segunda inició un trabajo de Deep Research más lento y devolvió un identificador para recuperar el informe. Zamora luego dividió el tráfico entre las dos versiones mientras mantenía una sola URL.

En una docena de solicitudes de prueba usando una configuración 50-50, siete llegaron a la versión más rápida y cinco iniciaron el proceso de investigación más profundo. La muestra pequeña no establece rendimiento, pero demuestra el modelo de enrutamiento: implementaciones de agentes distintas pueden ejecutarse simultáneamente detrás de un mismo recurso en producción.

Google publicó el código acompañante en un repositorio de demostración de código abierto, incluidos scripts para crear un engine, actualizarlo con una revisión, listar revisiones y cambiar las asignaciones de tráfico mediante el Vertex AI SDK.

El recorrido también expone una limitación de capacidad que los desarrolladores tendrán que presupuestar. La división manual del tráfico mantiene cada revisión objetivo activa. El primer intento de Zamora falló porque el despliegue permitía solo una instancia, lo que no dejó capacidad para la segunda revisión. Aumentar el rango de instancias resolvió la falla. Eso significa que los lanzamientos más seguros pueden requerir capacidad adicional en ejecución durante el periodo de prueba.

Las configuraciones de tráfico en sí no están versionadas. Cambiar una división redirige las solicitudes entre las revisiones existentes sin enviar código ni producir otra instantánea. Google también advierte a los desarrolladores que marquen como obsoletas o eliminen las revisiones antiguas para que no consuman cuotas ni sigan siendo accesibles con código obsoleto y posibles problemas de seguridad.

Google aún está probando la interfaz

Google etiqueta revisiones y división del tráfico como una función Preview regida por sus términos pre-GA. Los controles están disponibles a través de la API v1beta1, lo que significa que los nombres de campos, el comportamiento y los compromisos de soporte aún pueden cambiar. Zamora también señaló que la herramienta de despliegue desde la línea de comandos aún no exponía directamente la división del tráfico, requiriendo el Vertex AI SDK para la demostración.

La adición sitúa a Google más dentro de la competencia de plataformas en la nube sobre quién opera agentes en producción después de que los desarrolladores terminan un prototipo. Amazon Bedrock AgentCore ofrece un runtime gestionado con sesiones de usuario aisladas, mientras que Microsoft Foundry Agent Service ejecuta código de agente en contenedores con escalado gestionado, persistencia de sesiones, identidad y observabilidad.

Los controles de revisión son menos visibles que un nuevo lanzamiento de modelo, pero abordan el trabajo operativo que determina si un agente puede sobrevivir en uso de producción. Google Cloud está dando a los equipos un camino controlado para parchear el código del agente, probar comportamientos en competencia y revertir lanzamientos fallidos mientras preserva el endpoint y la infraestructura con estado alrededor de la carga de trabajo.