Letta vs MemoryRouter: Shared Files or Recalled Decisions?

Two agents can have access to the same memory and still be working from different versions of it. With Letta's shared memory repositories, that is a Git synchronization question. With MemoryRouter, the first question is whether the next agent retrieved the saved context at all.

Letta shares a working repository

Letta's current shared memory guide describes organization-owned Git repositories hosted in Letta Cloud. Attach a repository to each cloud-hosted agent that needs it. Letta Code clones it beside the agent's own memory filesystem, and the system prompt lists its path and top-level files.

The agents read and edit those files with ordinary tools. An edit must be committed and pushed before another agent can pull it into its checkout. Letta documents letta shared-memory sync for pulling attached repositories or creating missing checkouts; later synchronization fast-forwards the local checkout.

That is a strong fit for a plan that several agents maintain as a document. You can identify the file revision containing an edit and inspect its Git history. Shared memory can also distribute skills through a repository's skills/ directory.

Do not confuse this with the older shared-block examples. Letta still supports the legacy memory-block API, but its current guide recommends migrating to shared repositories. Nor is all Letta memory shared: each agent has its own MemFS. Shared repositories are the separate mechanism for multiple cloud-hosted agents.

MemoryRouter shares saved context through retrieval

I built MemoryRouter for the decision you want available when you open another conversation, including in a different AI tool. The shared object is a vault of saved memories, not a Git checkout of working files. MemoryRouter does not merge document edits or act as a task lock.

The MCP tool reference documents store_memory as adding a record. It never overwrites an earlier one. search_memories retrieves relevant records from the vault selected during OAuth sign-in.

That matters when you save a correction. Store what changed and what it replaces. You have added evidence for the next agent to interpret, not edited a shared plan in place. The agent still needs to retrieve that correction and use it correctly.

A queued save is not proof of a completed handoff. Confirm that search returns the saved material before relying on another conversation to use it. Generic MCP calls are model-directed; adding a connection does not guarantee recall on every message. The MCP setup page explains that boundary and the separate hook-based options.

Test the handoff your work requires

Use a synthetic release plan, not customer data. Give one agent a document change: move a review step before deployment. Separately, tell it the reason: the reviewer needs to inspect the migration before production data changes. This tests access to the source, not whether the agent follows the plan.

For Letta, put the change and its rationale in the shared repository. Check that they were committed and pushed, then synchronize the second agent's checkout. Ask it to read the plan and identify the revision it used. A local edit that never reached the remote is not a shared update.

For MemoryRouter, explicitly save the decision with its rationale and inspect the tool result. In a fresh connected conversation using the same vault, ask why review precedes deployment without supplying the reason. Inspect search_memories for the source record. An answer based only on generic deployment advice does not prove continuity.

Create a MemoryRouter vault and check whether a fresh conversation can explain one decision you saved.