Vertex AI Agent Builder

The URL in our listing, cloud.google.com/products/agent-builder, no longer resolves to a page of its own — it redirects to cloud.google.com/products/gemini-enterprise-agent-platform, whose page metadata reads "Gemini Enterprise Agent Platform (formerly Vertex AI)". Google's own framing in the launch post is that the platform is "the evolution of Vertex AI, bringing the model selection, model building, and agent building capabilities that customers love, together with new features for agent integration, DevOps, orchestration, and security." The announcement post is dated 22 April 2026 and says "today, we're launching", but it does not state an explicit GA date, so we do not publish one.

The more useful distinction for a buyer is that Google now sells two adjacent things with confusingly similar names. Gemini Enterprise app (cloud.google.com/gemini-enterprise) is the seat-licensed product for employees to discover and run agents. Gemini Enterprise Agent Platform — the thing this listing covers, and the thing the old Agent Builder URL points at — is the developer platform, and its pricing page carries no seat component at all: every line is consumption-based. Per-seat figures circulating in third-party write-ups (commonly $21 and $30 per user per month) describe the app, not this platform. We could not verify those seat prices against a Google page: cloud.google.com/gemini-enterprise/pricing currently returns a 404.

If you are an existing Vertex AI customer, note this is a platform-level renaming rather than a new SKU you must migrate onto — but treat any claim about API endpoints or migration requirements as unverified; we did not confirm those.

This is the strongest thing about the product and the reason it deserves consideration even if you are not a Google Cloud shop. The Agent Development Kit is Apache-2.0 licensed and genuinely active: google/adk-python carries 21,100 stars and 3,828 forks, with commits pushed on 14 August 2026 — the day we checked. The companion Agent2Agent protocol repo (a2aproject/A2A) has 25,339 stars, also Apache-2.0, and Google donated it to the Linux Foundation, where it is now governed by a Technical Steering Committee including AWS, Cisco, IBM Research, Microsoft, Salesforce, SAP and ServiceNow. A protocol under neutral governance is a meaningfully different proposition from a vendor's house standard.

Portability is documented rather than implied. ADK's deployment guide lists Agent Runtime, Cloud Run and GKE, and then adds a fourth option in plain terms: you can package the agent into a container image and "run it in any environment that supports container images. For example you can run it locally in Docker or Podman. This is a good option if you prefer to run offline or disconnected, or otherwise in a system that has no connection to Google Cloud." That sentence is unusual candour for a cloud vendor's own docs, and it is the answer to the obvious lock-in question about the framework layer.

"Model-agnostic" is a claim most agent frameworks make and few honour past their preferred provider. ADK's own model documentation lists two integration paths. Direct registry access covers Gemini, Claude models, and models hosted on Agent Platform endpoints. Separately, model connectors cover "models outside the Google ecosystem", with documented pages for LiteLLM, Ollama, vLLM, Apigee and LiteRT-LM.

Ollama and vLLM matter more than the list length suggests: both are self-hosted inference paths, so the documented configuration is not merely "another vendor's API" but "a model you run yourself." Combined with the offline container deployment above, an ADK agent running entirely on your own hardware against your own weights is a configuration Google documents rather than tolerates.

The platform's pricing has been restructured, and anyone working from an older write-up will be reading the wrong model. The term "Agent Engine" no longer appears anywhere on the pricing page. Everything now normalises to three metered units, and this is a cleaner design than most competitors offer:

• Agent Compute — $0.085 per vCPU-hour
• Agent Memory — $0.009 per GiB-hour
• Agent Storage — $0.30 per GiB-month

The unusual part is that non-compute activity is expressed in the same currency rather than as separate SKUs. Agent Gateway bills 1 Agent Compute vCPU-hour ($0.085) per 15,000 API calls or authorization requests. Memory Bank, Sessions and Skill Registry bill 1 vCPU-hour per 3 million read operations and 1 vCPU-hour per 1 million write operations. All amounts are pro-rated to actual usage.

Two things to hold onto. First, at those conversion rates the operational metering is close to rounding error for most workloads — three million reads for eight and a half cents is not what will drive your bill. Second, and consequently, model tokens are billed separately under their respective model SKUs and are not included in any of the above. Your cost forecast for this platform is, in practice, a token forecast with a modest infrastructure surcharge; treating the vCPU-hour rates as the headline number will mislead you in the optimistic direction.

We found no free monthly allowance for Agent Compute stated on the pricing page. Third-party sources describe one (commonly "50 vCPU-hours and 100 GB-hours"), but we could not confirm it against a Google page and are not repeating it as fact. Google's standard $300 new-customer credit is referenced, but that is an account-level trial credit, not a product free tier.

The pricing page carries explicit commencement notes, and they are close enough to matter for anyone currently building. Memory Bank, Sessions and Skill Registry all state that billing "will commence on September 1st, 2026" — eighteen days from the date of this review. Agent Gateway billing was already noted as effective 13 July 2026.

The practical read: state, memory and conversation history are exactly the components a team leans on hardest during a prototype, and exactly the ones that have been free while teams built against them. If you have a pilot running on Memory Bank or Sessions, the storage line ($0.30/GiB-month) plus operation metering arrives at the start of September whether or not the pilot is finished. This is normal platform maturation and not a trap — Google published the dates in advance — but it is the kind of thing a buyer wants flagged rather than discovered on an invoice.

The portability story above applies to the framework, not the platform. Agent Runtime, Memory Bank, Sessions, Skill Registry and Agent Gateway are Google Cloud managed services with no self-hosted equivalent, and they are where the platform's operational value sits — autoscaling, managed persistent memory, conversation state, agent discovery and authorization.

So the honest characterisation is a two-layer trade-off. Write your agent in ADK and you can take that code to Cloud Run, GKE, another cloud's container service, or a disconnected machine. Adopt the managed layer and you have taken on a Google Cloud dependency for the parts that are hardest to rebuild — durable agent memory and session state in particular. That is a defensible trade for a team already on Google Cloud and a real consideration for one that is not. It is worth deciding deliberately at the start rather than discovering the boundary at migration time, because the two layers are adopted through the same SDK and the seam between them is not visually obvious while you are building.

ADK ships in four languages, but adoption across them is very uneven. Measured today: google/adk-python 21,100 stars, google/adk-go 8,654, google/adk-java 1,681, google/adk-js 1,346.

InfoWorld's Martin Heller, in an independent hands-on review, reports the same asymmetry from the developer's side, noting "few TypeScript, Go, or Java examples" with Python dominating the sample repository, and that the customer service sample "uses mocks for its tools, so not everything works exactly as you'd expect." He also names a significant learning curve as the framework's main drawback.

His overall assessment is favourable, and worth quoting because independent hands-on comparisons in this category are scarce: "Overall, I like the Google ADK, and its architecture makes more sense to me than Amazon Bedrock AgentCore," adding that it "offers more programming language options than AgentCore, as well as better development tooling." For a JVM or Node team, the reasonable expectation is a working SDK on a much less travelled path — budget for reading Python examples and porting them.