Sessions & Memory Bank

Before you start: this is a billed cloud service

• Cost and account. A Google Cloud project with billing enabled and the Agent Engine APIs on. Memory Bank lives on an Agent Engine instance (Lab 2), which bills while it exists; memory generation makes model calls. Clean up at the end.
• Authored against the docs, not executed live. The Python is written against the official docs and syntax-checked, not run during authoring. Sessions/Memory Bank are newer APIs — pin your SDK version and adjust names if yours differs.
• SDK-first.

About this series

This is Part 5 of the eleven-part Gemini Enterprise Agent Platform series. Your agent can reason, answer from documents (Lab 3), and reach real systems (Lab 4) — but it still forgets everything the moment a conversation ends. This lab fixes that with two managed layers: Sessions for short-term conversation history and Memory Bank for long-term memory that persists across conversations.

What you'll build

You'll give the Acme Orders assistant a memory:

1. Short-term: managed Sessions that keep the history of a single conversation (you've used these since Lab 2).
2. Long-term: Memory Bank, which reads completed sessions, extracts the durable facts (a customer's name, their usual shipping address, a standing preference), and recalls them in future conversations.

You'll generate memories from one conversation and watch them surface in a brand-new session — personalization and continuity, without running a database yourself.

Why this matters (the 5-minute business case)

Read this before handing the lab to your team.

An agent that forgets is a worse experience than the form it replaced. If a returning customer has to re-explain who they are and what they want every time, the agent feels broken — worse than a website that at least remembered their login. Memory is what turns a stateless Q&A bot into something that feels like it knows you.

Three reasons this is a leadership-level concern:

1. Personalization is the difference between useful and generic. An agent that remembers a customer's past orders, preferences, and context can give a tailored answer in one turn instead of an interrogation. That continuity is most of the perceived quality of an assistant.
2. It's managed, so you don't run a memory store. Doing this yourself means a database, an extraction pipeline to decide what's worth remembering, embeddings for recall, and privacy controls over all of it. Memory Bank is that pipeline as a service — Gemini extracts the meaningful facts and stores them; you decide when to write and read.
3. It's the production answer to the in-memory stub. In ADK Lab 2 you used an in-memory session that vanished on restart — fine for a demo, useless in production. This is the same capability as a managed backend that survives restarts, scales, and persists across conversations.

The honest caveats:

• Memory is data about people — govern it. Long-term memory means storing facts about users. Decide what's appropriate to remember, scope it per user, and have a deletion story. "Remember everything" is a privacy liability, not a feature.
• It's not free or instant. Generating memories runs a model over conversation history; it has cost and latency. Generate at sensible moments (end of a session), not on every turn.
• Newer API, expect change. Sessions/Memory Bank classes and methods move between versions. Pin and verify.

A framing for a non-technical stakeholder: "This gives our agent a memory — short-term within a conversation, and long-term across them — as a managed service. So a returning customer doesn't start from scratch, and we don't have to build and secure a memory database ourselves."

Concepts you'll use (2-minute primer)

• Sessions — managed short-term state: the ordered history (events) of a single conversation. The runtime keeps it; you reference it by session_id.
• Memory Bank — managed long-term memory. It reads completed sessions, uses Gemini to extract durable facts, and stores them so they can be recalled in later sessions.
• Generate vs. retrieve — you decide when to generate memories (typically when a conversation ends) and when to retrieve them (typically at the start of a new one). Memory Bank does the extraction, storage, and search.
• Scope — memories are stored and retrieved under a scope, usually the user (user_id), so each person's memory is theirs and isolated.
• ADK services — VertexAiSessionService and VertexAiMemoryBankService plug these into an ADK Runner so memory is handled for you; a load_memory tool lets the agent pull relevant memories mid-conversation.

One sentence: Sessions remember a conversation; Memory Bank remembers the person — both managed, both scoped, both attached to your Agent Engine instance.

Prerequisites

You'll need your Agent Engine resource name (the reasoningEngines/... id from Lab 2); Memory Bank and Sessions live on it.

Step 1 — Short-term memory: Sessions (recap)

You've used Sessions since Lab 2: create one per user, send turns against it, and the runtime keeps the conversation history.

import vertexai

client = vertexai.Client(project="your-project-id", location="us-central1")
remote_app = client.agent_engines.get(name="projects/.../reasoningEngines/RESOURCE_ID")

session = remote_app.create_session(user_id="u_123")
for event in remote_app.stream_query(
    user_id="u_123",
    session_id=session["id"],
    message="Hi, I'm Dana. I always want expedited shipping on my orders.",
):
    print(event)

That fact — Dana prefers expedited shipping — now lives in this session. But when the session ends, it's gone. That's what Memory Bank is for.

Step 2 — Generate long-term memories from the conversation

When a conversation ends, have Memory Bank extract the durable facts from it and store them under the user's scope:

client.agent_engines.generate_memories(
    name="projects/.../reasoningEngines/RESOURCE_ID",
    vertex_session_source={"session": session["name"]},  # extract from this session
    scope={"user_id": "u_123"},
)

Memory Bank reads the session, uses Gemini to pull out the meaningful bits (Dana's name, the expedited-shipping preference) — discarding the small talk — and stores them as long-term memories for u_123. You call this; Memory Bank does the extraction.

Step 3 — Retrieve memories in a new conversation

Later — a new session, maybe days later — retrieve what you know about the user and use it to personalize:

memories = client.agent_engines.retrieve_memories(
    name="projects/.../reasoningEngines/RESOURCE_ID",
    scope={"user_id": "u_123"},
    similarity_search_params={"search_query": "shipping preference"},
)
for m in memories:
    print(m)  # e.g. "Prefers expedited shipping"

You can retrieve by similarity search (memories relevant to the current query) or pull all memories within the scope. Inject the result into the agent's context and it greets Dana already knowing her preference — no re-asking.

Step 4 — Let ADK handle it automatically

Calling generate/retrieve by hand is the low-level view. In an ADK app, plug in the managed services and a memory tool so it's handled for you:

from google.adk.agents import Agent
from google.adk.runners import Runner
from google.adk.sessions import VertexAiSessionService
from google.adk.memory import VertexAiMemoryBankService
from google.adk.tools import load_memory

AGENT_ENGINE_ID = "RESOURCE_ID"  # the reasoningEngines id from Lab 2

session_service = VertexAiSessionService(
    project="your-project-id", location="us-central1",
    agent_engine_id=AGENT_ENGINE_ID,
)
memory_service = VertexAiMemoryBankService(
    project="your-project-id", location="us-central1",
    agent_engine_id=AGENT_ENGINE_ID,
)

agent = Agent(
    name="acme_orders_assistant",
    model="gemini-3.5-flash",
    instruction=(
        "You are the Acme Orders assistant. Use the load_memory tool to recall "
        "what you know about the customer (their name, preferences) and "
        "personalize your help. Don't ask for information you already remember."
    ),
    tools=[load_memory],
)

runner = Runner(
    agent=agent,
    app_name="acme-orders",
    session_service=session_service,
    memory_service=memory_service,
)

# When a conversation completes, persist it to long-term memory:
# await memory_service.add_session_to_memory(session)

Now the agent can pull relevant memories mid-conversation via load_memory, and add_session_to_memory rolls a finished conversation into long-term memory — the same generate/retrieve loop from Steps 2–3, handled by the framework.

Class names and method signatures (vertex_session_source, similarity_search_params, the memory-service methods) differ across SDK versions. The shapes here are current as of authoring; if they don't match, print the objects and check the docs for your pinned version.

Cost & cleanup

• Memory Bank and Sessions live on your Agent Engine instance — deleting that instance (Lab 2's cleanup.py, delete(force=True)) removes them.
• If you want to keep the instance but clear memory, delete the stored memories for your test users via the SDK/console.
• Confirm in Billing → Reports that nothing is still accruing.

If a lab created it and you're done, delete it today — and with memory, deleting test users' data is also the right privacy hygiene.

Verified against

• Agent Engine Sessions and Memory Bank docs, ADK VertexAiSessionService / VertexAiMemoryBankService / load_memory, and the `google-cloud-aiplatform[agent_engines,adk]` SDK, June 2026 (Memory Bank was in public preview).
• Method names and parameter shapes vary by SDK version; code is syntax-checked against the docs but not executed during authoring. Pin your version.

What's next

Your agent now remembers — within and across conversations. Next:

• Lab 6 — Example Store: steer the agent's behavior with curated few-shot examples injected at runtime, improving quality without retraining.
• Cross-link: ADK Lab 2 (state & memory) built the in-memory version of this by hand; here it's the managed, persistent backend. The privacy concerns raised here are addressed further in Lab 8 (safety) and Lab 9 (identity & governance).