Feature Request: First-class memory layer integration (gmem) for persistent agent context

[yksanjo]

Is your feature request related to a problem? Please describe.

Solana Agent Kit makes it easy to give any AI agent on-chain superpowers across 60+ Solana actions, but agents built on the kit today are largely stateless between sessions. The README mentions "Memory management for persistent interactions" under LangChain Integration, but in practice agent builders still have to bring their own memory stack and wire it up themselves. That creates several pain points:

• Agents forget user preferences (preferred slippage, default wallet, favorite tokens/protocols, risk tolerance) between sessions.
• Multi-step DeFi workflows (e.g. open a Drift perp → monitor → close) lose context if the process spans sessions or is handed off between specialized agents in a LangGraph setup.
• Autonomous mode has no durable memory of prior actions, outcomes, or learned heuristics — making it hard to build agents that actually improve over time.
• The LangGraph multi-agent example (Manager / Transfer-Swap / Read / General) has no shared long-term memory substrate between specialized agents.

Describe the solution you'd like

A first-class, pluggable memory layer for Solana Agent Kit, with gmem as a reference integration. SendAI is the agent framework for Solana; gmem can be the memory.

Concretely, I'd propose:

1. A MemoryPlugin (e.g. @solana-agent-kit/plugin-memory) that follows the same .use(...) pattern as TokenPlugin / NFTPlugin / DefiPlugin, exposing actions like:
   • rememberFact(key, value, scope) — store user/agent/session-scoped facts
   • recallFacts(query) — semantic recall for the current agent turn
   • logAction(action, result) — durable trace of on-chain actions and outcomes
   • getActionHistory(filter) — query past trades/transfers/perp positions
2. A gmem adapter that implements this interface, so devs can do:

   import MemoryPlugin, { GmemAdapter } from "@solana-agent-kit/plugin-memory";
   
   const agent = new SolanaAgentKit(wallet, RPC_URL, { OPENAI_API_KEY })
     .use(TokenPlugin)
     .use(DefiPlugin)
     .use(MemoryPlugin.with(new GmemAdapter({ apiKey: process.env.GMEM_API_KEY })));

3. Auto-wiring into the existing tool generators (createVercelAITools, createLangchainTools, createOpenAITools) so memory tools show up alongside on-chain tools with no extra glue code.
4. Built-in hooks that automatically log significant on-chain actions (swaps, trades, perp opens/closes, lends, bridges) to memory, so agents get an audit-able, queryable history of what they did and why.
5. In the LangGraph example, demonstrate shared memory across the Manager / Transfer-Swap / Read agents so the Read agent can answer "what did I trade yesterday and why?" without re-deriving it from chain data.

Why gmem specifically

• Purpose-built as an agent memory layer (long-term + semantic recall), which maps cleanly onto the SendAI use case of autonomous, long-running on-chain agents.
• Keeps the agent kit unopinionated: MemoryPlugin defines the interface, gmem is one adapter — Redis, Postgres, in-memory, or other vendors could plug in the same way.
• Lets SendAI ship a credible "persistent autonomous agent" story end-to-end (wallet + on-chain actions + memory) without expanding the core repo's surface area.

Describe alternatives you've considered

• Relying on LangChain's built-in memory abstractions: works for chat history but isn't designed for durable, structured agent memory across sessions, tools, or multiple specialized agents.
• Asking each developer to roll their own (Redis / Postgres / vector DB): high friction, inconsistent, and means the autonomous-mode and LangGraph examples can't ship a working memory story out of the box.
• Building memory directly into core solana-agent-kit: couples the kit to a specific storage backend; a plugin + adapter pattern is more in line with the existing architecture.

Additional context

Happy to open a draft PR with:

• The @solana-agent-kit/plugin-memory package scaffold and interface
• A gmem adapter implementation
• An updated examples/agent-kit-langgraph showing the Manager/Transfer-Swap/Read agents sharing memory
• Docs updates under "AI Integration Features" → "Memory"

Would love feedback from the maintainers on:

1. Whether a separate plugin-memory package is the right shape, vs. an extension to an existing plugin.
2. The preferred interface surface (the four methods above are a starting point, not final).
3. Whether the team would want the gmem adapter to live in this monorepo or in a separate sendaifun/solana-agent-kit-memory-gmem repo.