Letta Code Memory: How MemFS Works and When to Add Shared Memory

Looking for a different harness rather than a MemFS deep dive? The Letta Code alternatives guide compares coding agents, pluggable memory layers, and shared readable memory with a cross-agent replacement drill.

Letta Code memory is not just a vector database attached to a coding assistant. In the current architecture, each Letta agent has a git-backed memory filesystem called MemFS. The agent reads and edits Markdown files, commits changes, and carries that state across conversations. That makes Letta Code one of the clearest examples of a memory-first coding agent.

The important design question is no longer “files or memory?” Letta already uses files. It is who owns the files and who must share them. Agent-specific experience belongs naturally in Letta's context repository. Approved project knowledge that must travel across Letta, Claude Code, Codex, Cursor, and human workflows may need an agent-agnostic layer. Meshnote provides that second model: linked Markdown wikis your tools maintain through MCP, with files you can read, edit, and self-host.

What the top results explain—and what they leave open

The three strongest current results are Letta's own product and research pages. The December 2025 Letta Code introduction explains long-lived agents, /init, explicit learning with /remember, skills, and searchable conversation history. The February 2026 Context Repositories announcement goes deeper: hierarchical Markdown, progressive disclosure, git worktrees for concurrent memory agents, background reflection, and memory defragmentation. The March 2026 platform update explains Letta's move away from legacy server memory tools toward filesystem operations, skills, and client-side subagents.

Those pages explain Letta's direction well. They do not give teams a practical boundary test for deciding which knowledge should stay inside one agent's MemFS and which should become shared, tool-independent project memory. This guide adds that missing deployment boundary plus a two-agent correction test.

How current Letta Code memory works

MemFS projects an agent's durable state into a real checkout. Markdown files include YAML frontmatter with a description. Files under system/ are loaded into the system prompt on every turn; files elsewhere remain available on demand, while the directory tree gives the agent navigational hints. This is progressive disclosure without injecting the full archive into every prompt.

Every durable edit is committed to Git. Cloud-backed agents synchronize that repository; local-only agents keep it on the current machine, so you must back it up. Letta's “dreaming” process can review recent conversations and consolidate lessons in the background. /doctor audits organization, duplication, and prompt-token use. MemFS does not include semantic search by default; Letta documents a separate MemFS Search mod for keyword and optional semantic or hybrid retrieval.

This separation matters. Conversation search finds prior episodes. MemFS contains consolidated state. Skills encode reusable procedures. Treating all three as interchangeable creates noisy prompts and stale rules. For a broader model of working, episodic, semantic, and procedural layers, see persistent memory for LLM agents.

A working Letta Code memory setup

The current quickstart requires Node.js 22.19 or newer. The following commands install the published CLI and start it inside a project:

node --version
npm install -g @letta-ai/letta-code
cd /path/to/your/project
letta

In the interactive client, connect a model provider and initialize project memory:

/connect
/init
/remember use pnpm in this repository; never npm
/doctor

/init inspects the project and bootstraps or refreshes memory. /remember asks the agent to place a durable lesson in the appropriate MemFS file and commit it. Inspect the result through Letta's memory viewer or the $MEMORY_DIR checkout. Do not merely test that a command returned success: open the changed Markdown, check its frontmatter and wording, then start a new conversation and ask which package manager the project uses.

For a local-only agent, back up the repository explicitly. Current Letta Code also documents an additional Git remote:

/memory-repository set git@github.com:YOUR_ORG/YOUR_PRIVATE_MEMORY.git
/memory-repository status
/memory-repository push

That is a real Git remote, so configure SSH or your credential helper first and keep the repository private. Letta notes that push failures do not block commits; check status rather than assuming the backup arrived.

Agent-owned MemFS or shared project wiki?

Requirement	Best default	Reason
One long-lived Letta agent learns your preferences	Letta MemFS	Identity, reflection, prompt placement, and agent experience are native to the harness.
Several Letta cloud agents need common context	Letta shared memory	It attaches Git-backed files within the same agent platform.
Letta, Claude Code, Codex, and humans need one source	Agent-agnostic MCP wiki	The knowledge contract survives switching clients or model providers.
Millions of fuzzy user memories need low-latency recall	Mem0 or Zep-style service	Extraction and semantic or graph retrieval are stronger defaults than manually curated pages.
Personal convenience inside one chat product	Native ChatGPT or Claude memory	Minimal setup, but weaker portability and cross-tool governance.

Letta and readable shared memory are complementary. Keep agent identity, personal working style, and reflection artifacts in MemFS. Promote approved architecture decisions, runbooks, service ownership, and cross-agent handoffs into the shared project wiki. The same distinction appears in a practical cross-tool MCP architecture.

The two-agent correction test

This test exposes a boundary the ranking pages do not cover. Run it before relying on any memory design in production:

Record: “The billing worker retries three times” and attach the source commit or runbook.
End the conversation. In a new Letta conversation, ask for the retry policy and its source.
Correct the policy to five retries. Verify the old value was replaced or clearly superseded, not merely joined by a conflicting fact.
Open the underlying Markdown and Git history. Confirm a human can understand the current rule and recover the earlier version.
Ask a second, non-Letta MCP client for the policy. If it cannot retrieve the correction, the information is agent memory—not shared project memory.
Export or clone the canonical files and reconstruct the answer without the original service. If that fails, you have persistence but not a credible exit path.

The expected outcome is not that every fact appears everywhere. The outcome is explicit scope. Letta-only preferences should stay Letta-only. Team decisions should be promoted once, corrected once, and read consistently by every authorized tool. A similar discipline is useful when designing memory for AI coding agents.

Honest trade-offs against Mem0, Zep, and native memory

Mem0 is a memory layer rather than a coding harness. It is attractive when applications need automatic extraction and retrieval across many users and sessions. Zep emphasizes temporal, relationship-rich memory through its graph approach, which fits questions about changing entities and events. Letta Code owns the complete agent loop: model choice, tools, conversations, learning, skills, and MemFS. That integration enables background reflection and deliberate prompt placement.

Readable MCP memory gives up some automatic personalization and graph-native querying. In return, approved knowledge is ordinary Markdown, can be reviewed outside one harness, and can serve several agents. Native ChatGPT or Claude memory is the easiest option for personal continuity, but it is not a substitute for a repository-level source of truth.

Do not choose from feature lists alone. Choose based on authority: automatic user personalization, temporal relationship history, one evolving agent, or shared operational knowledge. Hybrid systems are normal, but each fact should have one canonical home.

Practical recommendation

Use Letta Code's MemFS as designed if you want a stateful coding agent that learns over time. Initialize it, inspect what it writes, audit it with /doctor, and back up local-only state. Add shared memory only when knowledge must cross an agent or platform boundary.

For that shared layer, Meshnote keeps the source readable and exposes it through MCP rather than trapping it in one client. Start syncing — $8/mo. Teams that need their own deployment can choose self-hosted access from $10/seat/month, with a five-seat minimum.