Update memory to fix issue 1350- 6

docs/sessions/memory.md

@@ -1,36 +1,32 @@
-# Memory: Long-Term Knowledge with `MemoryService`
+# Memory: Long-term knowledge with `MemoryService`
 
 <div class="language-support-tag">
   <span class="lst-supported">Supported in ADK</span><span class="lst-python">Python v0.1.0</span><span class="lst-typescript">TypeScript v0.2.0</span><span class="lst-go">Go v0.1.0</span><span class="lst-java">Java v0.1.0</span><span class="lst-kotlin">Kotlin v0.1.0</span>
 </div>
 
-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`:** 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.
 
-* **`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` (or `Service` in Go) defines the interface for managing this searchable, long-term knowledge store. It supports these operations:
 
-The `BaseMemoryService` (or `Service` in Go) defines the interface for managing this searchable, long-term knowledge store. It supports four operations:
+*   **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.
 
-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.
-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.
-
-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.
-
-## Choosing the Right Memory Service
+## 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). |
+| **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.
 
@@ -82,7 +78,7 @@ The `InMemoryMemoryService` stores session information in the application's memo
     ```
 
 
-**Example: Adding and Searching Memory**
+**Example: add and search memory**
 
 This example demonstrates the basic flow using the `InMemoryMemoryService` for simplicity.
 
@@ -207,7 +203,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.
 
@@ -270,23 +266,59 @@ 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.
 
-### How It Works
+### How it works
 
 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
@@ -302,7 +334,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://<agent_engine_id>`.
+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://<agent_engine_id>`.
 
 ```bash title="bash"
 adk web path/to/your/agents_dir --memory_service_uri="agentengine://1234567890"
@@ -329,7 +361,7 @@ Or, you can configure your agent to use the Memory Bank by manually instantiatin
   )
   ```
 
-## RAG Memory
+## RAG memory
 
 The `VertexAiRagMemoryService` stores conversations in [Knowledge Engine](https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/rag-overview) and retrieves them by vector similarity. Use it when you already have RAG infrastructure or want raw transcript retrieval rather than the LLM-extracted memories produced by Memory Bank. Requires the Agent Platform SDK.
 
@@ -345,11 +377,11 @@ The `VertexAiRagMemoryService` stores conversations in [Knowledge Engine](https:
     )
     ```
 
-## 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:
 
-* `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:**
@@ -413,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
@@ -486,29 +518,29 @@ To extract memories from your session, you need to call `add_session_to_memory`.
     ```
 
 
-## Advanced Concepts
+## Advanced concepts
 
-### How Memory Works in Practice
+### 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`. 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 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`, 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?
 
 *   **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.** Nothing stops you from importing and instantiating a second `BaseMemoryService` directly. The cleanest place to consult it is from a custom tool, which already has a `ToolContext` for the framework-configured service.
+*   **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.
+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: Using Two Memory Services
+#### Example: use two memory services
 
 === "Python"