Compatibility
Memnode fits where agent builders already work
Use Memnode through MCP for coding agents, through the hosted HTTP API for app backends, or as a memory backend inside a framework like LangChain or the Vercel AI SDK.
MCP clients
Best for Claude Code, Cursor, and local coding workflows that want persistent repo memory.
Hosted HTTP API
Best for deployed agents, app backends, support workflows, and shared team memory.
Framework wrappers
Best when orchestration already lives in LangChain, the Vercel AI SDK, or custom middleware.
LangChain example: Memnode as the memory backend
import { ChatOpenAI } from '@langchain/openai'
import { createAgent } from 'langchain'
import { MemnodeClient } from '@memnode/client'
const llm = new ChatOpenAI({ model: 'gpt-5-mini' })
const memory = new MemnodeClient({
apiKey: process.env.MEMNODE_API_KEY,
})
const agent = createAgent({
llm,
tools: [
{
name: 'recall_project_memory',
async invoke({ question, entity }) {
return memory.recall({ query: question, entity })
},
},
{
name: 'record_project_memory',
async invoke({ entity, text, source }) {
return memory.record({ entity, text, source })
},
},
],
})Memnode owns the memory lifecycle while LangChain keeps orchestration, tools, and model routing. That is the right split.
Vercel AI SDK shape
Put `recall` before response generation and `record` after the answer completes. That keeps Memnode in the memory lane rather than trying to replace your SDK or transport layer.
What to keep framework-agnostic
- entity / tenant naming
- source kinds and lineage discipline
- correction flow for stale policy or convention memory
- memory-health review and query workflows later