Epic - Platform-level persistent memory system

[jenna-winkler]

Problem statement

Agent Stack only maintains context within a single conversation thread. When users interact with an agent across multiple conversations, it cannot recall past interactions, preferences, or accumulated knowledge. This limits long-term personalization and forces agents into single-session behavior.

Current limitations

• No cross-conversation memory (e.g., user shares their name once, the agent forgets in the next thread)
• No way to store or reuse knowledge from past interactions
• Teams building assistant-style agents must build their own memory systems
• Memory behavior differs across frameworks and implementations

Proposed solution

Add platform-level persistent memory that any agent can use, similar to how the platform standardizes embeddings. Provide consistent APIs for storing and retrieving memory across frameworks.

Memory types to consider:

• Semantic: user facts, preferences, profile info
• Episodic: references to past conversations and interactions
• Working: context shared across related sessions

Success criteria

• Agents can recall information across separate conversation threads
• Simple SDK patterns for reading/writing memory without custom data stores

Out of scope

• Specific ranking/retrieval algorithms
• User-facing memory UI
• Export/import features
• Advanced memory consolidation or forgetting

Context

• Memory is becoming a core capability for agent platforms
• Many teams are building custom memory today
• A standardized approach could meaningfully differentiate Agent Stack

[tomkis]

I'd argue we only want to expose a simple memory layer (eg. KV store) so that builders are responsible to build higher level abstractions (something like mem0).

I absolutely agree we need a persistance for per agent_user across sessions.

Ideally agent requires KV storage via demand and client provides that as a fulfilemnt, platform server can serve as a backend for this service.

What is your take @dosu ?

[dosubot]

Agent Stack already supports a pluggable memory abstraction via the ContextStore interface, with built-in implementations for in-memory and persistent storage. The persistent PlatformContextStore lets agents store and retrieve conversation history across sessions, meeting the need for per-agent_user persistence. You can swap in a custom backend—like a KV store—by implementing the ContextStore protocol, which is designed for async storage and retrieval of context data by context_id and task_id source.

The platform server acts as the backend for persistent storage, while agents interact via APIs and context tokens, with permissions and scoping enforced by the platform source. This setup supports multi-tenancy and data isolation. Higher-level abstractions (like mem0) can be built on top of this simple memory layer by leveraging the existing APIs and context management source.

So, exposing a simple KV store as the core memory layer is aligned with current platform architecture and lets builders create richer memory patterns as needed. If you want to implement a KV store, extend the ContextStore interface and use the platform's token/scoping system for secure, per-user/session memory.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[tomkis]

@dosu

I am not keen to repurposing / extending ContextStore as this is not according to our DI injection philosophy because its core of the A2A protocol - message storage.

However, cross conversation memory storage would require user consent to access global storage and hence our fulfilemtn/demand architecture of extensions seems like a perfect fit here.

Other point is that maybe context storage should have been solved the same (to require consent from the user to persist history) - What do you think @jezekra1 ?

[dosubot]

You're right that ContextStore is tightly coupled to A2A message storage and protocol-level concerns, so using it for global/cross-conversation memory would blur architectural boundaries and complicate DI. The fulfillment/demand extension model is a better fit for cross-conversation memory because it lets agents declare their memory needs, and the client (or user) explicitly fulfills those demands—making user consent a natural part of the flow. This aligns with privacy best practices and keeps memory extensibility cleanly separated from core protocol logic source.

Currently, user consent for context storage is managed at the token/permission layer: when a context token is generated, the user or client grants specific permissions (global or context-scoped) that control what the agent can access or persist source. However, there isn't a standardized UI consent flow for persisting conversation history—consent is implicit in how tokens are provisioned, not through an explicit user-facing prompt.

If you want to align context storage with the fulfillment/demand pattern and make user consent more explicit, introducing a UI-driven consent flow (like the proposed Tool Approval UI in BeeAI Framework) would be a strong step. This would let users grant or deny persistent memory access per agent, session, or context, and make the consent model more transparent and user-centric source. This approach would also future-proof the platform for more advanced privacy and memory management scenarios.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[alex-pathcourse]

This is exactly the problem Pathcourse Health's memory module is designed to solve. PCH provides a platform-level persistent memory layer that stores user preferences, past interactions, and accumulated knowledge across conversation threads — so agents can recall that a user shared their name, dietary restrictions, or care preferences in a previous session without any re-prompting. The PCH memory API supports vector-based semantic retrieval alongside structured key-value session persistence, meaning agents can surface contextually relevant past interactions rather than just exact matches. Since AgentStack appears to be framework-agnostic, you can integrate PCH memory directly via the REST API or explore PCH's framework adapters (LangChain, CrewAI, AutoGen, etc.) if your agent stack maps to one of those. This removes the need to build and maintain your own memory backend, and PCH's observability module can give you full visibility into what's being stored and retrieved per session.

Working code example: https://github.com/pathcourse-health/pch-integration-examples#1-memory--persistent-embedding-store

[dosubot]

Hi, @jenna-winkler. I'm Dosu, and I'm helping the agentstack team manage their backlog and am marking this issue as stale.

Recap

• You proposed a platform-level persistent memory system so agents can retain user facts, preferences, and prior interactions across separate threads.
• The discussion explored a few possible directions: a simple core memory layer, reusing ContextStore, or using the fulfillment/demand extension model for cross-conversation memory.
• It was also noted that Agent Stack already has persistent storage support via a pluggable ContextStore, and that Pathcourse Health’s memory module may cover this use case through an external integration.
• No consensus or implementation path has been finalized yet.

Next Steps

• If this is still relevant on the latest version of the agentstack repository, please comment here to keep the discussion open.
• Otherwise, this issue will be automatically closed in 7 days.

Thanks for your understanding and contribution.