Summary
SQLSpecMemoryService.search_memory() currently scopes every lookup to exactly (app_name, user_id). There is no way to store or recall memory entries shared across the users of an application, even though the ADK session model already distinguishes app: and user: state (persisted in separate adk_app_state / adk_user_state tables).
Request
Add an optional scope dimension to the memory store and service, mirroring the session-state split:
MemoryRecord gains a scope ("user" default, "app") or an equivalent nullable-user_id convention.add_memories(...) accepts the scope when writing.search_memory(app_name=..., user_id=..., query=...) matches user-scoped entries plus app-scoped entries for the same app_name, with results labeled by scope.- Age-based retention (
delete_entries_older_than) accepts an optional scope filter so shared knowledge can be retained on a different schedule than per-user memory.
Motivation
Multi-user applications often have facts that belong to the application or a shared context rather than one user (domain glossaries, shared conclusions). Today the only options are seeding under a sentinel user id (bends the identity model, invisible to other users' searches) or duplicating entries per user (write amplification, retention drift). A first-class scope keeps the (app_name, user_id) contract intact for user memory while making shared recall possible.
Notes
Backward compatible: default scope "user" preserves current behavior; existing rows need only a defaulted column. Applies to the async and sync stores and all adapter implementations.
Summary
SQLSpecMemoryService.search_memory()currently scopes every lookup to exactly(app_name, user_id). There is no way to store or recall memory entries shared across the users of an application, even though the ADK session model already distinguishesapp:anduser:state (persisted in separateadk_app_state/adk_user_statetables).Request
Add an optional scope dimension to the memory store and service, mirroring the session-state split:
MemoryRecordgains ascope("user"default,"app") or an equivalent nullable-user_idconvention.add_memories(...)accepts the scope when writing.search_memory(app_name=..., user_id=..., query=...)matches user-scoped entries plus app-scoped entries for the sameapp_name, with results labeled by scope.delete_entries_older_than) accepts an optional scope filter so shared knowledge can be retained on a different schedule than per-user memory.Motivation
Multi-user applications often have facts that belong to the application or a shared context rather than one user (domain glossaries, shared conclusions). Today the only options are seeding under a sentinel user id (bends the identity model, invisible to other users' searches) or duplicating entries per user (write amplification, retention drift). A first-class scope keeps the
(app_name, user_id)contract intact for user memory while making shared recall possible.Notes
Backward compatible: default scope
"user"preserves current behavior; existing rows need only a defaulted column. Applies to the async and sync stores and all adapter implementations.