One memory layer across Claude Code, Cursor, and LangGraph

Most teams today run more than one agent framework, whether they planned to or not. One engineer lives in Claude Code's terminal. Another prefers Cursor's editor panel. A third is building a LangGraph pipeline for something more autonomous. All three are, at various points, working in the same repo — and all three are, by default, invisible to each other.

Here's the scenario that motivates threadctx's whole design. An engineer using Claude Code spends an afternoon tracking down why a migration silently corrupts data under concurrent writes. They fix it, and — because their agent calls memory_write — the root cause and the fix get stored: scoped to the repo, tagged, timestamped.

A week later, a teammate is building a LangGraph agent to automate schema changes for a different feature. Before it touches the migrations table, it calls memory_query — the same tool, the same protocol, running inside a completely different framework — and the exact incident surfaces before the agent repeats it. No Slack thread to dig up, no "did anyone else hit this," no re-discovering the same bug a third time in a Cursor session next month.

Why this only works with a protocol, not a plugin

If threadctx were a Claude Code extension, a Cursor extension, and a LangGraph integration — three separate codebases, three separate auth flows, three places to go stale — the LangGraph engineer in that scenario would never have seen the memory at all. Building it as one MCP server instead means the fix lives in exactly one place, and every framework that speaks MCP can reach it. That's the entire argument for MCP as the substrate for agent memory: value that compounds across tools instead of resetting inside each one.

Set it up for Claude Code, Cursor, or LangGraph — it's the same server and the same two tools everywhere.