The Orchestrator

Memory is what survives the run: facts about the organization, the project, the customer, past decisions, past failures, and corrections that were applied. Chapter 3 established why memory is a defining feature of delegated intelligence rather than a convenience — a system without it starts fresh every time and cannot build on its own experience — and Chapter 4 described the file-based layouts (the MEMORY.md pattern) and the formats beginning to standardize them. What has changed in 2026 is that memory has become a product category of its own, with dedicated systems, dedicated vendors, and an emerging division of labor against the retrieval layer underneath them.

The distinction worth holding onto is a tendency, not a hard boundary. Organizational retrieval often indexes a relatively stable corpus and serves many reads, while conversational memory may ingest frequent updates, reconciling contradictions as facts change, extracting entities, and scoping by user, session, and agent — and either layer can be read- or write-heavy.²⁴ A vector database returns the nearest neighbors of a query; a memory system decides what a system should still believe next week. That difference in workload is why dedicated memory products emerged instead of vector databases simply adding a memory feature: the read-optimized indexes that make vector search fast tend to degrade under constant writes.

1.5.1 The dedicated memory layer

The current field:

• mem0 is the category’s flagship: an open-source memory layer that sits between an application and its model, extracting facts from conversations, curating them, and recalling them across sessions, tools, and multiple agents. It is model-agnostic and backs onto roughly twenty vector and graph stores; its managed platform and a local-first “OpenMemory” server that any MCP-compatible agent can share cover the two deployment poles. Its April 2026 algorithm release added entity linking, multi-signal retrieval, and temporal reasoning — memory features, not search features.
• Letta, from the MemGPT research line, treats memory as the agent’s own operating problem: labeled memory blocks the agent edits itself, a hierarchy of in-context core memory, searchable recall, and archival storage — and, in 2026, an Agent File format meant to make a stateful agent portable between servers, much as the container image made stateless software portable.
• Zep builds memory as a temporal knowledge graph: entities and facts as graph nodes and edges with validity windows, so the system can distinguish what was true then from what is true now — and invalidate a fact when new information contradicts it, while keeping the history. Its open-source engine, Graphiti, ships an MCP server, so its memory is reachable from any MCP-compatible client.
• LangMem, from the LangChain team, adds long-term memory to the LangGraph stack: memory-management tools the agent itself invokes, a background manager that extracts and consolidates knowledge asynchronously, and procedural memory — the system improving its own instructions over time, which Chapter 3 called the dynamic disposition.

1.5.2 Memory from the model vendors

The model vendors are converging on the same territory from the other side. Claude’s consumer and team surfaces ship memory that persists across conversations, with summaries the user can view and edit; an API memory tool gives Claude a standard interface to memory files the developer controls, with persistence and retention implemented client-side — Anthropic does not host that memory for the application; Cursor, the editor, keeps per-project memories that its agents reference in later sessions. When the model vendor, the editor, and the standalone memory company all ship “memory,” the word is being stretched the same way “agent” was: applied to anything that persists anything, until it stops meaning anything in particular. The psychology of memory has a canonical taxonomy: declarative memory is retrievable knowledge — facts and events, available for recall and statement — while procedural memory is skills and habits, an ability that shows up in performance rather than in recollection.²⁵ The strict sense of memory, applied to agent systems, is the declarative one: a subsystem that stores what the system knows — facts, decisions, corrections, what was promised and to whom — and can retrieve it on demand. Much of what ships as “memory” is the procedural kind instead: the ability to update the system’s own directives and context so that it performs differently next time. That is a real capability and a form of memory, but it is not memory in the primary sense — and a product that only updates directives cannot answer the questions an orchestrator asks of a memory system. Those questions are the ones from Chapter 4: what may be written, by whom, with what provenance, and how would you reconstruct what the system believed at the moment it made a decision? A memory system that cannot answer them is a feature, not a subsystem — and the survey question that matters is whether a given product treats memory as governed organizational infrastructure or as a convenience that accumulates.

1.5.3 Where memory shows up for an orchestrator

Memory shows up for an orchestrator as the system’s accumulated experience, and the encounter is a governance encounter, not a feature encounter. The hardest case is when memory is wrong: the system has confidently acted on outdated information, and the fix is not deleting one row but knowing what else that row contaminated.

Who may write is the operational form of Chapter 3’s dispositions. A fixed-disposition system treats memory as a record a person maintains; a dynamic-disposition system lets the agent write its own, and the memory products in this section — mem0’s curation, Letta’s agent-edited blocks, LangMem’s procedural memory — sit at different points on that line. Chapter 16 returns to the forensic questions (what did the system believe when it made that decision?), because memory is where those answers live or do not.