Vertex AI Agent Builder: Setup, Pricing, and Simpler Alternatives

Short answer: the product people still search for as Vertex AI Agent Builder is now presented by Google as Gemini Enterprise Agent Platform. The practical route is to prototype with Agent Studio or the open-source Agent Development Kit, test the agent locally, then deploy it to Agent Runtime with a dedicated identity, narrow permissions, logs, and explicit cost limits. Choose the Google stack when you need deep Google Cloud integration and enterprise controls. Choose a simpler hosted worker when the real requirement is an always-on browser, terminal, files, schedules, and chat without assembling a cloud platform first.

The rename is not cosmetic. Google's current documentation splits agent work across building, runtime, sessions, memory, evaluation, observability, and tools. A search for the old name can land you in pages written for an earlier product map. This guide uses the familiar keyword so you can find it, then follows the product names and setup paths Google documents now.

Pricing deserves the same care. There is no honest single “Vertex AI Agent Builder price.” A bill may contain model tokens, runtime compute, grounding queries, storage, logs, networking, and services called by tools. The useful question is not the sticker price of one page; it is which meters your agent actually turns on.

Contents

• What Vertex AI Agent Builder is called now
• Choose the right build path
• Set up a Google Cloud project safely
• Build and test a small ADK agent
• Move from a laptop to Agent Runtime
• Estimate the real cost
• Know when a simpler runtime wins

Vertex AI Agent Builder is now part of Gemini Enterprise Agent Platform

Google's former Agent Builder product URL now redirects to Gemini Enterprise Agent Platform. The current platform documentation describes two broad ways to create an agent. You can work in the console with Agent Studio and prebuilt material from Agent Garden, or take a code-first route with Google's ADK or another supported framework. Deployment and operations live under Agent Runtime and related services.

That distinction prevents a common planning mistake: treating every Google agent feature as one visual builder. Agent Studio is the console experience. ADK is an open-source framework. Agent Runtime is the managed execution layer. Sessions, Memory Bank, evaluation, tracing, logging, monitoring, sandboxed code execution, and computer use are separate capabilities around the runtime.

Use the old name as a search synonym. Use the current component names in architecture, budgets, IAM policies, and runbooks.

Choose the build path before creating resources

Start with the work, not the model. Write down one input, one useful output, the tools required, the data boundary, and the action that still needs human approval. A customer-support answer backed by approved documents is a different system from an agent that edits infrastructure or operates a browser.

Use Agent Studio for a quick console prototype

Agent Studio is useful when a product owner and engineer need to test instructions, tools, and conversational behavior together. It lowers the cost of the first experiment. Do not let a successful console conversation stand in for production readiness. Export the design decisions into a versioned artifact, define the runtime identity, and test failures outside the happy path.

Use ADK when the agent is part of your codebase

ADK supports Python, TypeScript, Go, and Java. It can run locally, then move to Agent Runtime, Cloud Run, or Google Kubernetes Engine. It also supports multi-agent composition and both predictable workflow agents and dynamic routing. This is the clearest path when pull requests, tests, dependency pinning, and CI/CD matter.

Bring another framework when its semantics matter

The managed runtime documents templates for ADK, LangChain, LangGraph, AG2, LlamaIndex, and Agent2Agent integrations, plus a custom-agent path. Pick one because its execution model fits the problem. For example, LangGraph's explicit graph and replay model can be valuable for human-in-the-loop workflows. Framework familiarity alone is a weak reason to inherit extra dependencies.

Set up the Google Cloud project with a narrow security boundary

Google's runtime setup starts with a Cloud project and billing. Enable the platform API and the supporting APIs needed for storage, logging, monitoring, telemetry, trace, and resource management. An administrator may need to grant the Agent Platform User role and the Service Usage permission required to enable APIs.

Do not grant the agent broad project ownership just to get the first deployment through. Google's current recommendation is an IAM agent identity tied to the individual agent. A custom service account is another option when you need a familiar policy model. In either case, add only the roles required by the agent's tools.

1. Create or select a dedicated Google Cloud project and confirm billing.
2. Choose a region after checking model, runtime, data-residency, and networking requirements.
3. Enable only the APIs needed by the first version.
4. Create the agent identity before deployment when policies must be reviewed in advance.
5. Store credentials in Secret Manager rather than in source files or prompts.
6. Set a budget and billing alerts before sending test traffic.

Cloud Storage is conditional. Deploying from source files can upload the source directly without a staging bucket. Deploying an in-memory agent object uses a bucket to stage packaged artifacts. This small distinction matters in locked-down environments: do not create and authorize a bucket merely because an older tutorial assumed one.

Build and test a small ADK agent locally

The official Python quickstart requires Python 3.10 or later. Use a virtual environment so the agent's dependencies do not drift with unrelated projects:

python3 -m venv .venv
source .venv/bin/activate
pip install google-adk
adk create support_agent

The generated project contains agent.py, .env, and __init__.py. The only required program element is root_agent. A compact example can define one read-only tool and make the tool's result observable:

from google.adk.agents.llm_agent import Agent

def lookup_order(order_id: str) -> dict:
    """Returns a sanitized order status for an approved order ID."""
    return {"status": "shipped", "order_id": order_id}

root_agent = Agent(
    model="gemini-flash-latest",
    name="support_agent",
    description="Answers order-status questions.",
    instruction=(
        "Use lookup_order for order status. "
        "Never invent an order, refund, or delivery date."
    ),
    tools=[lookup_order],
)

Run it with adk run support_agent, or launch the local development interface with adk web --port 8000 from the parent directory. ADK Web is for development and debugging; Google explicitly warns against using it as a production deployment.

Test the denial path, not only the answer

A useful first test suite includes an unknown order, malformed input, a prompt asking for another customer's data, a tool timeout, and a request for an unauthorized refund. Record the tool call and the final response. The agent should refuse or degrade predictably without fabricating success.

Keep initialization separate from request handling. The managed runtime serializes or packages the agent, and open sockets or file handles stored inside agent state can break deployment. Pin SDK and framework versions once the prototype works so the build can be reproduced.

Deploy to Agent Runtime without losing control

Agent Runtime currently documents five deployment inputs: an in-memory agent object, local source files, a Dockerfile, an image in Artifact Registry, or a connected Git repository. Source deployment is a sensible default for CI/CD. A container image is better when you need exact control over the build or faster redeployment from a prebuilt artifact.

Before traffic arrives, configure minimum and maximum instances, CPU, memory, and container concurrency from measured behavior. The documented defaults are not a performance target. A nonzero minimum instance can reduce cold starts and also creates idle cost. High concurrency can improve efficiency until tool calls, memory, or downstream rate limits become the bottleneck.

After deployment, run one known request through the remote endpoint. Verify the response, tool trace, logs, identity, secret access, latency, and refusal behavior. Then disable or rotate the test credential. A successful deployment message proves that a resource exists; it does not prove the agent can complete the job safely.

Vertex AI Agent Builder pricing: count the meters

Google publishes model prices per token and separate prices for capabilities such as grounding. Runtime and adjacent Cloud services have their own meters. Model families, regional rates, preview status, and included quotas change, so use the official calculator and pricing pages on the day you approve a budget.

Build a cost estimate from a representative successful run:

monthly cost ≈
  successful runs × model tokens per run
  + runtime instance time
  + grounding or search queries
  + storage, logs, traces, and network egress
  + databases and APIs called by tools
  + retry and evaluation traffic

Measure failed runs separately. An agent that loops through five tool calls before timing out may be more expensive than one that answers correctly. Set ceilings for turns, tool calls, output tokens, runtime duration, and retries. Cache stable context where the model and product support it, but do not cache user-specific data across an unsafe boundary.

A practical pilot budget

• Collect 50 to 100 representative tasks, including failures.
• Record input tokens, output tokens, tool calls, wall time, and grounded queries per task.
• Separate development and evaluation traffic from user traffic.
• Estimate the 50th and 95th percentile rather than one average.
• Add logs, storage, networking, and downstream APIs to the same worksheet.
• Set a monthly alert well below the maximum amount the project can spend.

Do not compare platforms using model tokens alone. Engineering time, IAM reviews, on-call work, integration maintenance, and failure investigation are part of the operating cost even when they never appear on the cloud invoice.

When a simpler hosted alternative is the better tool

Gemini Enterprise Agent Platform is a strong fit when the agent belongs inside an existing Google Cloud estate. It offers managed deployment, IAM, sessions, memory, evaluation, telemetry, Google services, and several framework paths. Those pieces are valuable when the organization already has cloud governance and the agent will become a maintained service.

It can be more platform than you need. If the requirement is “give this worker a browser, terminal, files, secrets, Telegram, and a schedule,” a dedicated hosted agent may reach the useful workflow sooner. GolemWorkers provides that runtime as an environment rather than asking a team to assemble project APIs, packaging, observability, connectors, and machine operations first.

The choice is not permanent. A team can validate a workflow in a hosted worker, learn which tools and approvals matter, then implement a dedicated service on Google Cloud. It can also keep a GolemWorkers operator as the outer control loop while calling a specialized Google-hosted agent for one bounded capability.

Common setup failures

The tutorial uses an obsolete product name

Follow the redirect and map every step to the current Gemini Enterprise Agent Platform documentation. Avoid copying old console paths or IAM role names into a new runbook.

Local ADK works, remote deployment fails

Check package serialization, pinned requirements, region availability, enabled APIs, staging storage for object deployment, and the deploying principal's permissions. Remove open handles and initialization side effects from agent state.

The agent can call the model but not its tool

Model permission does not grant database, Secret Manager, storage, or third-party API access. Inspect the runtime identity and give it the smallest tool-specific permission. Verify that the deployment service can fetch required secrets without granting the runtime unrelated access.

The first invoice is larger than the estimate

Look for retries, evaluation runs, grounded searches, idle minimum instances, verbose output, log volume, and downstream service calls. Tag development traffic and break down cost by environment so a useful production run is not mixed with a noisy experiment.

Production checklist

• The architecture uses current component names and links to current documentation.
• The first workflow has one measurable outcome and one explicit approval boundary.
• The agent runs under a dedicated identity or narrowly scoped service account.
• Secrets live outside source code, prompts, and deployment logs.
• Dependencies and deployment artifacts are pinned and reproducible.
• Known-good, denied, malformed, timeout, and tool-failure cases are tested.
• Remote traces and logs show the expected model and tool sequence.
• Runtime resources, concurrency, retries, and token output have ceilings.
• The budget includes model, runtime, grounding, data, logs, and networking.
• A person can disable the agent and revoke its credentials quickly.

Bottom line

Vertex AI Agent Builder is still a useful search phrase, but the current decision is about Gemini Enterprise Agent Platform. Prototype through Agent Studio or ADK, deploy only after the identity and failure tests are clear, and estimate costs from actual runs rather than a marketing-page number.

Use Google's platform for a governed service that belongs in Google Cloud. Use a dedicated hosted worker when you need useful operational tooling without first becoming the platform team. To test that simpler path, create an AI agent on GolemWorkers. For a broader market view, compare the best AI agent builders.

Primary sources

• Google Cloud: former Vertex AI Agent Builder product URL — current redirect and platform naming.
• Google Cloud: Build with Gemini Enterprise Agent Platform — current console, ADK, framework, and integration paths.
• Google Agent Development Kit: Python quickstart — installation, project creation, local execution, and development interface warning.
• Google Cloud: Set up the Agent Runtime environment — projects, APIs, IAM, identities, and storage.
• Google Cloud: Deploy an agent — deployment methods, dependencies, secrets, and resource controls.
• Google Cloud: Agent Platform generative AI pricing — current model and grounding rates.