Vertex AI Agent Builder: The Ownership Test Before Production

Vertex AI Agent Builder did not vanish. Google renamed and rearranged it. The old product URL now lands on Gemini Enterprise Agent Platform, where the console, development kit, managed runtime, memory, evaluation, and observability are presented as parts of one agent stack.

That rebrand is the least important part of the decision. The consequential change is what a team agrees to own after a promising demo: a cloud project, a runtime identity, deployment artifacts, resource limits, tool permissions, evaluation cases, telemetry, and several independent cost meters. The model is only one line in that operating contract.

A fresh 23 July replay tested that contract with the retained deterministic configuration fixture. A console-first shortcut failed 18 controls, including two consequential tools without human approval. A deliberately narrow read-only pilot passed the same validator with zero errors. Nothing was deployed to Google Cloud, so this is not a latency, quality, reliability, or cost benchmark. It is evidence for a narrower warning: “the agent answered” and “the agent is ready to run” are different claims.

That gap is the ownership test.

The old name now points to a larger platform

Google's current documentation separates three choices that older Vertex AI Agent Builder guides often blur together. Agent Studio is the console route for building and trying an agent. The Agent Development Kit (ADK) is a code-first framework. Agent Runtime is the managed deployment surface. Around that runtime sit sessions, Memory Bank, evaluation, tracing, logging, monitoring, sandboxing, identity, a registry, and tool gateways.

That map matters because each part creates a different obligation. A prompt edited in Agent Studio is not a versioned deployment. An ADK project that works under adk web is not a production server; the official quickstart explicitly describes that interface as development and debugging software. A successful Agent Runtime deployment proves that a resource was created. It does not prove that the identity is narrow, the tool can fail safely, or the bill has a ceiling.

Sources of the shortcut manifest’s eighteen omissions

The retained fixture contains two deployment manifests and one local validator. The fresh replay began with the shortcut a team might take after a good console session: it named ADK Web as the target, relied on the default identity with project-owner access, embedded a secret, exposed four tools, left resource defaults largely intact, and defined no evaluation, telemetry, timeout, retry, budget, rollback, or operational owner.

The second manifest described a read-only pilot. It pinned a source revision, used a dedicated service account, referenced Secret Manager, exposed one approved-document search tool, ran seven denial and failure cases, and declared logs, traces, metrics, timeouts, retries, model-token and grounding ceilings, a rollback revision, and an owner. Its resource starting point was intentionally modest: zero minimum instances, three maximum instances, one CPU, 2 GiB of memory, and concurrency three.

The 23 July replay again produced 18 shortcut errors. Two were especially serious: both consequential tools could act without human approval. The pilot produced none. This replay's fixture SHA-256 is c73047ac2edc799032b4e9cfe58c6bc79a73ae6f0fb8b66b702a43a81e80a356, and its six-event ledger is sequence-complete, so the observations remain tied to the exact inputs rather than a reconstructed anecdote.

The validator scored reviewability, not polish.

This result does not say the pilot will be fast, cheap, reliable, or useful. It says the pilot's assumptions are visible enough to test.

The blast radius begins with project identity

Current Agent Runtime setup starts with a Google Cloud project and billing. The documented API set reaches beyond the agent service into storage, logging, monitoring, telemetry, trace, and resource management. Permissions are needed both to enable services and to operate the platform. That is normal cloud engineering, but it means the first architecture question is not “Which Gemini model?” It is “Which project and identity absorb the blast radius?”

A dedicated agent identity or service account gives reviewers somewhere concrete to attach policy. Avoid granting broad project ownership just to unstick deployment. A tool that reads approved documents needs different authority from one that updates customer data or sends a message. Model access does not confer either permission; each downstream system still enforces its own boundary.

Cloud-managed is not permissionless.

Secret handling has the same shape. Agent Runtime supports Secret Manager references, and the runtime identity needs the corresponding accessor role. Passing the secret through source, a prompt, or an environment file may get a prototype moving, but it also makes provenance and rotation harder to prove. Use a versioned reference for the pilot, then test what happens when access is removed.

Troubleshooting deployment starts with a reproducible input

Reproducibility decides which path deserves production traffic.

Agent Runtime currently documents several deployment inputs: an in-memory agent object, local source files, a Dockerfile, an Artifact Registry image, and a repository connected through Developer Connect. They are not equivalent packaging syntaxes.

• Agent object: convenient for an experiment, but serialization and staging become part of the result.
• Source files: a sensible first CI path when dependencies and the package boundary are pinned.
• Dockerfile or image: appropriate when the build environment, server, or system dependencies must be controlled explicitly.
• Developer Connect: useful when deployment should follow an already governed Git repository.

Google's current deployment page notes that source-files and Dockerfile paths do not require a Cloud Storage staging bucket. Object deployment does. That detail is worth preserving in a runbook because a stale tutorial can otherwise create a bucket, IAM policy, and data path the design never needed.

Whatever input you choose, preserve an immutable answer to “what is running?” A mutable branch name or an unversioned requirements file is not enough. Record the source commit or image digest alongside the runtime resource, evaluation result, identity, and rollback target.

Default capacity is an unreviewed production choice

Defaults are an opening bid.

The managed runtime exposes minimum and maximum instances, CPU, memory, and container concurrency. Google's documentation currently lists a default of one minimum instance, 100 maximum instances, four CPUs, 4 GiB memory, and concurrency nine. Those numbers describe a default shape, not a recommendation for every agent.

For the local pilot manifest, we chose zero minimum instances and a maximum of three. That makes cold starts possible and bounds idle and burst capacity while the workload is still unknown. We chose concurrency three because the deployment documentation offers 2 × CPU + 1 as a starting recommendation. These are local review choices, not universal limits. A tool-heavy agent may saturate on memory, downstream rate limits, or long network waits before CPU tells the truth.

The bill has more than one meter

No single meter settles the budget.

There is no durable single price for “Vertex AI Agent Builder.” Google's pricing page separates model token charges from grounding features, while runtime compute and ordinary Cloud services have their own meters. Rates, included quotas, model names, and preview terms can change, so freezing a detailed price table inside an evergreen guide would be false precision.

Our review enumerated six surfaces that require separate budget attention: model input and output tokens; runtime instance time; grounding queries; storage; logs and traces; and network or downstream tool services. This is a cost-surface inventory, not a quote. It also omits engineering time, IAM review, incident response, and integration maintenance, which are real costs without being line items on the same invoice.

A useful budget test starts with representative successful and failed tasks. Record token use, tool calls, grounded queries, wall time, and retries. Compare the median with the tail. An agent that loops before failing can consume more than a correct answer, while a nonzero minimum instance can accrue cost with no user request at all. Put ceilings on turns, retries, runtime duration, output, and log volume before raising traffic.

Requirements before the first write-capable tool

The governed fixture used one read-only tool and seven cases: known answer, unknown answer, malformed input, prompt injection, tool timeout, cross-tenant request, and a request to perform a write. The last case had to refuse. This is not a complete evaluation suite, but it reveals more than repeating the happy-path prompt.

Only after those traces are inspectable should a write-capable tool enter the design. At that point, define the exact arguments it accepts, the identity it uses, the evidence shown to a reviewer, the approval required, and the idempotency or rollback behavior. “Human in the loop” is not a control unless the human can see what will happen and can still stop it.

When Gemini Enterprise Agent Platform is the right ownership choice

The platform is a credible fit when the agent belongs inside an existing Google Cloud estate: the team already operates IAM, budgets, CI/CD, observability, networking, and incident response; the agent needs Google data or services; and managed sessions, memory, evaluation, or runtime controls reduce work the team would otherwise build.

It is a poor fit when “managed” is being mistaken for “ownerless.” A small team that mainly needs a persistent browser, terminal, files, schedules, secrets, and chat may get to the workflow faster with a hosted worker. GolemWorkers packages those operational surfaces into a running environment, which can be the simpler choice while the task and approval boundaries are still being discovered.

The two paths can coexist. A hosted operator can call a narrowly scoped Google-hosted agent, or an early workflow can graduate into Agent Runtime after its tools, identity, evidence, and traffic shape are understood. The important part is to migrate a tested contract, not merely a prompt that once worked.

Choose the control plane only when the workflow earns it

Ownership has to be explicit.

Keep “Vertex AI Agent Builder” in the search vocabulary, but make the architecture decision against the current Gemini Enterprise Agent Platform. Choose it when you want to own a governed cloud service and its surrounding control plane. Start with one read-only task, one pinned artifact, one narrow identity, explicit resource ceilings, seven uncomfortable tests, and a rollback path.

If that sounds like more platform than the workflow deserves, it probably is. Prove the work in a simpler hosted environment first. You can create an AI agent on GolemWorkers without assembling the cloud runtime, or compare the broader AI agent builder landscape before committing to an operating model.

Evidence boundary: all six claim-level primary sources below returned HTTP 200 on 23 July 2026 and matched their retained claim markers. The fixture replay was local and deterministic; it did not contact a credential, Agent Runtime, model, network service, production system, message channel, or customer record.

Six current documents anchor the ownership test

• Google Cloud: former Vertex AI Agent Builder product URL — current redirect and platform name.
• Google Cloud: Build with Gemini Enterprise Agent Platform — console, ADK, frameworks, tools, and platform components.
• Google Cloud: Set up Agent Runtime — projects, APIs, roles, identities, and storage.
• Google Cloud: Deploy an agent — deployment inputs, secrets, resources, and concurrency.
• Google Agent Development Kit: Python quickstart — local project and the ADK Web production warning.
• Google Cloud: generative AI pricing — current model and grounding meters.