Vector Memory vs Readable Memory: Choosing the Right Agent Memory

Vector memory and readable memory solve different parts of the same problem: helping an agent use information after the original conversation has disappeared. A vector index is good at finding semantically similar passages. A readable Markdown repository is good at showing people and agents what is believed, why it is believed, and how to correct it. Treating them as interchangeable leads to brittle systems.

The practical answer for many engineering teams is to separate canonical storage from retrieval indexes. Keep decisions, runbooks, preferences, and verified facts in files you can inspect and version. Add vector search when semantic recall over a large corpus justifies the operational cost. Meshnote follows that model: an agent-agnostic Markdown wiki exposed through MCP, so the memory is readable and self-hostable instead of being locked inside one vendor's index.

What the current search results cover

The pages currently ranking for this question largely converge on three ideas. A DEV Community article argues that storage and search should be separate: Markdown can be the source of truth while vectors, BM25, or graphs are derived indexes. Oracle's comparison frames files as an excellent agent interface and databases as stronger substrates for concurrency, auditability, and semantic search. Another DEV article makes the case for a small project context file that an agent reads first.

Those explanations are useful, but they stop short of an operational decision test. They do not show how to connect a shared readable store to an MCP client, nor do they define what to do when a remembered fact is wrong. This guide adds both: a runnable remote-MCP configuration and a storage-versus-index acceptance checklist you can apply to any provider.

Vector memory in plain terms

Vector memory converts text into an embedding, stores the resulting vector with metadata, and embeds a later query to retrieve nearby records. “We deploy behind a reverse proxy” can retrieve a note that says “nginx sits in front of the app,” even when the words do not match. That semantic tolerance is valuable for conversational history, support transcripts, and large collections of loosely structured material.

Vector retrieval is not automatically memory, however. It is an index and ranking technique. The system still needs policies for extraction, deduplication, updates, tenant isolation, provenance, deletion, and stale information. A high similarity score does not prove that a record is current or authoritative. It only says the representations are close.

Readable memory in plain terms

Readable memory stores the canonical record as Markdown (often with YAML frontmatter), ordinary files, or another human-inspectable document format. A person can open the file, review a diff, make a correction, link related notes, and back it up with normal tools. An agent can do the same through a file interface or MCP tools.

This is especially effective for durable engineering knowledge: architecture decisions, deployment runbooks, project conventions, and explicit user preferences. Search does not have to mean “load the whole folder.” A readable system can use filename and keyword search, BM25, links, metadata filters, or a derived vector index while keeping the file as the authority.

Honest trade-offs

Question	Vector-first memory	Readable Markdown memory
Best retrieval shape	Paraphrases and fuzzy semantic queries across large corpora	Exact terms, named decisions, links, scoped browsing, and human-guided recall
Correction	Needs an update, delete, or supersession policy; stale duplicates can still rank	Edit the canonical file, review the diff, and rebuild any derived index
Auditability	Depends on metadata, provider APIs, and retained event history	Visible content, file history, diffs, and normal repository backups
Scale and concurrency	Purpose-built stores generally handle high query volume and concurrent writes better	Simple and robust at modest scale; needs locking, a database, or a service boundary for heavy concurrent writes
Portability	Export quality varies; embeddings and provider-specific schemas may not travel	Plain files are straightforward to copy, inspect, and migrate
Cost and complexity	Embedding, index, hosting, and monitoring costs; fast semantic recall	Low substrate complexity; you must design sensible organization and retrieval

Neither column wins universally. A customer-facing assistant with millions of interaction records may need vectors for fast candidate retrieval. A team deciding whether to rotate a certificate should not make the vector database the only place where the runbook exists. Use vector search to find candidates; use an authoritative readable record to decide what the agent should trust.

What the 2025–2026 benchmarks actually tell you

Current benchmark results are useful signals, not a universal leaderboard. Mem0's published README reports its April 2026 algorithm at 92.5 on LoCoMo, 94.4 on LongMemEval, and roughly 7K tokens and sub-second-to-low-second retrieval figures in its stated stack. Those are vendor-reported results and the README explicitly notes that managed-platform optimizations are not identical to the open-source SDK.

LongMemEval-V2 is a more operationally relevant direction: its public harness describes 451 questions, up to 500 trajectories per haystack, web and enterprise domains, and abilities such as dynamic state tracking, workflow knowledge, environment gotchas, and premise awareness. That is closer to the failure modes of a working agent than a single “did it recall the sentence?” score.

Do not compare decimals without checking the judge model, retrieval budget, prompt, corpus size, and full-context baseline. A memory system can improve token cost and latency while losing a narrow recall test, or score well on a small benchmark while failing your team's correction and access-control requirements. Measure your own questions, added latency, token cost, stale-answer rate, and recovery time.

Where Mem0, Zep, Letta, and native memory fit

Mem0 is a strong choice when an application needs an API-oriented memory layer with automated extraction and retrieval. Zep is a credible option for teams interested in temporal and graph-shaped memory, especially when relationships and time are central to the product. Letta takes a more stateful-agent and memory-management approach, which can be a good fit when the runtime itself owns the memory loop.

Native memory in ChatGPT and Claude is the shortest path for an individual using those products. OpenAI describes saved memories plus reference to past chat context; Anthropic describes editable memory topics and, for its developer memory tool, a file-based store managed by the developer. The trade-off is scope: native memory is convenient inside its host product, while a shared MCP store can be selected by Claude Code, Cursor, Codex, and other MCP clients. Choose based on whether memory must cross that boundary.

A runnable MCP setup with a readable source of truth

For a hosted Meshnote project, add the server to an MCP client with an API key. The following Claude Code configuration uses the documented HTTP endpoint and sends the bearer token explicitly:

{
  "mcpServers": {
    "meshnote": {
      "type": "url",
      "url": "https://meshnote.io/mcp",
      "headers": {
        "Authorization": "Bearer mnk_YOUR_API_KEY"
      }
    }
  }
}

Replace the placeholder with a key from your Meshnote account; do not commit credentials. Then run a small acceptance test: write a decision with its project scope and source, read it back in a new session, correct one detail, search for the old and new wording, and export or inspect the underlying Markdown. If the old value still wins, your write or supersession policy is not finished. This Claude Code memory guide covers the native layers, while the MCP memory server guide explains the cross-tool connection.

The five-question selection test

Can a human identify the source? Require provenance, not just a similarity score.
Can an agent correct it? Test an explicit update and verify that stale copies stop being returned.
Can scopes be isolated? Test two users, projects, or tenants and attempt cross-scope retrieval.
Can you restore it? Delete or corrupt a record, then recover from a versioned export.
Can you measure your workload? Keep a small set of real queries and record recall, latency, token overhead, and false positives.

If semantic recall is the bottleneck, add vectors as a derived layer. If trust, review, and portability are the bottleneck, start with readable files. In both cases, define the source of truth before choosing the index.

Start syncing — $8/mo, or choose self-hosted for teams from $10/seat/month when your agents need a shared memory they can read, edit, and own.