Agent Runtime: sessions, memory, deploys, meter

Lesson 3 of 5 in Google’s Agent Stack: ADK, Agent Runtime, and the Names That Keep Moving.

The managed runtime’s pitch is one sentence: you “deploy and scale agents efficiently without the need to manage underlying infrastructure”, inside “a fully managed environment for developers to handle testing, release management, and reliability at a global scale.”

Two details in that pitch matter more than the marketing. First, it is not ADK-only: the runtime is documented as supporting agents built with ADK, A2A, LangChain, LangGraph, AG2, LlamaIndex (Query Pipeline), and fully custom code. If you have a LangGraph agent and want Google’s runtime, that is a supported combination, not a workaround. Second, release management is doing real work in that sentence — the documented operations include revision and traffic management, which is the difference between “I can deploy” and “I can roll back the deploy that started hallucinating at 3 a.m.”

The ring of managed services around the runtime (Agent Platform overview and pricing page, checked September 2026)
Service	What the docs say it does	What you would otherwise build	Check before you depend on it
Sessions	Stores individual interactions between users and agents — short-term conversational state. Manageable via ADK, the console, or the API.	A durable message store with per-user isolation and a resume path when the process dies mid-task.	Quotas and region lists were not printed on the pages checked. Read the live docs.
Memory Bank	Stores and retrieves information from sessions to personalise interactions, and “uses Generative AI models to generate memories” — with event ingestion, memory profiles, and memory revisions.	An extraction pipeline, embeddings, a retrieval API, and a policy for what is worth remembering.	Went Preview 8 July 2025 and GA (with Sessions) 16 December 2025. ML processing occurs in the region or multi-region of the model endpoint used — a residency question, not a latency one.
Sandbox / Code Execution	Secure code execution for agent-generated code, including Computer Use and shell sandboxes.	A container per session, an egress policy, and a convincing story about why model-written code cannot reach your VPC.	Code Execution arrived in Preview on 10 September 2025. Confirm current launch stage and isolation guarantees yourself.
Example Store	Stores few-shot examples for agents to draw on.	A versioned example corpus plus retrieval, wired into prompt assembly.	Notably the one service the enterprise-security table did not list as covered by VPC Service Controls, CMEK, and data residency at rest.
Skill Registry	Stores, searches, reads, and dynamically loads agent skills, with Vulnerability Analysis of skills billed as model tokens.	A registry, a search index, and a review process for capabilities your agents load at runtime.	Dynamic loading means the tool set is data, not code. Treat registry write access as a security boundary.
Agent Gateway	Marketed as Agent-to-Anywhere: routing and authorization for API calls made during agent execution, for agents on the runtime and in the Gemini Enterprise app.	A protocol-converting proxy plus a credential broker plus per-call authorization.	Billed per API call or authorization request. Its meter is a decent proxy for how chatty your agents are.
Agent Retrieval	Labelled formerly Vector Search 2.0: a fully managed retrieval engine unifying vector indexing and payload storage in one service.	An ANN index, a payload database, and the sync between them.	The retrieval layer under your agents, priced by index serving capacity — not an agent feature per se.
Feedback + evaluation	A Feedback service for collecting user feedback alongside telemetry, plus Gen AI evaluation.	A feedback schema joined to traces, and an evaluation harness with a golden dataset.	Feedback joined to trace ids is the raw material for evals. Design that join before you launch, not after.

Now the distinction that decides your data model. Sessions hold short-term conversational state; Memory Bank holds long-term memories derived from those sessions. One conversation versus what you know about this user across all their conversations.

The implementation detail is the important part: Memory Bank generates memories with generative models rather than storing turns verbatim. An LLM reads session events and writes durable facts. That buys you compact, useful memory — “prefers morning appointments”, “manages the Frankfurt account” — instead of a transcript archive nobody can query.

Generated memory is an inference pipeline, so treat it like one

If an LLM writes the memories, then three things follow that a key-value store would not have made you think about.

It can be wrong. A misread aside becomes a durable “fact” about a customer, and every later session reasons from it. Memory revisions exist for a reason — build a path to correct and delete, and know who is allowed to.

It can be attacked. Text the agent reads during a session can be crafted to plant a memory that fires on a later session — injection with persistence, and a cousin of tool-output poisoning. Memory Bank access control is via IAM Conditions; scope memory reads and writes per user rather than per application wherever you can.

It costs tokens and it has a location. The generation call is billed under the model’s own SKU, and the ML processing happens in the region or multi-region of the model endpoint used. If your residency story says “data stays in europe-west”, that includes the model doing the memory extraction.

How the runtime accumulated its features — and why you should read release notes like this

A compressed history from the Vertex AI release notes, because the pattern is the lesson:

4 March 2025 — general availability, billing starts the same day; the note also records that “LangChain on Vertex AI has been renamed to Vertex AI Agent Engine”.
9 April 2025 — ADK integration, Example Store, and LlamaIndex Query Pipeline integration land in Preview; Agent Garden debuts.
7 and 21 August 2025 — custom service accounts for agent identity, then Private Service Connect deployment, CMEK, customised resource controls (instance counts, per-container limits and concurrency), and HIPAA support.
10 September 2025 — Code Execution in Preview, A2A-protocol agent support, bidirectional streaming, a console Memory Bank tab — and a breaking refactor of the Python SDK’s agent_engines module to a client-based design in v1.112.0.
7 November 2025 — console observability in Preview (sessions, traces, logs, events, plus a playground), Gen AI evaluation via the SDK, memory revisions, IAM agent identity; Express mode and a runtime free tier go GA.
16 December 2025 — Sessions and Memory Bank reach GA, runtime pricing drops, seven regions are added, and usage charging for Sessions, Memory Bank, and Code Execution is scheduled.

Read that list as a maturity signal, not trivia. A platform whose isolation, identity, and observability features all arrived within a year of GA is a platform where “is this GA?” is a question with a different answer each quarter — and where a minor SDK bump once contained a breaking change.

Which regions and what quotas?

By December 2025 the runtime had expanded to additional regions including europe-west6 (Zurich), europe-west8 (Milan), asia-east2 (Hong Kong), asia-northeast3 (Seoul), asia-southeast2 (Jakarta), northamerica-northeast2 (Toronto), and southamerica-east1 (São Paulo).

Exact quotas, current region lists, and supported model lists for Sessions and Memory Bank were not on the pages checked in September 2026. If a region or a quota is load-bearing for your design — and residency requirements make it load-bearing more often than latency does — get it from the live docs and put the date next to it in your own document.

Finally, the meter — because the shape of a bill tells you what the platform thinks it is selling, and that outlives any particular number.

Google’s answer is unusually tidy: as checked in September 2026, the platform’s “Scale” products share a unified structure built on three resource SKUs — Agent Compute (per vCPU-hour), Agent Memory (per GiB-hour of RAM), and Agent Storage — with request-based services converted into Agent Compute units. That is not a per-agent price, a per-seat price, or a per-token price. It is an infrastructure meter, which tells you the runtime bills like hosting: you pay for allocated capacity over time, so idle capacity and oversized containers are your bill, not your model’s.

The shape of the meter (Agent Platform pricing page, checked September 2026 — verify every number before you model a budget)
Meter	What it charges for	Rate as published in September 2026	What it makes you optimise
Agent Compute	Allocated vCPU time for the runtime and sandbox environments, rounded to the nearest second.	$0.085 per vCPU-hour, with the first 50 vCPU-hours per account per month free.	Container sizing and session lifetime. For the runtime, idle time spent waiting for the next prompt between turns is not billed — so a slow human is cheaper here than on a naive always-on container.
Agent Memory (RAM)	Allocated RAM over time for the same environments.	$0.009 per GiB-hour, with the first 100 GiB-hours per month free.	Not asking for 8 GiB because it felt safer. Allocation is the charge, whether you use it or not.
Agent Storage	Durable bytes: Sessions, Memory Bank, Skill Registry contents.	Published inconsistently on the page checked — prose quotes $0.30 per GiB-month while the SKU table lists an hourly rate of $0.000328767 per GiB-hour. Reconcile against the live page before quoting either.	Retention policy. Sessions you never delete are a bill that only grows, and unbounded memory is a governance problem before it is a cost problem.
Sessions and Memory Bank operations	Reads and writes against the two state services, converted into Agent Compute units.	One vCPU-hour ($0.085) per 3 million read operations; one per 1 million write operations. Billing on this structure commences 1 September 2026.	Chattiness. An agent that re-reads memory on every loop iteration multiplies this meter by its own turn count.
Agent Gateway	API calls and authorization requests processed during agent execution, for runtime agents and the Gemini Enterprise app.	One vCPU-hour ($0.085) per 15,000 calls or authorization requests, billing effective 13 July 2026.	Tool-call volume — which is also your latency and your audit volume. Three meters, one behaviour.
Model tokens	Everything the model itself does, including the generation calls that write memories and analyse skills.	Billed under the model’s own SKU, separately from the three platform SKUs.	Remembering: memory generation is inference. It is a real line item, not free bookkeeping.
Commitments	Discounts against the above.	Gemini Enterprise Flexible Savings Plans (1-year and 3-year) discount these rates roughly 10% and 20% respectively.	Nothing technical — but a three-year commitment on a platform that renamed itself twice in two years is a business decision, not a procurement formality.

Key terms: memory, trace, eval, prompt injection, tool-output poisoning, RAG

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.