Memory has no removal path: delete_session() leaves what add_session_to_memory() copied, and BaseMemoryService exposes no way to remove it

[vasilisnasopoulos]

🔴 Required Information

Describe the Bug:

BaseSessionService has delete_session, implemented by all five session backends. BaseMemoryService has three ingestion methods and one search method, and no removal method at all:

BaseMemoryService public API: ['add_events_to_memory', 'add_memory',
                               'add_session_to_memory', 'search_memory']

Since add_session_to_memory() copies the session's content into the memory service, deleting the session leaves that copy in place with no API to remove it. A caller who deletes a session reasonably expects the conversation to be gone; it is still returned verbatim by search_memory().

The base class docstring describes the service as providing "functionality to ingest conversation history into memory so that it can be used for user queries" — it does not say the ingestion is one-way.

Steps to Reproduce:

1. pip install google-adk==2.9.0
2. Save the script under Minimal Reproduction Code as repro.py
3. python repro.py

Expected Behavior:

Either a way to remove what was ingested (for a session, a user, or a memory entry), or documentation stating that ingestion is one-way and that memory has to be cleaned up through the backend directly.

Observed Behavior:

before delete — in memory : True
after delete  — session   : gone
after delete  — in memory : STILL THERE
   retrieved verbatim    : my-passport-number-is-AB1234567

BaseMemoryService public API: ['add_events_to_memory', 'add_memory', 'add_session_to_memory', 'search_memory']
any removal method?        : False

The middle line is the negative control: the session really is deleted, so the surviving copy is the memory service's, not a stale session.

Environment Details:

• ADK Library Version: google-adk 2.9.0
• Desktop OS: macOS 26.6.2 (arm64)
• Python Version: 3.12.13

Model Information:

• Are you using LiteLLM: No
• Which model is being used: N/A — no model is involved

---

🟡 Optional Information

Additional Context — scope, stated restrictively:

• This is a gap in the abstraction, not a runtime failure. Nothing raises, and InMemoryMemoryService behaves exactly as written.
• I have not checked whether the hosted backends (Vertex AI RAG, Memory Bank) offer deletion outside ADK through their own APIs or consoles. They may well do. The asymmetry I am reporting is in ADK's own surface: one store is deletable through the abstraction and the other is not, while one feeds the other.
• I am deliberately not proposing an API shape. Whether removal is keyed by session, by user, or by memory entry is a design decision, and search_memory results do not currently carry an identifier that a delete call could take.
• I am not raising any compliance or regulatory claim; that is yours to judge. I am only showing that the two lifecycles are asymmetric and that the docstring does not say so.

Minimal Reproduction Code:

"""delete_session() removes the session; what add_session_to_memory() copied stays,
and BaseMemoryService exposes no way to remove it."""
import asyncio, inspect
from google.genai import types
from google.adk.events.event import Event
from google.adk.sessions.in_memory_session_service import InMemorySessionService
from google.adk.memory.in_memory_memory_service import InMemoryMemoryService
from google.adk.memory.base_memory_service import BaseMemoryService

SECRET = 'my-passport-number-is-AB1234567'

async def main():
    sessions, memory = InMemorySessionService(), InMemoryMemoryService()
    s = await sessions.create_session(app_name='app', user_id='u1')
    await sessions.append_event(s, Event(author='user', invocation_id='i1',
        content=types.Content(role='user', parts=[types.Part(text=SECRET)])))
    s = await sessions.get_session(app_name='app', user_id='u1', session_id=s.id)
    await memory.add_session_to_memory(s)

    hit = await memory.search_memory(app_name='app', user_id='u1', query='passport')
    print('before delete — in memory :', bool(hit.memories))

    await sessions.delete_session(app_name='app', user_id='u1', session_id=s.id)

    gone = await sessions.get_session(app_name='app', user_id='u1', session_id=s.id)
    print('after delete  — session   :', 'gone' if gone is None else 'STILL THERE')  # negative control

    hit = await memory.search_memory(app_name='app', user_id='u1', query='passport')
    print('after delete  — in memory :', 'STILL THERE' if hit.memories else 'gone')
    if hit.memories:
        print('   retrieved verbatim    :', hit.memories[0].content.parts[0].text)

    api = [n for n, _ in inspect.getmembers(BaseMemoryService, inspect.isfunction)
           if not n.startswith('_')]
    print('\nBaseMemoryService public API:', api)
    print('any removal method?        :',
          any(k in n for n in api for k in ('delete','remove','purge','forget')))

asyncio.run(main())

How often has this issue occurred?:

• Always (100%) — deterministic; no model, no network, no timing involved.

[surajksharma07]

@vasilisnasopoulos BaseMemoryService really has no removal method so what add_session_to_memory() copies just outlives the deleted session indefinitely. We sketched a session-scoped delete_session_from_memory() for InMemory that mirrors delete_session()'s own keying. Could you try it against your setup and confirm it clears what you're seeing? Heads up it's InMemory-only for now and doesn't cover Vertex AI RAG/Memory Bank or give search results an id to delete by so the real API shape is still an open call for the team. If that's not enough for your case documenting that ingestion is one-way might be the faster fix, let us know before anyone raises a PR.

[sattyamjjain]

One thing on the keying question, from having built a forget path for an agent memory store.

Session-scoped delete alone won't close this, because two of the three ingestion methods don't come from a session. add_memory and add_events_to_memory can both write with no session existing, so a delete_session_from_memory leaves those unreachable by any key at all. You end up needing entry-level removal regardless, and once you have it, session and user deletes are just queries over it.

Which puts the search_memory identifier first in the order rather than last. Until a result carries something a delete call can take, every removal API is keyed on something the caller can't observe.

For what it's worth, I shipped five forget modes (soft, hard, decay, consolidation, archive) and only hard delete needed the entry id. The other four are metadata writes. So if the worry is scope, the id unlocks the cheap ones too.

[vasilisnasopoulos]

A session-scoped delete_session_from_memory() on InMemoryMemoryService covers what I hit, so it would help. But I would not want it to land only there, and the id problem you raise is smaller than it looks.

Why not InMemory-only: the asymmetry in the report is between base classes, not implementations. BaseSessionService declares delete_session, and all four session backends answer for it (in_memory, sqlite, database, vertex_ai). BaseMemoryService declares add_session_to_memory, add_events_to_memory, add_memory, search_memory — three memory backends implement them and none can undo any of it. A concrete method on InMemoryMemoryService alone leaves the abstract contract saying ingestion is one-way while one implementation quietly is not, so anyone writing against BaseMemoryService still cannot delete. Declaring it on the base, even raising NotImplementedError in the two Vertex services, at least makes each backend answer the question.

On search results having no id to delete by: the field already exists and the write side already consumes it. MemoryEntry.id is declared at memory_entry.py:35. VertexAiMemoryBankService.add_memory documents it — "When a MemoryEntry.id is set, it is forwarded as the memory_id of the created memory" (vertex_ai_memory_bank_service.py:311) — and passes it through at :495 as memory_id=memory.id.

What is missing is only the search side filling it in. All three MemoryEntry(...) construction sites leave id unset:

• in_memory_memory_service.py:175
• vertex_ai_rag_memory_service.py:396
• vertex_ai_memory_bank_service.py:576

InMemory has the value in hand: it already dedups on event.id at in_memory_memory_service.py:128-132. Memory Bank has it too — memory.id is what it just wrote. So round-tripping the id through search_memory is a small change in each backend, and it is what turns "delete a whole session's worth" into "delete this result", without inventing an identifier scheme.

If the team would rather not commit to the API shape yet, documenting that ingestion is one-way is honest and I can work around it. But it is worth saying plainly in BaseMemoryService's own docstring rather than in a changelog, because the thing that surprised me was delete_session succeeding and returning nothing while the copy stayed searchable.

[vasilisnasopoulos]

@sattyamjjain that checks out in the signatures, which makes it more than a design opinion:

ingestion method	carries a session?
add_session_to_memory(session)	yes
add_events_to_memory(app_name, user_id, events, session_id=None)	optional
add_memory(app_name, user_id, memories)	none at all

So a delete_session_from_memory() cannot reach what add_memory wrote — not by a different key, by no key. Worth narrowing where that bites today: only VertexAiMemoryBankService implements add_memory, and add_events_to_memory is implemented by that plus InMemoryMemoryService, so sessionless writes are reachable in one backend right now. That makes it a small hole today and a guaranteed one later, which is the worse of the two — the method is public API, and the next backend to implement it inherits the hole.

And the base class has already answered the API-shape question, in this same file. add_session_to_memory and search_memory are @abstractmethod. add_events_to_memory and add_memory are not: they carry a default that raises NotImplementedError with a message naming the alternative —

raise NotImplementedError(
    "This memory service does not support direct memory writes. "
    "Call add_events_to_memory(...) or add_session_to_memory(session) "
    "instead."
)

That is exactly the shape removal wants. A non-abstract delete_memory on BaseMemoryService with that same default breaks no existing implementation, tells a caller writing against the base class what is and is not supported, and does not force the two Vertex services to answer before the team knows what the remote API can do.

Which leaves one order rather than two:

1. search_memory populates MemoryEntry.id. The field is already declared (memory_entry.py:35) and the write side already consumes it (vertex_ai_memory_bank_service.py:311, :495) — only the three construction sites leave it unset. Nothing new to design.
2. delete_memory on the base, defaulting to NotImplementedError, taking that id.
3. Session and user deletes become queries over 2, which is @sattyamjjain's point and why they should not be built first.

On the five forget modes: agreed, and that is an argument for doing 1 before anything else rather than for doing less. If four of five are metadata writes, they all still need to name the entry they are writing metadata about.

[vasilisnasopoulos]

Correcting my own numbers, which were wrong in both the report and the comment above. They understated the asymmetry.

Session services implementing delete_session: 7, not four or five — InMemorySessionService, SqliteSessionService, DatabaseSessionService, VertexAiSessionService, FirestoreSessionService, RedisSessionService, and PerAgentDatabaseSessionService (cli/utils/local_storage.py:134).

Memory services: 4, not three — I missed FirestoreMemoryService (integrations/firestore/firestore_memory_service.py:43). It implements exactly two methods, add_session_to_memory and search_memory, so it has no removal path either.

So the shape is 7 backends that can delete against 4 that cannot, and the newest memory backend inherited the gap rather than closing it — which is the part that matters more than the count.

One knock-on for the MemoryEntry.id point: there are four MemoryEntry(...) construction sites, not three (in_memory:175, vertex_ai_rag:396, vertex_ai_memory_bank:576, firestore:149), and all four leave id unset.

[surajksharma07]

@vasilisnasopoulos Checked all of that against source and it holds exactly. add_session_to_memory/search_memory are the two abstractmethods, add_events_to_memory/add_memory already use the "raise NotImplementedError naming the alternative" pattern you want for delete_memory and memory_entry.py:35 already declares id: Optional[str] = None. VertexAiMemoryBankService really does forward it on write (memory_id=memory.id on the create path) while all four search-side MemoryEntry(...) builds (in_memory:175, vertex_ai_rag ~396, vertex_ai_memory_bank ~576, firestore:149) leave it unset. So it's genuinely a "fill in a field nothing else needs to change for" not a new schema.

Corrected backend counts check out too (7 session services, 4 memory services including Firestore) so this isn't a narrow case, every memory backend inherits the gap today.

The sequencing you landed on is the right order and doesn't need us to pick a full API shape upfront: round-trip the id at those four sites, add a non-abstract delete_memory(id) on the base that defaults to NotImplementedError (same pattern as the two existing default methods), leave session/user-scoped delete as a later query over it. That's concrete enough to be a PR rather than a design doc. Want to put one up for the id round-trip + the stub? Will get it in front of the team once it's up and we can still land the docstring update in parallel if the real API takes longer than the four-site change.

[vasilisnasopoulos]

Wrote and ran it. One correction to my own plan first, because it changes the count I gave you: three of the four search sites have a durable id, not four.

VertexAiRagMemoryService does not. The events it returns are not loaded, they are rebuilt from chunk text on every search:

event = Event(author=author, timestamp=timestamp, content=content)

and Event mints a fresh uuid when id is empty (event.py:285). So id=event.id there would round-trip a handle that is different on every call and addresses nothing — worse than leaving it unset, because a caller would reasonably pass it to delete_memory. The durable handle in that backend is the RAG file behind source_display_name, not the event. I left the field unset with that written next to it rather than filling in a number that looks like an id.

The other three all have one already, and in one case it is already the identity the backend uses: InMemoryMemoryService.add_events_to_memory dedupes on event.id at in_memory_memory_service.py:128. It just never reaches the caller.

diff --git a/src/google/adk/memory/in_memory_memory_service.py b/src/google/adk/memory/in_memory_memory_service.py
@@ -132,6 +132,18 @@ class InMemoryMemoryService(BaseMemoryService):
           existing_ids.add(event.id)
       self._session_events[user_key][scoped_session_id] = existing_events
 
+  @override
+  async def delete_memory(
+      self, *, app_name: str, user_id: str, memory_id: str
+  ) -> None:
+    user_key = _user_key(app_name, user_id)
+
+    with self._lock:
+      for session_id, events in self._session_events.get(user_key, {}).items():
+        kept = [event for event in events if event.id != memory_id]
+        if len(kept) != len(events):
+          self._session_events[user_key][session_id] = kept
+
   @override
   async def search_memory(
       self, *, app_name: str, user_id: str, query: str
@@ -173,6 +185,7 @@ class InMemoryMemoryService(BaseMemoryService):
           scored_memories.append((
               matched_words,
               MemoryEntry(
+                  id=event.id,
                   content=event.content,
                   author=event.author,
                   timestamp=_utils.format_timestamp(event.timestamp),
diff --git a/src/google/adk/integrations/firestore/firestore_memory_service.py b/src/google/adk/integrations/firestore/firestore_memory_service.py
@@ -147,6 +147,7 @@ class FirestoreMemoryService(BaseMemoryService):  # type: ignore[misc]
           content = types.Content.model_validate(data["content"])
           entries.append(
               MemoryEntry(
+                  id=doc.id,
                   content=content,
                   author=data.get("author", ""),
                   timestamp=_utils.format_timestamp(data.get("timestamp", 0.0)),
diff --git a/src/google/adk/memory/vertex_ai_memory_bank_service.py b/src/google/adk/memory/vertex_ai_memory_bank_service.py
@@ -574,6 +574,7 @@ class VertexAiMemoryBankService(BaseMemoryService):
           update_time = memory.update_time
           memory_events.append(
               MemoryEntry(
+                  id=_memory_id_from_name(getattr(memory, 'name', None)),
                   author='user',
                   content=types.Content(
                       parts=[types.Part(text=fact)],
@@ -969,6 +970,19 @@ def _extract_revision_labels(
   return revision_labels
 
 
+def _memory_id_from_name(name: str | None) -> str | None:
+  """The `memory_id` component of a memory resource name.
+
+  `add_memory` forwards `MemoryEntry.id` as the `memory_id` of the created
+  memory, i.e. the last component of the resource name, so search returns that
+  same component rather than the full path.
+  """
+  if not name:
+    return None
+  return name.rsplit('/', 1)[-1] or None
+
+
 def _is_consolidation_enabled(
     custom_metadata: Mapping[str, object] | None,
 ) -> bool:
diff --git a/src/google/adk/memory/vertex_ai_rag_memory_service.py b/src/google/adk/memory/vertex_ai_rag_memory_service.py
@@ -392,6 +392,10 @@ class VertexAiRagMemoryService(BaseMemoryService):
       for events in _merge_event_lists(event_lists):
         sorted_events = sorted(events, key=lambda e: e.timestamp)
 
+        # `id` is deliberately left unset. The events above are rebuilt from
+        # chunk text on every search, so `event.id` is a fresh uuid that names
+        # nothing a caller could later address; the durable handle here is the
+        # RAG file behind `source_display_name`, not the event.
         memory_results.extend([
             MemoryEntry(
                 author=event.author,
diff --git a/src/google/adk/memory/base_memory_service.py b/src/google/adk/memory/base_memory_service.py
@@ -120,6 +120,28 @@ class BaseMemoryService(ABC):
         "instead."
     )
 
+  async def delete_memory(
+      self,
+      *,
+      app_name: str,
+      user_id: str,
+      memory_id: str,
+  ) -> None:
+    """Deletes a single memory item by its id.
+
+    The id is the one carried by `MemoryEntry.id` as returned by
+    `search_memory`. Session-scoped and user-scoped removal are queries over
+    this method rather than separate entry points.
+
+    Args:
+      app_name: The application name for memory scope.
+      user_id: The user ID for memory scope.
+      memory_id: The id of the memory item to delete.
+    """
+    raise NotImplementedError(
+        "This memory service does not support deleting individual memories."
+    )
+
   @abstractmethod
   async def search_memory(
       self,

The memory_id choice is the write side's, not mine: add_memory's docstring already says an explicit MemoryEntry.id becomes "the last component of the memory resource name", so search returns that component and a write-search-write round-trips.

Measured, against the leak from the report — main first:

main:  id = None
main:  has delete_memory = False

and with the diff applied:

search returns 2 entries
  id='e7a84134-9867-4241-91b1-539800ac5bd5'   my-passport-number-is-AB1234567
  id='6c852ef5-c2e4-4a18-9bdb-9957fe184be1'   passport office opening hours

after delete  -- secret in memory : gone
after delete  -- sibling entry    : kept
unknown id    -- entries          : 1 (was 1)

The last two lines are there on purpose: the sibling entry surviving is what says the delete is keyed on the id rather than on the query, and an unknown id changing nothing is what says a wrong handle is not a silent wipe.

tests/unittests/memory: 93 passed, 9 failed — the same 9, byte-identical list, on main (they are the test_search_memory_non_latin NFC/NFD cases, unrelated and pre-existing in this environment). tests/unittests/integrations/firestore/test_firestore_memory_service.py plus test_load_memory_tool.py and test_preload_memory_tool.py: 23 passed on both branches.

The InMemoryMemoryService.delete_memory hunk is separable — it is the only piece that closes the hole the report was about rather than just exposing the seam, so I included it, but the first four hunks stand alone if you would rather land the id round-trip and the stub and leave every implementation to its own change.

Not a pull request: I am not signing a CLA for this. Take it as a patch, or fold it into whatever branch you prefer, same as the resume and agent-name ones.

[agooll]

Thanks for the detailed report. I’m interested in helping with this issue if it is open to external contribution.

Before proposing an implementation, I’d like to confirm the intended deletion semantics. Should removal initially be scoped to an entire session, or should the API also support user-level or individual memory-entry deletion? I’d also like to confirm whether the first implementation should cover only the in-memory service or define a contract that all memory backends are expected to implement.

If maintainers agree on the scope and no one is already working on it, I’d be happy to investigate the existing memory backends, propose a minimal API, and add focused lifecycle tests before implementation.