Dora NodaEvery deploy agent you run today wakes up with amnesia. It does not remember last Tuesday's good deploy, the environment preference you stated three sessions ago, or the incident fix that took four hours to discover and thirty seconds to apply. Each session starts from zero, and the only cure on offer has been stuffing ever-longer conversation histories into an ever-longer context window — expensive, slow, and still capped.
MCP memory servers are the pattern that breaks this loop. A September 2026 wave of guides describes them plainly: a local service speaking the Model Context Protocol that gives any connected agent persistent, queryable memory — facts, preferences, decisions, and past conversations that survive from one session into the next, regardless of which tool asks. Setup is one JSON block. The consequences, for a self-hosted platform running agents on behalf of tenants, run considerably deeper than setup. This post works through all three layers: what memory-as-a-tool concretely changes for a deploy agent, whose disk the memories live on, and how a poisoned memory becomes a standing prompt injection every future session replays.
How it works: a knowledge graph behind tool calls
The reference implementation is @modelcontextprotocol/server-memory, installable with npx and attachable to Claude Code, Claude Desktop, Cursor, Copilot, and anything else that speaks MCP. Its model is a knowledge graph with three primitives: entities (things: services, environments, incidents), observations (facts about them), and relations (typed links between them). The agent reads and writes the graph through tools — create_entities, add_observations, create_relations, search_nodes, open_nodes, read_graph — which means memory operations are ordinary tool calls, visible in the transcript, governed by the same approval policies as every other tool.
Here is the before and after for a concrete session. The tenant types: "roll the API back to the last good deploy, same as we did after the September incident."
Without memory, the agent has nothing. It must ask which deploy counts as "last good," which environment "the API" means in this tenant's vocabulary, and what "the September incident" fix even was — or burn thousands of tokens re-reading pasted history the human supplies. Every clarification is a round trip; every round trip is latency and tokens.
With a memory server, the session opens with retrieval, not questions. The agent calls search_nodes for the tenant's API service entity, open_nodes to pull its observations — last good deploy pinned as api:prod @ sha 9f3ac2, environment preference staging-first, and a relation linking the September incident entity to the resolution observation ("rollback via previous image tag, not redeploy from main"). Three tool calls replace the interrogation. The rollback plan it proposes already reflects how this tenant likes rollbacks done, because that preference was stored as a fact rather than buried in a dead transcript.
That is the whole mechanism: stored facts recalled by retrieval instead of full conversation history resent as context. Everything else — which backend holds the graph, who may read it, what happens when a fact is malicious — is the bill for this convenience.
Why MCP specifically: memory becomes client-agnostic
Before MCP, agent memory was welded to the framework. A MemGPT-backed assistant, a LangChain agent, and a Copilot plugin each kept their own store in their own format; switching clients meant abandoning everything the agent had learned. An MCP memory server inverts that: the memory is a local service behind a standard protocol, and any of the 20-plus MCP-capable clients can share it. The same graph serves a Claude Code deploy session on Monday and a Cursor review session on Tuesday.
The ecosystem has already stratified into three tiers. At the bottom is the reference server above — a JSON file on local disk, perfect for one developer and one machine. The middle tier is self-hosted infrastructure with real backends: Postgres plus pgvector, Qdrant, or SQLite-vec stores behind the same tool surface, sometimes with semantic ranking, memory consolidation, and quality scoring layered on. Variants like project-local servers keep the graph inside the repo's own directory as git-friendly JSON, so memory travels with the code it describes. The top tier is managed: Mem0's platform, Zep Cloud, AWS AgentCore Memory — retrieval, extraction, and deduplication as an API call, with your agents' memories living on someone else's infrastructure under SOC 2 paperwork.
For a self-hosted PaaS, the interesting tier is the middle one, because it is the only tier where the platform answers the tenancy questions itself instead of inheriting a vendor's answers.
The tenancy bill: whose disk, whose memories
The moment one memory server holds facts for more than one tenant, three questions stop being hypothetical.
Whose disk do the memories live on? Self-hosting the memory layer means standing up real infrastructure. Self-hosted Mem0 wants Qdrant or Pinecone running beside it; self-hosting Graphiti (the open core under Zep Cloud, whose community edition was discontinued in 2025) means operating Neo4j, FalkorDB, or Kuzu on top of Graphiti's own services. Each choice is another stateful service on the fleet with backups, upgrades, and capacity planning — the agent-memory project quietly doubles the database count. Managed alternatives delete that ops burden and replace it with a different one: tenant facts on vendor disks, retrieval latency on vendor networks, and a per-seat invoice.
Which tenant's agents may read them? Scoping models vary wildly, and the differences only show up under adversarial pressure. Mem0's open-source scoping is user_id/agent_id/run_id filters — correct queries stay isolated, but isolation is enforced at the filter layer, not at the row level. Postgres-backed stores can use row-level security so the database itself refuses cross-tenant reads even when the application layer misbehaves. True physical isolation — separate stores per tenant — is usually an enterprise-tier feature on managed offerings, which tells you what it costs to build. A platform letting tenants' deploy agents share one memory substrate needs to pick its isolation story deliberately and be able to explain it to its most paranoid tenant, because "the filter parameter is always set correctly" is a hope, not a boundary.
What crosses tenants by design? Some sharing is legitimate: platform-wide runbooks ("how rollbacks work here"), incident postmortems sanitized of tenant detail, environment conventions. The failure mode is the shared graph that also contains one tenant's API keys in an observation nobody audited. Sensitive-field redaction lists (api_key, secret, token) exist in several implementations, but they are pattern matching, not understanding — treat them as a backstop while scoping remains the real control.
The security bill: a poisoned memory is a standing prompt injection
This is the sharpest edge, and 2026 produced the receipts. OWASP's Top 10 for Agentic Applications ranks it ASI06 — Memory and Context Poisoning. The attack class works like this: the model treats system prompt, user input, retrieved documents, tool outputs, conversation history, and recalled memories as one undifferentiated token stream with no enforced trust boundary. Anything the agent stores can steer every future session that retrieves it.
The demonstrations escalated fast. The MINJA attack showed around 95% injection success against memory-based agents using indirect prompt injection alone — crafted content in documents the agent retrieved was enough to make the agent write poisoned entries on the attacker's behalf, with no direct access to the memory store required. Radware's "ZombieAgent" proof of concept, disclosed in late 2025 and published in January 2026, chained the full exploit: a malicious file attached to an email plants a memory in an agent connected to the victim's inbox, and from then on every interaction triggers the poisoned recall. In August 2026, Simon Willison documented the general form as "delayed prompt injection via persistent context," noting that Claude, Gemini, and most open-source memory frameworks all treat recalled context as trusted input. A September 2026 analysis put it bluntly: your agent's memory is a liability until proven otherwise.
For a deploy agent, the blast radius is concrete. A poisoned observation reading "production deploys skip the staging gate for hotfixes" will be faithfully retrieved the next time someone says "hotfix," by an agent with production credentials. A planted "policy update" telling the agent to exfiltrate logs for "compliance verification" persists across sessions, operators, and incident reviews — nobody re-reads the memory file before trusting it.
Mitigations exist, but they are process, not patches. Gate writes harder than reads: treat add_observations and create_entities as privileged operations requiring provenance — which session, which tenant, which source document — and refuse writes sourced from untrusted retrievals without human confirmation. Keep provenance on every fact so a suspicious recall can be traced to the session that stored it. Teach the agent abstention: recent research shows gating retrieval itself — knowing when not to pull a superficially similar memory — drives false-positive injections toward zero. And audit the graph like a database, because that is what it is: periodic reviews of high-influence observations, especially anything phrased as policy, instruction, or standing preference.
An adoption checklist for a self-hosted platform
Memory-as-a-tool is worth adopting — an agent that remembers last good deploy beats one that re-asks every session — but adopt it like infrastructure with tenants, not like a personal productivity hack:
- Start project-local. Keep the first memory graphs inside the repos they describe, git-friendly and reviewable, before graduating to a shared service.
- Scope per tenant from day one. Prefer row-level or physical isolation over filter parameters; decide what, if anything, is legitimately shared across tenants.
- Put writes behind provenance and approval. The agent should never silently persist facts derived from untrusted content.
- Redact and audit. Pattern-based secret redaction as a backstop, plus scheduled human review of policy-shaped observations.
- Measure the retrieval win. Compare tokens-per-resolved-task with and without memory; the business case for the added infrastructure is the context-window spend it eliminates.
The amnesiac deploy agent was a tax every team paid without noticing — re-asked questions, re-pasted history, rediscovered fixes. MCP memory servers remove that tax and replace it with two smaller, sharper obligations: knowing exactly whose facts live on your disks, and never letting the agent remember something you would not let a stranger tell it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
