Agent Memory in Google ADK: Sessions and Persistent Context

Google Agent Development Kit (ADK) distinguishes between session state, which lasts for the current invocation, and memory services, which persist facts across sessions. Understanding the boundary between the two is the first step to reliable agent memory in ADK.

ADK's session management handles the in-session context automatically. The memory layer is where you need to make deliberate choices about what survives a session end and how the agent retrieves it in the next run. Tools like fenbs hold the shared project decisions and the current task list outside the ADK runtime, so every connected assistant reads the same project context regardless of which session or memory service configuration is in use.

ADK session state: in-session only

A session in ADK is a container for one conversation or one invocation sequence. The session holds the message history, the current tool call results, and any state the agent sets during the run. When the session ends, this data is no longer accessible through the session object unless a memory service has saved it.

Session state is convenient for context that only matters within one run: the file a user uploaded, the intermediate results of a multi-step plan, the last tool call output. It is not designed for context that must be available in a different session or a different agent. For that, you need a memory service.

ADK memory services: persistence across sessions

ADK's memory services are integrations that let an agent store and retrieve facts outside the session. The agent calls a memory tool to save a fact during a session. In a later session, it calls the same tool to retrieve facts relevant to the current context. The memory service manages the storage and retrieval backend.

Vertex AI provides managed memory options that integrate with ADK. Check the ADK documentation for the currently supported memory tools and their storage backends, since this is an actively developed area. Verify on the Google Cloud documentation which memory options are available for your project type and region before designing your memory architecture.

Testing memory persistence across sessions

Run a three-step test after configuring a memory service.

1. Start a session and ask the agent to save a specific fact using its memory tool.
2. End the session and start a completely new session with the same agent configuration.
3. Ask the agent to recall the fact saved in the previous session. Confirm it retrieves the correct value.

If step three returns nothing, the memory service may not be connected to the agent, the tool call in step one may not have succeeded, or the retrieval query in step three may not match the stored fact. Check the ADK logs for tool call results in both sessions. A tool call that returned an error in step one means the fact was never stored.

What session state and memory services do not cover

ADK session state and memory services handle the agent's operational context: what happened in this session and what facts has the agent accumulated over time. They do not hold the project-level shared record that a team of people and assistants works from: the current tasks, the decisions that must not be reversed, and the instructions that every assistant reads before acting.

An ADK agent working on a shared project needs both layers: a memory service for its own operational knowledge and a shared project record for the team context. See agent memory vs context for a closer look at how operational memory and project context differ.

Multi-agent memory and scope

ADK supports multi-agent pipelines where a root agent delegates to sub-agents. Each agent has its own session. Memory saved by one agent may not be automatically available to another unless they share the same memory service backend and use compatible retrieval queries.

Design memory scope deliberately in a multi-agent pipeline. Facts that every agent needs (the project goal, the standing rules) belong in a shared layer that all agents read. Facts that are specific to one agent's task (the intermediate results of a search, the draft it is working on) belong in that agent's own session or memory store. See how to build agent memory for a broader look at memory scope in multi-agent systems.

How to do this with fenbs

Use ADK's session state for in-run context and a memory service for the agent's own accumulated knowledge. Use fenbs for the shared project record that travels across agents, sessions, and team members.

1. Create a free account and add your project to fenbs. Record the standing rules as Decisions and rules and the current tasks on the board.
2. Connect your assistant from /integrations. Add a fenbs context-read step at the start of your ADK agent's session.
3. Configure a memory service for the agent's operational knowledge: check the ADK and Vertex AI documentation for supported options.
4. Run the three-step persistence test after configuring the memory service.
5. Before each session ends, ask the agent to save progress in fenbs so the next session has an accurate starting point.