Google renamed this product while I was mid-project. Vertex AI Agent Builder, the console and SDK you use to design agents, is now folded into what Google calls the Gemini Enterprise Agent Platform, and the managed runtime that used to be Agent Engine is now Agent Runtime. The API calls barely moved. The names on the buttons did. I will keep the Vertex AI names this series has used and flag the new ones where they matter, because that is what your running code and half the docs still say today.

Two things sit at the center of this part. The Agent Development Kit, or ADK, is an open-source framework for writing an agent in code: a model, a set of tools it can call, and the loop that ties them together. Agent Builder is the wider surface around it, the managed runtime, the session and memory services, the evaluation and governance layers that take that code to production. Part 11 covered calling a Gemini model directly with function calling, and Part 12 covered retrieval with RAG Engine. An agent is what you build once one model call and one tool are no longer enough.

What Agent Builder and the ADK actually are

Start with the split, because the two names get used as if they were one thing. The ADK is a library you install with pip. You write a Python file that declares an agent: which model runs it, a system instruction, and a list of plain Python functions the model is allowed to call as tools. The ADK handles the reasoning loop, deciding when to call a tool, feeding the result back to the model, and stopping when the answer is ready. It runs on your laptop with no cloud account attached. The framework is open source and also ships SDKs beyond Python, including Java, with more languages listed in the docs.

Agent Builder is the managed half. Once the agent works locally, you deploy it to Agent Runtime, a serverless host that keeps your agent process alive, scales replicas under load, and exposes it as an endpoint. Around that sit Sessions for short-term conversation state, Memory Bank for long-term facts about a user, an Evaluation service, tracing into Cloud Trace, and governance controls. You can use the ADK without any of this and self-host the result. You lose most of the reason to be on Google Cloud when you do.

The console has a visual builder too, now called Agent Studio, plus a gallery of prebuilt samples Google calls Agent Garden. I reach for those to learn an API shape, not to ship. Real agents live in a code repository with tests and review, and the ADK is the code-first path to that.

Why I build agents in code, not the console

The console builder demos well. It falls apart the moment an agent needs a code review, a unit test, or a second environment. An agent is software. It has branches, edge cases, and a tool that returns the wrong shape at 2am. You want that under version control, running in CI, and diffable when it breaks. A drag-and-drop canvas gives you none of that.

Code-first also keeps you portable. An ADK agent is Python, so the same file runs on your laptop, in a container on Cloud Run, on a GKE pod, or on Agent Runtime, with a change to how you deploy rather than how you wrote it. That portability is real insurance when a product gets renamed under you, as this one just was.

When would I not go code-first? A non-engineer building an internal helper agent for a small team, who will never touch a repo, is better served by Agent Studio. For anything a customer will hit, or anything that calls a tool with side effects, the answer is code.

How an ADK agent handles one request

Walk one turn through the loop, because this is where agents stop being magic. A user message arrives at the runtime. The ADK builds a prompt from your instruction, the conversation so far pulled from Sessions, and the JSON schema of every tool you registered. It sends that to the model. The model does one of two things: it answers, or it asks to call a tool with specific arguments.

If it asks for a tool, the ADK runs your Python function, captures the return value, and appends it to the conversation. Then it calls the model again with that new information. This repeats until the model produces a final answer instead of another tool call. That repetition is the whole difference between an agent and a single model call. The model is deciding, step by step, which action moves it toward the goal, and your code is executing those actions.

Two limits keep this honest. Set a maximum number of steps so a confused model cannot loop forever and burn tokens. And make every tool return fast and return a clear error, because the model reasons over whatever text your function hands back. A tool that returns a stack trace teaches the model to give up.

Which runtime should host the agent?

You have three sensible places to run an ADK agent, and the choice is mostly about how much operations work you want to own. Agent Runtime is the managed default: you hand it your code, it keeps a replica warm, scales under load, and wires in Sessions, Memory Bank, tracing, and identity. Cloud Run is the middle ground, a container that scales to zero and back, good when traffic is bursty and you already package things as images. GKE is full control on Kubernetes, and the only real reason to pick it is a constraint the managed runtime cannot meet.

The table below is how I decide. Read the rightmost column first.

If you are weighing GPU-backed serving for a self-hosted open model behind the agent, the trade-offs there belong to a different stack, and the NVIDIA AI guide covers them rather than this series repeating them.

Sessions and Memory Bank, the state layer

A model call is stateless. The runtime is not, and that is the point. Sessions hold the running conversation for one user interaction, the turns so far, so the agent remembers what was said two messages ago. When a session ends, that transcript can be summarized into Memory Bank, which stores durable facts about a user across sessions: their account tier, that they prefer metric units, the name of the project they always ask about.

Keep the two roles separate in your head. Sessions are working memory, cheap and short-lived. Memory Bank is long-term memory, and it costs more because it persists and gets retrieved into future prompts. The failure mode is stuffing everything into Memory Bank, which grows the prompt, raises token cost on every turn, and drags in stale facts. Write to Memory Bank deliberately, not on every message.

Both are billed per event, so state is not free even when the model is idle. That matters for the cost picture below, and it is the number people forget when they price an agent.

Build and deploy a support agent

Here is a small agent end to end. One model, one tool, deployed to the managed runtime. The tool is a stub; swap it for a real lookup. Note the deploy verb: the ADK command historically read adk deploy agent_engine, and with the 2026 rename it may now read adk deploy agent_runtime, so check the command help before you run it.

# support_agent/agent.py
from google.adk.agents import Agent

def order_status(order_id: str) -> dict:
    '''Look up the shipping status for an order id.'''
    # replace with a real call into your order system
    return {'order_id': order_id, 'status': 'shipped', 'eta_days': 2}

root_agent = Agent(
    name='support_agent',
    model='gemini-2.5-flash',
    instruction=(
        'You answer order questions. '
        'Call order_status for any order id the user gives. '
        'If no id is given, ask for one.'
    ),
    tools=[order_status],
)

# test locally, then deploy
adk run support_agent           # chat with it in your terminal
adk deploy agent_engine 
  --project=my-proj 
  --region=us-central1 
  --staging_bucket=gs://my-proj-agents 
  support_agent
# expected: a resource name like
# projects/123/locations/us-central1/reasoningEngines/456

Expected result: adk run gives you a local chat loop, and asking about order A-1005 returns a shipped status with a two day estimate. The deploy prints a reasoning engine resource name, which is the endpoint your app calls. Common failure: the deploy fails with a permission error because the calling identity lacks the Vertex AI User role, or with a staging error because the bucket does not exist. Create the bucket and grant the role before you deploy, not after the traceback.

Worked example

Price one always-on support agent for a month. The runtime holds one replica of 2 vCPU and 4 GB across 730 hours. Compute is 730 times two vCPU-hours at about 0.0864 dollars plus 730 times four GB-hours at about 0.0090 dollars, which is roughly 152 dollars. Add 100,000 session and memory events at about 0.25 dollars per thousand, near 25 dollars. Add 50,000 grounding queries at about 2 dollars per thousand, near 100 dollars. Add roughly 40 dollars of Gemini Flash tokens. Total lands near 317 dollars a month, and about 152 of that is fixed before a single user shows up.

What it costs to keep an agent running

An agent has a cost shape that a plain API call does not, and it surprises people. With the managed runtime you pay for a replica that stays warm, billed per vCPU-hour and per GB-hour, whether or not anyone is talking to it. On top of that sit per-event charges for Sessions and Memory Bank, per-query charges if you ground with Agent Search, and model tokens billed separately. The chart below breaks the worked example into its four parts.

The fixed compute floor is why a low-traffic agent can look expensive per request. The next chart plots total monthly cost as request volume climbs. Notice the line does not start at zero; it starts at the warm-replica floor and rises with model and search usage.

The lesson I take from this: for a spiky or low-traffic agent, Cloud Run scaling to zero can beat the managed runtime on raw cost, and you accept a cold start in exchange. For steady traffic, the managed runtime earns its floor by handing you state, tracing, and identity you would otherwise build. Pricing on the Vertex AI pricing page shifts, so treat every number here as a shape to confirm, not a quote.

Governance before you let an agent act

An agent that only answers questions is low risk. An agent that calls tools with side effects, refunds an order, opens a ticket, sends an email, is a different animal, and Agent Builder has a governance layer built for exactly that. Each deployed agent gets its own identity through IAM, so you scope what it can reach the same way you scope a service account, no broader. Model Armor screens prompts and responses for injection and unsafe content. Agent Gateway sits in front of traffic for policy and connectivity control, and an Agent Registry tracks what is deployed.

My rule is blunt: no agent touches a tool with side effects until its identity is scoped down and Model Armor is on. It is far easier to wire this in before launch than to retrofit it after an agent has been calling an internal API with a wide role for a month. Governance is not a later phase. It is a launch requirement for anything that can change state.

Safety filtering and Model Armor get a full treatment in Part 14, which builds directly on this one; grounding and retrieval quality, the other half of a trustworthy agent, was Part 12.

Code-first ADK is the right default, GKE is the exception

Here is where I land after shipping these. Write the agent with the ADK, in a repo, with tests. Deploy it to Agent Runtime and take the Sessions, Memory Bank, tracing, and identity that come with it, because rebuilding those yourself is weeks of work for no differentiation. Drop to Cloud Run only when scale-to-zero economics matter more than the free state layer. Drop to GKE only when a hard constraint, a GPU-bound tool or a strict network boundary, leaves you no choice. The console builder is for learning and for non-engineers, not for anything a customer will touch.

And keep one eye on the names. This platform is being renamed and reorganized under you right now, from Vertex AI to Gemini Enterprise Agent Platform, from Agent Engine to Agent Runtime. Write to the code and the API, which are stable, not to the label on the console tab, which is not. Your next move: take the support agent above, point its one tool at a real system, and deploy it to a throwaway project before you price anything.

Dr. Pranay Jha, AI infrastructure architect and long-time vExpert, writing from building and running these platforms for real customers.