Pi Coding Agent Memory: Persistent Markdown via MCP

Pi is deliberately a minimal coding-agent harness. It gives you sessions, project instructions, compaction, and an extension system, but it does not prescribe one long-term memory architecture. That is useful: a personal scratchpad, an automatically extracted fact store, and a team knowledge base have different failure modes and should not be collapsed into one feature.

For shared engineering knowledge, a strong default is memory stored as files you can read, edit, diff, and self-host—not embeddings locked behind an opaque retrieval layer. Meshnote exposes a linked Markdown wiki through MCP, so Pi can maintain the same project memory as Claude Code, Cursor, Codex, or another MCP client.

What Pi remembers without an extension

Pi stores sessions as tree-structured histories and can compact an active session as it approaches the context limit. It also loads AGENTS.md project instructions. These are three different things:

Session history lets you resume or branch a conversation.
Compaction keeps one long conversation usable by summarizing older messages.
Durable memory preserves selected knowledge for a different session, machine, or agent.

Resuming a transcript is helpful, but it is not a maintained source of truth. If an architecture decision changes, you need one current page plus recoverable history—not several plausible summaries scattered across old sessions. The same separation is central to a good memory design for coding agents.

What the current ranking pages cover

The first three results for “Pi coding agent memory” are implementation-focused. pi-semantic-memory indexes a project into local LogosDB vector search, injects matches before prompts, captures turns, and supports global or project namespaces. LaPis uses SQLite and adds automatic recall, code and documentation indexing, trust decay when linked code changes, deduplication, and maintenance tooling. pi-memora wraps Microsoft Memora, offering a native Pi extension or MCP bridge with automatic recall and capture.

Those pages explain their own memory loops well. What they do not provide is a vendor-neutral, authenticated setup for connecting Pi to a readable wiki shared with other agents, followed by a correction-and-history acceptance test. That is the walkthrough below.

Choose the storage model before the package

Approach	Best at	Honest trade-off
Pi-native Markdown extension	Low-friction personal memory and lifecycle hooks inside Pi	Usually local to Pi unless you design synchronization separately
Mem0	Automatic fact extraction, scoped semantic retrieval, and a current Pi plugin	Extracted facts and indexes are less direct than canonical engineering documents
Zep / Graphiti	Temporal relationships, changing facts, and hybrid graph retrieval	A graph, extraction pipeline, and model services add operational surface
Letta	A stateful agent runtime whose agent manages persistent memory	Excellent when the runtime is the product; heavier if you only need shared Pi knowledge
Readable wiki over MCP	Decisions, runbooks, research, provenance, human correction, and cross-agent reuse	Requires a write policy; it should not ingest every turn automatically

This is not a choice between search and files. Search can be a derived index while Markdown remains canonical. The deeper trade-offs are covered in vector memory versus readable memory.

Working setup: connect Pi to Meshnote over OAuth

Pi does not ship an MCP client in core. Install the community adapter, then register the remote server. Pi packages execute code with your user permissions, so review third-party package source before installing it.

Install the adapter:
```
pi install npm:pi-mcp-adapter
```

Create .mcp.json in the project root:

{
  "mcpServers": {
    "meshnote": {
      "url": "https://meshnote.io/mcp",
      "auth": "oauth"
    }
  }
}

Restart Pi, authenticate, and inspect the connection:
```
/mcp-auth meshnote
/mcp
```
The adapter opens an OAuth 2.1 authorization flow with PKCE. Meshnote supports dynamic client registration, so there is no client ID to paste into the file. The adapter stores credentials in the operating system credential store and binds them to the configured server URL.

Ask Pi to discover the wiki and obey its schema:

Use the meshnote MCP server. Call list_projects. For project
product-api, call get_schema before doing anything else, then call
search_wiki for "idempotency" and summarize the current decision
with the page path as evidence.

The adapter exposes MCP through a compact proxy tool and discovers server tools on demand. That avoids permanently loading every tool schema into Pi’s context. For the protocol architecture behind this setup, see the MCP memory server guide.

Add a selective write contract

MCP connectivity does not automatically create good memory. Put a short policy in the repository’s AGENTS.md so Pi knows when to read and write:

## Durable project memory
- Before relying on a prior decision, search the Meshnote project.
- Call get_schema before writes. Read an existing page before updating it.
- Store decisions with rationale, verified constraints, runbooks, and resolved failures.
- Do not store secrets, raw transcripts, temporary debugging output, or guesses.
- When a fact changes, update its canonical page; do not create a competing page.
- Report the page path and any unresolved links after each write.

This makes the boundary explicit. Source code and Git remain authoritative for current implementation. The wiki records knowledge that code alone does not explain: why a timeout is 48 hours, which failed migration caused a rollback, or how production recovery is performed.

Run a two-session correction test

Do not stop at “connected.” Use a disposable decision page and verify the full lifecycle:

Write: in session A, create wiki/decisions/webhook-retries.md with the statement “Webhook events are retained for 24 hours,” a rationale, and today’s date. New pages use an empty base_version.
Recall: exit Pi, start session B, search for webhook retention, and require the answer plus page path.
Correct: read the page to obtain its current version, change 24 hours to 48 hours, and write using that version. This exercises optimistic concurrency rather than blind overwrite.
Audit: read the page again and call list_page_history. The current answer must be 48 hours; history must retain the earlier 24-hour version.
Isolate: ask the same question in a different Meshnote project. It must not return the first project’s decision.

This test catches the failures a happy-path recall demo misses: stale answers, cross-project leakage, destructive correction, and writes without concurrency control.

What current benchmarks can—and cannot—tell you

LongMemEval, published at ICLR 2025, contains 500 questions spanning extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention; its authors found 30–60% drops for long-context models on roughly 115,000-token histories compared with oracle evidence. More relevant to coding work, the 2026 LongMemEval-V2 benchmark uses web-agent trajectories and reports 72.5% average accuracy for a scaffolded, file-based coding-agent method, versus 48.5% for its strongest RAG baseline and 69.3% for vanilla Codex. The file-based method also had high query latency.

That result is evidence for explicit files, manifests, and workflow instructions—not proof that one product wins. Benchmarks still do not replace your correction, provenance, isolation, deletion, and restart tests. Run those against your own failure modes.

The practical default

Use Pi’s session tree for exploration, compaction for continuity, and AGENTS.md for small always-on rules. Promote only durable, cross-session knowledge into a maintained memory layer. Choose Mem0 when automatic extraction is the main job, Zep when temporal graph queries are load-bearing, Letta when you want a stateful runtime, and a readable MCP wiki when engineers need to inspect and correct the source of truth.

Start syncing — $8/mo. Teams can self-host from $10/seat/month with a five-seat minimum.