From e2136716b8dcc9c570ef292eeb6985e582a41a36 Mon Sep 17 00:00:00 2001 From: adk-bot Date: Fri, 27 Feb 2026 00:36:09 +0000 Subject: [PATCH 1/4] docs: Document new add_memory method for direct memory management --- docs/sessions/memory.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/sessions/memory.md b/docs/sessions/memory.md index 98538c3eb4..a9660e77e5 100644 --- a/docs/sessions/memory.md +++ b/docs/sessions/memory.md @@ -16,7 +16,14 @@ Think of it this way: The `BaseMemoryService` defines the interface for managing this searchable, long-term knowledge store. Its primary responsibilities are: 1. **Ingesting Information (`add_session_to_memory`):** Taking the contents of a (usually completed) `Session` and adding relevant information to the long-term knowledge store. -2. **Searching Information (`search_memory`):** Allowing an agent (typically via a `Tool`) to query the knowledge store and retrieve relevant snippets or context based on a search query. +2. **Adding Memory Directly (`add_memory`):** In addition to ingesting entire sessions, you can directly add discrete pieces of information to the memory. This is useful for explicitly providing facts, instructions, or data that don't originate from a conversational session. + + When using `VertexAiMemoryBankService`, the `add_memory` method offers two ways to handle this: + + * **Direct Creation (`memories.create`):** By default, `add_memory` calls the underlying `memories.create` API. This treats each memory item as a distinct, new fact and adds it to the Memory Bank without any transformation. + + * **Consolidation (`memories.generate`):** If you set `enable_consolidation` to `True` in the `custom_metadata` when calling `add_memory`, the service will instead use the `memories.generate` API. This allows the Memory Bank to process and consolidate the new information with existing memories, potentially summarizing, correcting, or merging facts to maintain a more coherent and less redundant knowledge base. +3. **Searching Information (`search_memory`):** Allowing an agent (typically via a `Tool`) to query the knowledge store and retrieve relevant snippets or context based on a search query. ## Choosing the Right Memory Service From 132e049bd7e7dc8f18b242ec4c8f0a0e15430290 Mon Sep 17 00:00:00 2001 From: Zyan Date: Thu, 18 Jun 2026 13:30:46 -0600 Subject: [PATCH 2/4] 1350-6Memoryupdate.md --- docs/sessions/memory.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/sessions/memory.md b/docs/sessions/memory.md index a9660e77e5..419d0fcb9a 100644 --- a/docs/sessions/memory.md +++ b/docs/sessions/memory.md @@ -11,23 +11,23 @@ Think of it this way: * **`Session` / `State`:** Like your short-term memory during one specific chat. * **Long-Term Knowledge (`MemoryService`)**: Like a searchable archive or knowledge library the agent can consult, potentially containing information from many past chats or other sources. -## The `MemoryService` Role +## The `MemoryService` role -The `BaseMemoryService` defines the interface for managing this searchable, long-term knowledge store. Its primary responsibilities are: +The `BaseMemoryService` defines the interface for managing this searchable, long-term knowledge store. Its primary uses are: -1. **Ingesting Information (`add_session_to_memory`):** Taking the contents of a (usually completed) `Session` and adding relevant information to the long-term knowledge store. -2. **Adding Memory Directly (`add_memory`):** In addition to ingesting entire sessions, you can directly add discrete pieces of information to the memory. This is useful for explicitly providing facts, instructions, or data that don't originate from a conversational session. +1. **Ingest information (`add_session_to_memory`):** Add the contents of a completed `Session` to the long-term knowledge store. +2. **Add memory directly (`add_memory`):** Inject discrete facts, instructions, or data directly into the memory store. Use this method for structured information that does not originate from a conversational session. When using `VertexAiMemoryBankService`, the `add_memory` method offers two ways to handle this: - * **Direct Creation (`memories.create`):** By default, `add_memory` calls the underlying `memories.create` API. This treats each memory item as a distinct, new fact and adds it to the Memory Bank without any transformation. + * **Direct Creation (`memories.create`):** By default, `add_memory` calls the underlying `memories.create` API to add a memory item as a distinct fact without transformation. - * **Consolidation (`memories.generate`):** If you set `enable_consolidation` to `True` in the `custom_metadata` when calling `add_memory`, the service will instead use the `memories.generate` API. This allows the Memory Bank to process and consolidate the new information with existing memories, potentially summarizing, correcting, or merging facts to maintain a more coherent and less redundant knowledge base. -3. **Searching Information (`search_memory`):** Allowing an agent (typically via a `Tool`) to query the knowledge store and retrieve relevant snippets or context based on a search query. + * **Consolidation (`memories.generate`):** Set `enable_consolidation` to `True` in the `custom_metadata` when calling `add_memory`. The service uses the `memories.generate` API to process and consolidate the new information with existing memories. +3. **Search Information (`search_memory`):** Allows an agent (typically via a `Tool`) to query the knowledge store and retrieve relevant snippets or context based on a search query. -## Choosing the Right Memory Service +## Choose the right memory service -The ADK offers two distinct `MemoryService` implementations, each tailored to different use cases. Use the table below to decide which is the best fit for your agent. +ADK offers two distinct `MemoryService` implementations, each tailored to different use cases. Use the table below to decide which is the best fit for your agent. | **Feature** | **InMemoryMemoryService** | **VertexAiMemoryBankService** | | :--- | :--- | :--- | @@ -169,7 +169,7 @@ This example demonstrates the basic flow using the `InMemoryMemoryService` for s ``` -### Searching Memory Within a Tool +### Search memory within a tool You can also search memory from within a custom tool by using the `tool.Context`. @@ -235,7 +235,7 @@ Or, you can configure your agent to use the Memory Bank by manually instantiatin ) ``` -## Using Memory in Your Agent +## Use memory in your agent When a memory service is configured, your agent can use a tool or callback to retrieve memories. ADK includes two pre-built tools for retrieving memories: @@ -279,7 +279,7 @@ agent = Agent( ## Advanced Concepts -### How Memory Works in Practice +### How memory works in practice The memory workflow internally involves these steps: @@ -295,11 +295,11 @@ The memory workflow internally involves these steps: * **Through Standard Configuration: No.** The framework (`adk web`, `adk api_server`) is designed to be configured with one single memory service at a time via the `--memory_service_uri` flag. This single service is then provided to the agent and accessed through the built-in `self.search_memory()` method. From a configuration standpoint, you can only choose one backend (`InMemory`, `VertexAiMemoryBankService`) for all agents served by that process. -* **Within Your Agent's Code: Yes, absolutely.** There is nothing preventing you from manually importing and instantiating another memory service directly inside your agent's code. This allows you to access multiple memory sources within a single agent turn. +* **Within Your Agent's Code: Yes, absolutely.** Manually import and instantiate additional memory services to meet your specific requirements. This approach enables your agent to access multiple memory sources within a single turn. For example, your agent could use the framework-configured `InMemoryMemoryService` to recall conversational history, and also manually instantiate a `VertexAiMemoryBankService` to look up information in a technical manual. -#### Example: Using Two Memory Services +#### Example: use two memory services Here’s how you could implement that in your agent's code: From 88f0060ee8d0ed39216454c953ad27cb031e9064 Mon Sep 17 00:00:00 2001 From: Zyan Date: Wed, 8 Jul 2026 14:37:53 -0600 Subject: [PATCH 3/4] Update on memory.md according to issue #1350 - 6 Simplified dense sections, corrected markdown formatting errors, and fixed typos to align with documentation standards. Corrected some sections from the original page and the agent's PR that were a little clunky. Erased sentences inside paragraph's ,Joe's request, and included commas instead. All this while including the necessary update. --- docs/sessions/memory.md | 38 +++++++++++++++++--------------------- 1 file changed, 17 insertions(+), 21 deletions(-) diff --git a/docs/sessions/memory.md b/docs/sessions/memory.md index 3e1d1ec43b..adfc11b762 100644 --- a/docs/sessions/memory.md +++ b/docs/sessions/memory.md @@ -4,33 +4,29 @@ Supported in ADKPython v0.1.0TypeScript v0.2.0Go v0.1.0Java v0.1.0Kotlin v0.1.0 -We've seen how `Session` tracks the history (`events`) and temporary data (`state`) for a *single, ongoing conversation*. But what if an agent needs to recall information from *past* conversations? This is where the concept of **Long-Term Knowledge** and the **`MemoryService`** come into play. +While a `Session` tracks the history (`events`) and temporary data (`state`) of a single conversation, an agent may need to recall information from past interactions. This is where the concept of **Long-Term Knowledge** and the **`MemoryService`** come into play. Think of it this way: -Think of it this way: - -* **`Session` / `State`:** Like your short-term memory during one specific chat. -* **Long-Term Knowledge (`MemoryService`)**: Like a searchable archive or knowledge library the agent can consult, potentially containing information from many past chats or other sources. +* **`Session` / `State`:** It's your short-term memory during one specific chat. +* **Long-Term Knowledge (`MemoryService`)**: It's a searchable archive or knowledge library the agent can consult, potentially containing information from many past chats or other sources. ## The `MemoryService` role The `BaseMemoryService` (or `Service` in Go) defines the interface for managing this searchable, long-term knowledge store. It supports four operations: -1. **Ingesting a session (`add_session_to_memory`):** Take the contents of a (usually completed) `Session` and add relevant information to the long-term knowledge store. -2. **Ingesting events incrementally (`add_events_to_memory`):** Append a delta of events (e.g., the latest turn) without re-ingesting the full session. Useful when you want to write to memory partway through a long-running session. +1. **Ingesting a session (`add_session_to_memory`):** Take the contents of a completed `Session` and add relevant information to the long-term knowledge store. +2. **Ingesting events incrementally (`add_events_to_memory`):** Append a delta of events, for example the latest turn, without re-ingesting the full session. Useful when you want to write to memory partway through a long-running session. 3. **Writing memory items directly (`add_memory`):** Insert pre-built `MemoryEntry` items, for services that support direct writes alongside event-based extraction. -4. **Searching (`search_memory`):** Allow an agent (typically via a `Tool`) to query the knowledge store and retrieve relevant snippets based on a search query. +4. **Searching (`search_memory`):** Allow an agent, typically via a `Tool`, to query the knowledge store and retrieve relevant snippets based on a search query. Operations 2 and 3 are optional — the base class implementations of `add_events_to_memory` and `add_memory` raise `NotImplementedError`, so check your concrete service before relying on them. - When using `VertexAiMemoryBankService`, the `add_memory` method offers two ways to handle this: - The Python ADK ships three `MemoryService` implementations. Use the table below to decide which is the best fit for your agent. | **Feature** | **InMemoryMemoryService** | **VertexAiMemoryBankService** | **VertexAiRagMemoryService** | | :--- | :--- | :--- | :--- | -| **Persistence** | None (data is lost on restart) | Yes (Managed by Agent Platform) | Yes (stored in Knowledge Engine) | +| **Persistence** | None, data is lost on restart | Yes, managed by agent platform | Yes, stored in Knowledge Engine | | **Primary Use Case** | Prototyping, local development, and simple testing. | Building meaningful, evolving memories from user conversations. | Vector-search retrieval over the full conversation corpus, or alongside other RAG-indexed content. | -| **Memory Extraction** | Stores full conversation | Extracts [meaningful information](https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/generate-memories) from conversations and consolidates it with existing memories (powered by LLM) | Stores full conversation, indexed by [Knowledge Engine](https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/rag-overview). | +| **Memory Extraction** | Stores full conversation | Extracts [meaningful information](https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/generate-memories) from conversations and consolidates it with existing memories powered by LLM | Stores full conversation, indexed by [Knowledge Engine](https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/rag-overview). | | **Search Capability** | Basic keyword matching. | Advanced semantic search. | Vector similarity search over Knowledge Engine. | | **Setup Complexity** | None. It's the default. | Low. Requires an [Agent Runtime](https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/overview) instance on Agent Platform. | Medium. Requires [Knowledge Engine](https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/manage-your-rag-corpus). | | **Dependencies** | None. | Google Cloud Project, Agent Platform API | Google Cloud Project, Knowledge Engine, the Agent Platform SDK (optional install). | @@ -39,7 +35,7 @@ The Python ADK ships three `MemoryService` implementations. Use the table below `VertexAiRagMemoryService` is only exported from `google.adk.memory` when the Agent Platform SDK is installed. Memory Bank and RAG-backed memory are documented in [Memory Bank](#memory-bank) and [RAG Memory](#rag-memory) below. -## In-Memory memory +## In-memory memory The `InMemoryMemoryService` stores session information in the application's memory and performs basic keyword matching for searches. It requires no setup and is best for prototyping and simple testing scenarios where persistence isn't required. @@ -302,7 +298,7 @@ For more information on connecting to Google Cloud from ADK agents, see ### Configuration -To connect your agent to the Memory Bank, you use the `--memory_service_uri` flag when starting the ADK server (`adk web` or `adk api_server`). The URI must be in the format `agentengine://`. +To connect your agent to the Memory Bank, you use the `--memory_service_uri` flag when starting the ADK server (`adk web` or `adk api_server`). The Uniform Resource Identifier (URI) must be in the format `agentengine://`. ```bash title="bash" adk web path/to/your/agents_dir --memory_service_uri="agentengine://1234567890" @@ -349,7 +345,7 @@ The `VertexAiRagMemoryService` stores conversations in [Knowledge Engine](https: When a memory service is configured, your agent can use a tool or callback to retrieve memories. ADK includes two pre-built tools for retrieving memories: -* `PreloadMemory`: Always retrieve memory at the beginning of each turn (similar to a callback). +* `PreloadMemory`: Always retrieve memory at the beginning of each turn, similar to a callback. * `LoadMemory`: Retrieve memory when your agent decides it would be helpful. **Example:** @@ -492,12 +488,12 @@ To extract memories from your session, you need to call `add_session_to_memory`. The memory workflow internally involves these steps: -1. **Session Interaction:** A user interacts with an agent via a `Session`, managed by a `SessionService`. Events are added, and state might be updated. -2. **Ingestion into Memory:** At some point (often when a session is considered complete or has yielded significant information), your application calls `memory_service.add_session_to_memory(session)`. This extracts relevant information from the session's events and adds it to the long-term knowledge store (in-memory dictionary or Agent Runtime Memory Bank). -3. **Later Query:** In a *different* (or the same) session, the user might ask a question requiring past context (e.g., "What did we discuss about project X last week?"). -4. **Agent Uses Memory Tool:** An agent equipped with a memory-retrieval tool (like the built-in `load_memory` tool) recognizes the need for past context. It calls the tool, providing a search query (e.g., "discussion project X last week"). +1. **Session Interaction:** A user interacts with an agent via a `Session`, managed by a `SessionService`. During this interaction, events are recorded and session state is updated. +2. **Ingestion into Memory:** When a session concludes or captures significant information, your application calls `memory_service.add_session_to_memory(session)`. This action extracts key data and persists it to your long-term knowledge store, such as the Agent Runtime Memory Bank. +3. **Later Query:** In a different, or in the same session, you might ask a question requiring past context, for example, "What did we discuss about project X last week?". +4. **Agent Uses Memory Tool:** An agent equipped with a memory-retrieval tool, such as the built-in `load_memory` tool, recognizes the need for past context. It calls the tool, providing a search query (e.g., "discussion project X last week"). 5. **Search Execution:** The tool internally calls `memory_service.search_memory(app_name=..., user_id=..., query=...)`. -6. **Results Returned:** The `MemoryService` searches its store (using keyword matching or semantic search) and returns matching snippets as a `SearchMemoryResponse` containing a list of `MemoryEntry` objects (each holding `content`, optional `author`, optional `timestamp`, and optional `custom_metadata`). +6. **Results Returned:** The `MemoryService` searches its store, using keyword matching or semantic search, and returns matching snippets as a `SearchMemoryResponse` containing a list of `MemoryEntry` objects, each holding `content`, and all optional: `author`,`timestamp`, and `custom_metadata`. 7. **Agent Uses Results:** The tool returns these results to the agent, usually as part of the context or function response. The agent can then use this retrieved information to formulate its final answer to the user. ### Can an agent have access to more than one memory service? @@ -506,7 +502,7 @@ The memory workflow internally involves these steps: * **Within Your Agent's Code: Yes, absolutely.** Manually import and instantiate additional memory services to meet your specific requirements. This approach enables your agent to access multiple memory sources within a single turn. -For example, your agent can use the framework-configured `InMemoryMemoryService` for conversation history and manually instantiate a second service (a `VertexAiMemoryBankService`, a `VertexAiRagMemoryService` over a docs corpus, or any other `BaseMemoryService` implementation) for a separate knowledge base. +For example, your agent can use the framework-configured `InMemoryMemoryService` for conversation history and manually instantiate a second service, a `VertexAiMemoryBankService`, a `VertexAiRagMemoryService` over a docs corpus, or any other `BaseMemoryService` implementation, for a separate knowledge base. #### Example: use two memory services From 6b2df9fb8c28ccd2bd39b32dcd600302f28f41c4 Mon Sep 17 00:00:00 2001 From: Zyan Date: Fri, 10 Jul 2026 16:36:33 -0600 Subject: [PATCH 4/4] Update memory.md -Worked on feedback, fixed errors, changed wording slightly, and reviewed format. -Some changes were lost when I tried to resolve conflicts between branches in my last commit. I added them back here. --- docs/sessions/memory.md | 68 +++++++++++++++++++++++++++++++---------- 1 file changed, 52 insertions(+), 16 deletions(-) diff --git a/docs/sessions/memory.md b/docs/sessions/memory.md index adfc11b762..bc276d61f6 100644 --- a/docs/sessions/memory.md +++ b/docs/sessions/memory.md @@ -1,4 +1,4 @@ -# Memory: long-term knowledge with `MemoryService` +# Memory: Long-term knowledge with `MemoryService`
Supported in ADKPython v0.1.0TypeScript v0.2.0Go v0.1.0Java v0.1.0Kotlin v0.1.0 @@ -11,20 +11,20 @@ While a `Session` tracks the history (`events`) and temporary data (`state`) of ## The `MemoryService` role -The `BaseMemoryService` (or `Service` in Go) defines the interface for managing this searchable, long-term knowledge store. It supports four operations: +The `BaseMemoryService` (or `Service` in Go) defines the interface for managing this searchable, long-term knowledge store. It supports these operations: -1. **Ingesting a session (`add_session_to_memory`):** Take the contents of a completed `Session` and add relevant information to the long-term knowledge store. -2. **Ingesting events incrementally (`add_events_to_memory`):** Append a delta of events, for example the latest turn, without re-ingesting the full session. Useful when you want to write to memory partway through a long-running session. -3. **Writing memory items directly (`add_memory`):** Insert pre-built `MemoryEntry` items, for services that support direct writes alongside event-based extraction. -4. **Searching (`search_memory`):** Allow an agent, typically via a `Tool`, to query the knowledge store and retrieve relevant snippets based on a search query. +* **Ingesting Information:** + * **`add_session_to_memory`**: Takes a completed `Session` and adds relevant information to the long-term knowledge store. This approach is ideal for automatically capturing the essence of a conversation. + * **`add_memory`**: Allows you to add explicit `MemoryEntry` objects directly to the memory. This entry gives you fine-grained control and is useful for injecting specific facts from other sources. +* **Searching Information (`search_memory`):** Allowing an agent (typically via a `Tool`) to query the knowledge store and retrieve relevant snippets or context based on a search query. -Operations 2 and 3 are optional — the base class implementations of `add_events_to_memory` and `add_memory` raise `NotImplementedError`, so check your concrete service before relying on them. +## Choose the right memory service The Python ADK ships three `MemoryService` implementations. Use the table below to decide which is the best fit for your agent. | **Feature** | **InMemoryMemoryService** | **VertexAiMemoryBankService** | **VertexAiRagMemoryService** | | :--- | :--- | :--- | :--- | -| **Persistence** | None, data is lost on restart | Yes, managed by agent platform | Yes, stored in Knowledge Engine | +| **Persistence** | None, data is lost on restart | Yes, managed by the Agent Platform | Yes, stored in Knowledge Engine | | **Primary Use Case** | Prototyping, local development, and simple testing. | Building meaningful, evolving memories from user conversations. | Vector-search retrieval over the full conversation corpus, or alongside other RAG-indexed content. | | **Memory Extraction** | Stores full conversation | Extracts [meaningful information](https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/generate-memories) from conversations and consolidates it with existing memories powered by LLM | Stores full conversation, indexed by [Knowledge Engine](https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/rag-overview). | | **Search Capability** | Basic keyword matching. | Advanced semantic search. | Vector similarity search over Knowledge Engine. | @@ -266,7 +266,7 @@ You can also search memory from within a custom tool by using the tool context. --8<-- "examples/kotlin/snippets/sessions/MemoryExample.kt:search_within_tool" ``` -## Memory Bank +## Memory bank The `VertexAiMemoryBankService` connects your agent to [Memory Bank](https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/overview), a fully managed Google Cloud service that provides sophisticated, persistent memory capabilities for conversational agents. @@ -277,12 +277,48 @@ The service handles two key operations: * **Generating Memories:** At the end of a conversation, you can send the session's events to the Memory Bank, which intelligently processes and stores the information as "memories." * **Retrieving Memories:** Your agent code can issue a search query against the Memory Bank to retrieve relevant memories from past conversations. +### Direct memory ingestion with `add_memory` + +Besides generating memories from session history, `VertexAiMemoryBankService` also supports direct memory ingestion via the `add_memory` method. This method gives you precise control over the facts stored in the Memory Bank. + +How it works depends on the `enable_consolidation` option: + +* **Direct Creation (Default):** By default, `add_memory` calls the underlying `memories.create` API. Each `MemoryEntry` you provide is added as a distinct, separate memory item. + + ```python + from google.adk.memory import MemoryEntry, VertexAiMemoryBankService + from google.genai.types import Content, Part + + memory_service = VertexAiMemoryBankService(...) + + await memory_service.add_memory( + app_name="my-app", + user_id="user-123", + memories=[ + MemoryEntry(content=Content(parts=[Part(text="The user's favorite color is blue.")])) + ] + ) + ``` + +* **Creation with Consolidation:** If you set `enable_consolidation` to `True` in the `custom_metadata`, the service uses the `memories.generate` API. This setting allows the Memory Bank to intelligently consolidate the new memory items with existing related memories, preventing redundancy and building a more coherent knowledge base. + + ```python + await memory_service.add_memory( + app_name="my-app", + user_id="user-123", + memories=[ + MemoryEntry(content=Content(parts=[Part(text="The user's favorite color is light blue.")])) + ], + custom_metadata={"enable_consolidation": True} + ) + ``` + ### Prerequisites Before you can use this feature, you must have: 1. **A Google Cloud Project:** With the Agent Platform API enabled. -2. **An Agent Runtime:** You need to create an Agent Runtime on Agent Platform. You do not need to deploy your agent to Agent Runtime to use Memory Bank. This will provide you with the **Agent Runtime ID** required for configuration. +2. **An Agent Runtime:** You need to create an Agent Runtime on Agent Platform. You do not need to deploy your agent to Agent Runtime to use Memory Bank. This setup will provide you with the **Agent Runtime ID** required for configuration. 3. **Authentication:** Ensure your local environment is authenticated to access Google Cloud services. The simplest way is to run: ```bash gcloud auth application-default login @@ -409,7 +445,7 @@ When a memory service is configured, your agent can use a tool or callback to re --8<-- "examples/kotlin/snippets/sessions/MemoryExample.kt:preload_memory_agent" ``` -To extract memories from your session, you need to call `add_session_to_memory`. For example, you can automate this via a callback: +To extract memories from your session, you need to call `add_session_to_memory`. For example, you can automate this method via a callback: === "Python" ```python @@ -482,25 +518,25 @@ To extract memories from your session, you need to call `add_session_to_memory`. ``` -## Advanced Concepts +## Advanced concepts ### How memory works in practice -The memory workflow internally involves these steps: +The memory workflow includes the following steps: -1. **Session Interaction:** A user interacts with an agent via a `Session`, managed by a `SessionService`. During this interaction, events are recorded and session state is updated. +1. **Session Interaction:** A user interacts with an agent via a `Session`, managed by a `SessionService`. During this interaction, events are recorded and session state may be updated. 2. **Ingestion into Memory:** When a session concludes or captures significant information, your application calls `memory_service.add_session_to_memory(session)`. This action extracts key data and persists it to your long-term knowledge store, such as the Agent Runtime Memory Bank. 3. **Later Query:** In a different, or in the same session, you might ask a question requiring past context, for example, "What did we discuss about project X last week?". 4. **Agent Uses Memory Tool:** An agent equipped with a memory-retrieval tool, such as the built-in `load_memory` tool, recognizes the need for past context. It calls the tool, providing a search query (e.g., "discussion project X last week"). 5. **Search Execution:** The tool internally calls `memory_service.search_memory(app_name=..., user_id=..., query=...)`. -6. **Results Returned:** The `MemoryService` searches its store, using keyword matching or semantic search, and returns matching snippets as a `SearchMemoryResponse` containing a list of `MemoryEntry` objects, each holding `content`, and all optional: `author`,`timestamp`, and `custom_metadata`. +6. **Results Returned:** The `MemoryService` searches its store, using keyword matching or semantic search, and returns matching snippets as a `SearchMemoryResponse` containing a list of `MemoryEntry` objects, each holding `content`, and all optional: `author`, `timestamp`, and `custom_metadata`. 7. **Agent Uses Results:** The tool returns these results to the agent, usually as part of the context or function response. The agent can then use this retrieved information to formulate its final answer to the user. ### Can an agent have access to more than one memory service? * **Through Standard Configuration: No.** The framework (`adk web`, `adk api_server`) is designed to be configured with one memory service at a time via the `--memory_service_uri` flag. That single service is wired into the runner and exposed through `tool_context.search_memory()` and `callback_context.search_memory()`. -* **Within Your Agent's Code: Yes, absolutely.** Manually import and instantiate additional memory services to meet your specific requirements. This approach enables your agent to access multiple memory sources within a single turn. +* **Within Your Agent's Code: Yes.** You can instantiate a second `BaseMemoryService` and consult it from a custom tool, which already has a `ToolContext` for the framework-configured service. For example, your agent can use the framework-configured `InMemoryMemoryService` for conversation history and manually instantiate a second service, a `VertexAiMemoryBankService`, a `VertexAiRagMemoryService` over a docs corpus, or any other `BaseMemoryService` implementation, for a separate knowledge base.