Google Cloud gave Agent Runtime immutable versions and percentage-based routing

Google Cloud added immutable revisions and percentage-based traffic splitting to Agent Runtime by July 6th, enabling developers to release new agent code without replacing the running engine, resource name, or endpoint. The feature, resurfaced Monday in a Google Cloud Tech post on X, allows teams to route a percentage of live traffic to new agent versions for measurable production experiments, with older revisions remaining available until deprecated or deleted.

Google Cloud added immutable revisions and percentage-based traffic splitting to Agent Runtime https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime by July 6th, giving developers a way to release new agent code without replacing the running engine, resource name or endpoint. The feature resurfaced Monday in a Google Cloud Tech post on X https://x.com/GoogleCloudTech/status/2084355726630158626 , nearly a month after Dani Zamora published a technical walkthrough https://discuss.google.dev/t/revisions-and-traffic-splitting-on-agent-runtime/378489 . The timing matters because Google is positioning its managed agent infrastructure for workloads that need the release controls already standard in conventional cloud applications. Google's implementation creates an immutable snapshot whenever a developer changes a versioned field. Those fields include packaged code, dependencies, Python versions, environment variables, scaling limits, container concurrency, identity configuration and agent cards. Older revisions remain available until they are deprecated or deleted. The endpoint stays fixed while traffic moves between the revisions behind it. Developers can direct all requests to the newest version or configure a manual percentage split, provided the allocations add up to 100%. A team could send 10% of requests to new code, compare its behavior with the existing release, increase the share gradually and roll traffic back without creating another deployment. That mechanism turns agent updates into measurable production experiments. Agent behavior can change materially when a team swaps models, rewrites instructions, adds tools or changes orchestration code. A stable endpoint and concurrent revisions allow developers to compare latency, task completion, tool failures and user preferences on live traffic instead of making an immediate fleet-wide replacement. A release system built around agent state Agent Runtime, previously called Agent Engine, packages agent code into containers while Google Cloud handles infrastructure including managed sessions, memory, scaling, code execution, identity, observability and private networking. Revisions extend that managed layer into software delivery. Zamora's example deployed two versions of a research agent to the same engine. The first used Google Search to produce a quick briefing. The second started a slower Deep Research job and returned a handle for retrieving the report. Zamora then split traffic between the two versions while keeping one URL. In a dozen test requests using a 50-50 configuration, seven reached the faster version and five started the deeper research process. The small sample does not establish performance, but it demonstrates the routing model: distinct agent implementations can run simultaneously behind one production resource. Google published the accompanying code in an open-source demonstration repository https://github.com/danielazamorah/agentic-research-revisions-demo , including scripts for creating an engine, updating it with a revision, listing revisions and changing traffic allocations through the Vertex AI SDK. The walkthrough also exposes a capacity constraint developers will need to budget for. Manual traffic splitting keeps every targeted revision warm. Zamora's first attempt failed because the deployment allowed only one instance, leaving no capacity for the second revision. Increasing the instance range resolved the failure. That means safer rollouts can require additional running capacity during the test period. Traffic settings themselves are unversioned. Changing a split reroutes requests across existing revisions without shipping code or producing another snapshot. Google also warns developers to deprecate or delete old revisions so they do not consume quotas or remain accessible with stale code and potential security problems. Google is still testing the interface Google labels revisions and traffic splitting https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/manage-revisions-and-traffic as a Preview feature governed by its pre-GA terms. The controls are available through the v1beta1 API, which means field names, behavior and support commitments can still change. Zamora also noted that the command-line deployment tool did not yet directly expose traffic splitting, requiring the Vertex AI SDK for the demonstration. The addition places Google deeper into a cloud-platform contest over who operates production agents after developers finish a prototype. Amazon Bedrock AgentCore https://aws.amazon.com/blogs/aws/introducing-amazon-bedrock-agentcore-securely-deploy-and-operate-ai-agents-at-any-scale/ provides a managed runtime with isolated user sessions, while Microsoft Foundry Agent Service https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents runs containerized agent code with managed scaling, session persistence, identity and observability. Revision controls are less visible than a new model release, but they address the operational work that determines whether an agent can survive production use. Google Cloud is giving teams a controlled path to patch agent code, test competing behaviors and reverse failed releases while preserving the endpoint and stateful infrastructure around the workload.