How is Glen different from Semantic Kernel's memory connectors?

Memory connectors let you wire a vector store into one application, which you then operate yourself. Glen is a managed, org-shared memory delivered as one MCP tool, used by every agent in your organization regardless of language or framework, with no store to provision.

How do my Semantic Kernel agents reach Glen?

Glen is a standard MCP server. Register it with the kernel as an MCP server and call it from a function or planner to retrieve context and record observations in one round trip.

Shared memory for Semantic Kernel

Semantic Kernel gives .NET and Python developers a kernel that orchestrates plugins, functions, and planners, with a chat history object that carries the conversation through an invocation. It has memory connectors that let you wire in a vector store for semantic recall, but that means you choose, provision, and operate the backing store, the embeddings, and the retrieval logic yourself, and the result is typically scoped to one application. The durable knowledge your whole organization's agents should share, across services, across languages, and across other frameworks, is not something a single app's memory connector delivers. Glen, shared memory for AI agents, provides that org-wide memory as a single MCP tool every Semantic Kernel agent reads from and writes to.

Register Glen with your Semantic Kernel agents as an MCP server and the kernel gains one tool that retrieves long-term context and records new facts in a single round trip, no separate vector database to stand up, no embedding model to manage, no memory connector to wire and operate. A function or planner can pull what the organization already knows before it decides what to do, and write back the durable facts an invocation produced, while your chat history continues to handle the in-conversation turn-by-turn flow it is good at.

The split is clean: chat history keeps one invocation coherent, and Glen is the org-wide layer that outlives it and is shared across agents. Because the memory is org-scoped rather than bound to one kernel instance or one app's connector, a fact recorded by a Semantic Kernel service in .NET is available to a Python service, to another team's agents, and to agents built on entirely different frameworks, because Glen is a standard MCP server, not an SDK-specific store. The knowledge compounds across your fleet instead of being siloed per application. Connect once over OAuth or an API key, and the same memory your Semantic Kernel agents build is readable from Claude Code, Cursor, or any other MCP client, so enterprise services and human-driven work share one source of truth.

FAQ

How is Glen different from Semantic Kernel's memory connectors?: Memory connectors let you wire a vector store into one application, which you then operate yourself. Glen is a managed, org-shared memory delivered as one MCP tool, used by every agent in your organization regardless of language or framework, with no store to provision.
How do my Semantic Kernel agents reach Glen?: Glen is a standard MCP server. Register it with the kernel as an MCP server and call it from a function or planner to retrieve context and record observations in one round trip.