threadctx works with your custom agents too — we do the integration if you need it

Every pSEO page we've written so far names a specific framework — Claude Code, Cursor, LangGraph, Microsoft Agent Framework — because those are the tools most teams already have installed. But a meaningful share of engineering orgs aren't running any of those for their internal agent work. They're running something built in-house: a thin wrapper around an LLM API, a fork of an early open-source agent loop, an orchestrator that predates most of the current framework landscape.

That's fine. threadctx was never a Claude Code feature or a Cursor feature — it's an MCP server, and MCP is a protocol, not a club with a member list. Anything that can speak MCP over stdio (launch a command, read/write JSON-RPC over stdin/stdout) or over HTTP can call threadctx's two tools — memory_write and memory_query — the same as any public framework does.

What this actually requires

If your internal agent already does tool-calling against an LLM API, adding an MCP client is usually a self-contained addition: launch the server process, list its tools, forward a tool call, read the result back into context. It's the same shape of code as adding any other tool. We've written up the exact config block (command, args, environment) on the custom & enterprise integration page — it doesn't change based on what's calling it.

If it's not straightforward

Some setups genuinely aren't simple — a proprietary transport, a gateway that mediates every tool call for compliance reasons, an agent runtime that doesn't expose a plain tool-calling hook. If that's your situation, we'd rather hear about it than have you decide threadctx doesn't apply to you. Email founders@threadctx.dev — custom integration support is available for Team plan customers.