I enjoy building with new frameworks and services. Do you? It’s fun to break new ground. That said, I’m often filled with regret as a I navigate incomplete docs, non-existent search results, and a dearth of human experts to bother. Now add LLMs that try to help but accidentally set you back. Good times. But we persevere. My goal? Build an AI agent—it helps you plan a career change—that retains memory through long-running conversations, and is portable enough that it can run on most any host. Easy enough, yes?
My weapons of choice were the Agent Development Kit (Python), the new fully-managed Vertex AI Memory Bank service, and runtime hosts including Google Cloud Run and Vertex AI Agent Engine. Most every sample I found for this tech combination was either PhD level coding with excessive functionality, a hard-coded “hello world” that didn’t feel realistic, or a notebook-like flow that didn’t translate to an independent agent. I craved a simple, yet complete, example of what a real, hosted, and memory-infused agent looks like. I finally got it all working, it’s very cool, and wanted to share steps to reproduce it.
Let’s go through this step by step, and I’ll explain the various gotchas and such that weren’t clear from the docs or existing samples. Note that I am NOT a Python developer, but I think I follow some decent practices here.
First, I wanted a new Python virtual environment for the folder containing my app.
python3 -m venv venv
source venv/bin/activate
I installed the latest version of the Google ADK.
pip install google-adk
My source code is here, so you can just download the requirements.txt file and install the local dependencies you need.
pip install -r requirements.txt
I’ve got an __init__.py file that simply contains:
from . import agent
Now the agent.py itself where all the logic lives. Let’s go step by step, but this all is from a single file.
import os
import sys
from google.adk.agents import Agent
from google.adk.tools import agent_tool
from google.adk.tools import google_search
from google import adk
from google.adk.runners import Runner
from google.adk.sessions import VertexAiSessionService
from google.adk.memory import VertexAiMemoryBankService
from google.api_core import exceptions
Nothing earth-shattering here. But I use a mix of built-in tools including Google Search. And I’m using durable storage for sessions and memory (versus the default in-memory options) and importing those references.
app_name = 'career_agent'
# Retrieve the agent engine ID needed for the memory service
agent_engine_id = os.environ.get("GOOGLE_CLOUD_AGENT_ENGINE_ID")
Our agent app needs a name for the purpose of storing sessions and memory through ADK. And that agent_engine_id is important for environments where it’s not preloaded (e.g. outside of Vertex AI Agent Engine).
# Create a durable session for our agent
session_service = VertexAiSessionService()
print("Vertex session service created")
# Instantiate the long term memory service, needs agent_engine parameter from environment or doesn't work right
memory_service = VertexAiMemoryBankService(
agent_engine_id=agent_engine_id)
print("Vertex memory service created")
Here I create instances of the VertexAiSessionService and VertexAiMemoryBankService. These refer to fully managed, no ops needed, services that you can use standalone wherever your agent runs.
# Use for callback to save the session info to memory
async def auto_save_session_to_memory_callback(callback_context):
try:
await memory_service.add_session_to_memory(
callback_context._invocation_context.session
)
print("\n****Triggered memory generation****\n")
except exceptions.GoogleAPICallError as e:
print(f"Error during memory generation: {e}")
Now we’re getting somewhere. This function (thanks to my colleague Megan who I believe came up with it) will be invoked as a callback during session turns.
# Agent that does Google search
career_search_agent_memory = Agent(
name="career_search_agent_memory",
model="gemini-2.5-flash",
description=(
"Agent answers questions career options for a given city or country"
),
instruction=(
"You are an agent that helps people figure out what types of jobs they should consider based on where they want to live."
),
tools=[google_search],
)
That’s agent number one. It’s a secondary agent that just does a real-time search to supplement the LLM’s knowledge with real data about a given job in a particular city.
# Root agent that retrieves memories and saves them as part of career plan assistance
root_agent = Agent(
name="career_advisor_agent_memory",
model="gemini-2.5-pro", # Using a more capable model for orchestration
description=(
"Agent to help someone come up with a career plan"
),
instruction=(
"""
**Persona:** You are a helpful and knowledgeable career advisor.
**Goal:** Your primary goal is to provide personalized career recommendations to users based on their skills, interests, and desired geographical location.
**Workflow:**
1. **Information Gathering:** Your first step is to interact with the user to gather essential information. You must ask about:
* Their skills and areas of expertise.
* Their interests and passions.
* The city or country where they want to work.
2. **Tool Utilization:** Once you have identified a potential career and a specific geographical location from the user, you **must** use the `career_search_agent_memory` tool to find up-to-date information about job prospects.
3. **Synthesize and Respond:** After obtaining the information from the `career_search_agent_memory` tool, you will combine that with the user's stated skills and interests to provide a comprehensive and helpful career plan.
**Important:** Do not try to answer questions about career options in a specific city or country from your own knowledge. Always use the `career_search_agent_memory` tool for such queries to ensure the information is current and accurate.
"""
),
tools=[adk.tools.preload_memory_tool.PreloadMemoryTool(), agent_tool.AgentTool(career_search_agent_memory), ],
after_agent_callback=auto_save_session_to_memory_callback,
)
That’s the root agent. Let’s unpack it. I’ve got some fairly detailed instructions to help it use the tool correctly and give a good response. Also note the tools. I’m preloading memory so that it gets context about existing memories, even if they happened five sessions ago. It’s got a tool reference to that “search” agent I defined above. And then after the agent generates a response, we save the key memories to the Memory Bank.
runner = Runner(
agent=root_agent,
app_name=app_name,
session_service=session_service,
memory_service=memory_service)
Finally, I’ve got a Runner. I’m not positive this is even used when the agent runs on Vertex AI Agent Engine, but it plays a part when running elsewhere.
That’s it. 87 lines in one file. Writing the code wasn’t the hard part; knowing what to do and how to shape the agent was where all the work happened.
Let’s deploy, and test it all out with cURL commands. To deploy this to the fully-managed Vertex AI Agent Engine, it’s a single ADK command now. You need to provide it a Cloud Storage bucket name (for storing artifacts), but that’s about it.
adk deploy agent_engine \
--project=seroter-project-base \
--region=us-central1 \
--staging_bucket=gs://seroter-agent-memory-staging \
--display_name="Career Agent with Memory" \
--trace_to_cloud \
career_agent_memory/
When this finishes, I saw a bucket loaded up with code and other artifacts.
More importantly, I had an agent. Vertex AI Agent Engine has a bunch of pre-built observability dashboards, and an integrated view of sessions and memory.
Let’s use this agent, and see if it does what it’s supposed to. I’m going to use cURL commands, so that it’s super clear as to what’s happening.
curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://us-central1-aiplatform.googleapis.com/v1/projects/seroter-project-base/locations/us-central1/reasoningEngines/8479666769873600512:query \
-d '{"class_method": "create_session", "input": {"user_id": "u_123"},}'
This first command creates a new session for our agent chat. The authorization comes from injecting a Google Cloud token into the header. I plugged in the “resource name” of the Agent Engine instance into the URI and set a user ID. I get back something like this:
{
"output": {
"userId": "u_123",
"id": "5926526278264946688",
"events": [],
"appName": "8479666769873600512",
"state": {},
"lastUpdateTime": 1760395538.0874159
}
}
That “id” value matches the session ID now visible in the Vertex AI Session list. This session is for the given user, u_123.
Now I can chat with my career agent. Here’s the cURL request for submitting a query. This will trigger my root agent, call my secondary agent, and store the key memories of the interaction as a callback.
curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://us-central1-aiplatform.googleapis.com/v1/projects/seroter-project-base/locations/us-central1/reasoningEngines/8479666769873600512:streamQuery?alt=sse \
-d '{"class_method": "stream_query","input": {"user_id": "u_123","session_id": "5926526278264946688","message": "I am currently a beekeeper in New Mexico. I have been to college for economics, but that was a long time ago. I am thinking about moving to Los Angeles CA and get a technology job. What are my job prospects in that region and how should I start?",}}'
Note that the engine ID is still in the URI, and payload contains the user ID and session ID. What I got back was a giant answer with some usable advice on how I can take my lucrative career as a beekeeper and make my mark on the technology sector.
What got automatically saved as a memory? Switching to the Memories view in Vertex AI, I see that a few key details about my context were durably stored.
Now if I delete my session, come back tomorrow and start a new one, any memories for this user ID (and agent engine instance) will be preloaded into every agent request. Very cool!
Let’s quickly prove it. I can destroy my session with this cURL command.
curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://us-central1-aiplatform.googleapis.com/v1/projects/168267934565/locations/us-central1/reasoningEngines/8479666769873600512:query?alt=sse \
-d '{"class_method": "delete_session","input": {"user_id": "u_123","session_id": "5926526278264946688",}}'
No more session, but my Memories remain. I can then request another session (for the same user) using the earlier command:
curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://us-central1-aiplatform.googleapis.com/v1/projects/seroter-project-base/locations/us-central1/reasoningEngines/8479666769873600512:query \
-d '{"class_method": "create_session", "input": {"user_id": "u_123"},}'
At this point, I could ask something like “what do you already know about me?” in my query to see if it retrieves the memories it stored before.
curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://us-central1-aiplatform.googleapis.com/v1/projects/seroter-project-base/locations/us-central1/reasoningEngines/8479666769873600512:streamQuery?alt=sse \
-d '{"class_method": "stream_query","input": {"user_id": "u_123","session_id": "3132042709481553920","message": "What do you already know about me?",}}'
Here’s what I got back:
{"content": {"parts": [{"thought_signature": "CrgEAR_M...twKw==", "text": "You have an economics degree and are currently a beekeeper in New Mexico. You're considering a move to Los Angeles for a job in the technology sector."}], "role": "model"}, "finish_reason": "STOP", "usage_metadata": {"candidates_token_count": 32, "candidates_tokens_details": [{"modality": "TEXT", "token_count": 32}], "prompt_token_count": 530, "prompt_tokens_details": [{"modality": "TEXT", "token_count": 530}], "thoughts_token_count": 127, "total_token_count": 689, "traffic_type": "ON_DEMAND"}, "avg_logprobs": -0.8719542026519775, "invocation_id": "e-53e94a44-ad6b-4e97-9297-51612f4e77a9", "author": "career_advisor_agent_memory", "actions": {"state_delta": {}, "artifact_delta": {}, "requested_auth_configs": {}, "requested_tool_confirmations": {}}, "id": "c9e484cd-e5f7-4e1e-94d7-7490a006137d", "timestamp": 1760396342.830469}
Excellent! With this approach, I have zero database management to do, yet my agents can retain context for each turn over an extended period of time.
Vertex AI Agent Engine is cool, but what if you want to serve up your agents on a different runtime? Maybe a VM, Kubernetes, or the best app platform available, Google Cloud Run. We can still take advantage of managed sessions and memory, even if our workload runs elsewhere.
The docs don’t explain how to do this, but I figured out the first step. You need that Agent Engine ID. When deploying to Vertex AI Agent Engine, it happened automatically. But now I need to explicitly submit an HTTP request to get back an ID to use for my agent. Here’s the request:
curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/168267934565/locations/us-central1/reasoningEngines \
-d '{"displayName": "memory-bank-for-cloud-run"}'
I get back an ID value, and I see a new entry show up for me in Vertex AI Agent Engine.
The ADK also supports Google Cloud Run as a deployment target, so I’ll deploy this exact agent, no code changes, there too. First, I threw a few values into the shell’s environment variables to use for the CLI command.
export GOOGLE_CLOUD_PROJECT=seroter-project-base
export GOOGLE_CLOUD_LOCATION=us-central1
export GOOGLE_GENAI_USE_VERTEXAI=True
Then I issued the single request to deploy the agent to Cloud Run. Notice some different things here. First, no Cloud Storage bucket. Cloud Run creates a container from the source code and uses that. Also, I explicitly set the –memory_service_uri and –session_service_uri to enable some of the pre-wiring to those services. It didn’t work without it, and the current docs don’t include the proper parameters. And I also figured out (undocumented) how to add Cloud Run environment variables, since the Agent Engine ID was also needed there.
adk deploy cloud_run \
--project=$GOOGLE_CLOUD_PROJECT \
--region=$GOOGLE_CLOUD_LOCATION \
--service_name=career-agent \
--app_name=career_agent \
--port=8080 \
--memory_service_uri=agentengine://8058017254761037824 \
--session_service_uri=agentengine://8058017254761037824 \
career_agent_memory/ \
-- --set-env-vars "GOOGLE_CLOUD_AGENT_ENGINE_ID=8058017254761037824"
In just a couple minutes, I ended up with an agent ready to serve on Cloud Run.
The URLs I use to interact with my agent are now different because we’re not calling the managed service endpoints of Vertex AI to invoke the agent. So if I want a new session to get going, I submit a cURL request like this:
curl -X POST -H "Content-Type: application/json" -d '{}' \
https://career-agent-168267934565.us-central1.run.app/apps/career_agent/users/u_456/sessions
I’ve got no payload for this request, and specified the user name in the URL. I got back a session ID in a JSON payload like above. And I can see that session registered in my Agent Engine console.
Submitting queries to this agent is slightly different than when it was hosted in Vertex AI Agent Engine. For Cloud Run agents, the cURL request looks like this:
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://career-agent-168267934565.us-central1.run.app/run_sse \
-H "Content-Type: application/json" \
-d '{
"app_name": "career_agent",
"user_id": "u_456",
"session_id": "311768995957047296",
"new_message": {
"role": "user",
"parts": [{
"text": "I am currently a cowboy in Las Vegas. I have been to college for political science, but that was a long time ago. I am thinking about moving to San Francisco CA and getting a technology job. What are my job prospects in that region and how should I start?"
}]
},
"streaming": false
}'
After a moment, not only do I get a valid answer from my agent, but I also see that the callback fired and I’ve got durable memories in Vertex AI Memory Bank.
Just like before, I could end this session, start a new one, and the memories still apply . Very nice.
Access to sessions and memories that scale as your agent does, or survive compute restarts, seems like a big deal. You can use your own database to store these, but I like having a fully managed option that handles every part of it for me. Once you figure out the correct code and configurations, it’s fairly easy to use. You can try this all yourself in Google Cloud with your existing account, or a new account with a bunch of free credits.
Richard Seroter's Architecture Musings 