Does Glen interfere with DSPy's optimizers?

No. DSPy optimizes how your program reasons; Glen handles what it remembers. They are orthogonal, and Glen is just one MCP tool your modules call to read and write durable memory.

How do my DSPy modules reach Glen?

Glen is a standard MCP server. Connect to it as an MCP tool and call it from any module to retrieve context and record observations in one round trip.

Shared memory for DSPy

DSPy reframes prompting as programming: you declare modules and signatures, then let optimizers compile and tune the prompts and weights that drive your LLM programs. It is a powerful way to build reliable pipelines, but DSPy optimizes how your program reasons, not what it remembers across runs. The durable facts a compiled program should accumulate, the knowledge that should carry from one execution to the next and across the other programs in your stack, is not something DSPy's optimizers provide. Glen, shared memory for AI agents, gives your DSPy programs long-term shared memory as a single MCP tool, so optimized modules can read and write organization-wide knowledge as they run.

Give a DSPy program access to Glen over MCP and any module can call one tool that retrieves relevant long-term context and records new facts in a single round trip. You keep DSPy doing what it does best, compiling and optimizing the reasoning, while Glen handles durable memory: a module fetches what your organization already knows before it acts, and a later module writes back what the program learned, all without you standing up a vector store and a write path.

The separation is clean. DSPy's optimizers improve the program; Glen's memory persists what the program discovers. And because Glen is org-scoped, that memory is shared across every DSPy program, every agent, and every deployment in your organization. One compiled pipeline learns a durable fact; another reads it next time, even a program built on a different framework or driven by a different model. Since Glen is a standard MCP server, the same memory is readable from Claude Code, Cursor, or any other MCP client, so the knowledge your DSPy programs accumulate is shared with your developers and other agents. You connect once over OAuth or an API key, keep optimizing your reasoning, and let the shared memory compound.

FAQ

Does Glen interfere with DSPy's optimizers?: No. DSPy optimizes how your program reasons; Glen handles what it remembers. They are orthogonal, and Glen is just one MCP tool your modules call to read and write durable memory.
How do my DSPy modules reach Glen?: Glen is a standard MCP server. Connect to it as an MCP tool and call it from any module to retrieve context and record observations in one round trip.