Need some clarity on fast api and sessions

[pabhero]

I want to deploy my agent to GKE. If I pass the VertexAiSessionService URI to the get_fast_api_app function will the agent automatically start managing sessions and creating memories without any further intervention? Would additional memory related code just be for custom use cases at that point? Or do I still need to use these callbacks

Alternatively can I use Runners directly? The docs seem to imply that we should be exposing a root_agent but if I need to manage sessions manually outside of AI Engine it seems like this section suggests that we should be using Runners directly.

Or, you can configure your agent to use the Memory Bank by manually instantiating the VertexAiMemoryBankService and passing it to the Runner.

Is ADK meant to be used like a library within existing services or are we supposed to use the existing fast api app?

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: Passing the --memory_service_uri flag to the adk web or adk api_server command does automatically configure the VertexAiMemoryBankService, but you still need to explicitly use tools and callbacks in your agent to load and save memories. ADK is a flexible framework that can be used as a high-level server via get_fast_api_app for quick deployments, or as a library by using Runners directly within your existing application for more control.

---

Hello! That's a great set of questions that gets to the core of how to best use ADK for production deployments. Let's break it down.

1. Automatic Session and Memory Management

When you use the adk web or adk api_server commands and pass a --memory_service_uri, ADK automatically detects the service URI and instantiates the correct service for you. However, there's a distinction between the Session Service and the Memory Service.

• VertexAiSessionService: This manages the short-term conversational state (like the history of events in a single user session). When you deploy to Google Cloud Agent Engine, this is used automatically to persist conversations.
• VertexAiMemoryBankService: This is for long-term, semantic memory that is consolidated from many conversations and persists across sessions. To use it, you need to do two things:
  1. Retrieve memories: Add a tool like PreloadMemoryTool to your agent's before_agent_prompt to search for relevant memories at the start of a turn.
  2. Save memories: Use an after_agent_callback to explicitly save the conversation to the memory bank using add_session_to_memory. [1]

So, while the service is configured automatically, you still need to add a little bit of code to your agent to tell it when and how to use the memory bank.

2. get_fast_api_app vs. Using Runners Directly

You are correct! You have two primary options for structuring your application:

• High-Level (using get_fast_api_app): This is the quickest way to get started. By defining a root_agent in your agent.py, the adk command-line tools can automatically discover it, create a Runner, and wrap it in a FastAPI server for you. This is ideal for many use cases and for rapid development.
• Library Mode (using Runner directly): For more complex scenarios or when integrating ADK into an existing application, you can instantiate the Runner, SessionService, and MemoryService yourself. This gives you complete control over the application structure and lifecycle. The documentation shows examples of this pattern precisely for this reason. [1] [2]

Choosing between them is a matter of control vs. convenience.

3. ADK: A Library or a Framework?

ADK is designed to be both. At its core, it is a flexible and modular Python library for building and orchestrating agents. [3] It provides the fundamental building blocks (Agent, Tool, Runner, Service) that you can integrate into any application. [4]

However, it also provides a powerful framework—including the get_fast_api_app helper and command-line tools—to handle the boilerplate of setting up a production-ready web server, allowing you to focus on the agent's logic. You can even extend the FastAPI app it generates with your own custom endpoints (e.g., for health checks).

For your GKE deployment, either approach is valid. You can containerize the app generated by adk api_server or build your own container with a custom server that uses ADK as a library.

I hope this clarifies things!

---

References:
[1] ADK Docs: Using Memory in Your Agent
[2] ADK Docs: Tutorials
[3] ADK Project Overview
[4] ADK Docs: Deploying Agents