Feature: Persistent agent memory — agents forget everything across sessions

Problem

Composio agents have no persistent memory across sessions. Every composio.create(user_id="...") starts from scratch — the agent can use 1000+ tools, but it cannot remember what it learned in a previous session. If an agent spent 20 turns debugging a GitHub issue, discovered the root cause, and fixed it, the next session has zero knowledge of that.

This is the single biggest gap I have felt while building with Composio. The session model is great for tool execution and auth scoping, but there is no memory layer underneath it.

Current workarounds and why they fall short

1. Stuff everything into the system prompt — hits context window limits fast, and the agent cannot selectively retrieve relevant past experiences.

2. External vector DB (Pinecone, Weaviate, etc.) — works but adds significant infrastructure. You need an embedding model, a running service, and latency for every retrieval. For a lot of agent use cases this is overkill.

3. Store in user's Notion/Google Docs via Composio tools — hacky. The agent writes notes to a doc and re-reads them next session. No relevance ranking, no structured retrieval, no concept of verified vs unverified knowledge.

What would be useful

A way for agents to store and retrieve memories within the Composio session lifecycle, without requiring external infrastructure. Ideally:

• After executing a tool, the agent can store what it learned (e.g., "the failing test was caused by an expired OAuth token")
• Before acting in a new session, the agent searches past memories relevant to the current task
• Memories have metadata: category, confidence, source, timestamp
• Works with the existing @composio.experimental.tool() and ExperimentalToolkit patterns so it feels native to the SDK

Suggested approach

I have been building cognicore-env — a persistent memory layer for AI agents that uses BM25 retrieval instead of embeddings. No vector DB, no embedding server, pure Python stdlib for the retrieval engine. It also has a memory transfer system where verified memories (backed by proof — command, result, exit code) can be exported/imported between agents with content hashing and chain of custody.

I think there are two ways this could integrate:

1. Example integration — add examples/cognicore_memory.py showing how to give any Composio agent persistent memory using @composio.experimental.tool() + CogniCore's TFIDFMemoryBackend as a custom toolkit. No changes to Composio core, just demonstrates the pattern.

2. Native memory toolkit — register a memory toolkit in Composio's backend alongside Gmail, GitHub, etc. so every session gets MEMORY_STORE, MEMORY_SEARCH, MEMORY_REFLECT tools out of the box.

I am happy to contribute either approach. Option 1 is a PR I can open immediately. Option 2 would need discussion about whether this belongs in the SDK or the backend.

Benchmark context

On LongMemEval, BM25 retrieval (what CogniCore uses) outperformed embeddings at small context sizes: 78.8% → 85.2% at 5 chunks, 87.2% → 92.8% at 10 chunks, converging at 95% at 20 chunks. The point is that for agent memory (where you typically retrieve 5-10 relevant items, not 1000), lightweight BM25 is competitive with heavy vector infrastructure.

Open questions for maintainers

• Is persistent agent memory something you see as part of Composio's scope, or do you consider it the application layer's responsibility?
• Would you accept an example PR demonstrating the pattern, even if you do not want memory in core?
• Is there a roadmap for session-level state beyond the current session_id reuse?

Happy to discuss before writing any code.