How is Glen different from a LlamaIndex index or vector store?

An index answers questions over documents you ingested. Glen is durable, org-shared memory of what your agents learn in production, facts no source document contained, written and read live as workflows run.

Where in a workflow do I call Glen?

Connect Glen as an MCP tool and call it from any step. A retrieval step reads relevant context before dispatching the next event; a later step records what the run discovered, in one round trip.

Shared memory for LlamaIndex Workflows

LlamaIndex Workflows model agent logic as event-driven steps that emit and consume events, giving you a clean way to orchestrate retrieval, reasoning, and tool calls across an application. The framework already shines at indexing documents and answering questions over them, but that is retrieval over a corpus you ingested, not durable memory of what your agents have actually learned in production. The facts a workflow discovers mid-run, a corrected assumption, a customer-specific detail, a resolution that worked, vanish when the events stop flowing. Glen, shared memory for AI agents, gives your workflows that missing long-term layer as a single MCP tool, so every run reads from and writes to one org-wide store.

Add Glen as an MCP tool and any step in a LlamaIndex Workflow can call it to pull relevant long-term context and record new facts in one round trip, alongside the index-backed retrieval you already do. The distinction matters: your indices answer questions over documents you ingested, while Glen holds the operational knowledge your agents generate as they run, the things no document captured because they only became true in production. A step can read what the organization already knows before it dispatches the next event, and a later step can write back what the workflow concluded, so the memory grows as a byproduct of normal execution rather than a separate ingestion job you maintain.

Because Glen is org-scoped, that memory is shared across every workflow, every deployment, and every other agent in your organization rather than trapped in one running graph of events. One workflow learns a durable fact; a different workflow, even one built on a different framework, reads it the next time it needs it. That is precisely what event-driven state within a single run cannot give you: persistence that outlives the run and is shared across agents. And because Glen is a standard MCP server, the same memory your LlamaIndex Workflows write is readable from Claude Code, Cursor, or any other MCP client, so your retrieval pipelines and your human-driven work draw on one knowledge base. Wire it in once over OAuth or an API key and let the knowledge compound across runs.

FAQ

How is Glen different from a LlamaIndex index or vector store?: An index answers questions over documents you ingested. Glen is durable, org-shared memory of what your agents learn in production, facts no source document contained, written and read live as workflows run.
Where in a workflow do I call Glen?: Connect Glen as an MCP tool and call it from any step. A retrieval step reads relevant context before dispatching the next event; a later step records what the run discovered, in one round trip.