Letta Agent Memory: Persistent State and Shared Work

Letta agent memory is persistent information an assistant can read and edit across conversations. Its current memory model, MemFS, uses a Git-backed collection of files, so understanding what persists means checking the agent, the saved files, and how those files reach its next session.

That continuity is useful when you want an assistant to retain working knowledge. A shared project also needs agreements and progress that people and other assistants can review; fenbs keeps that work record separately. Decide which information belongs to the assistant and which belongs to the team before combining the two.

What is the current Letta memory model?

Letta’s MemFS documentation↗ (opens in a new tab) describes an agent-owned memory repository projected onto the computer where the agent runs. The assistant works with ordinary files. Files at the memory root are included in its system prompt, while indexed directories can hold deeper material that it reads when needed.

Git is a system for recording file versions. Here, it gives memory changes a saved history rather than leaving them as an unexplained replacement of yesterday’s text. That history is useful evidence when an assistant starts repeating a wrong assumption: you can inspect the change instead of guessing what it learned.

The Letta Agent SDK memory guide↗ (opens in a new tab) explains how starting memory entries become Markdown files labeled for their purpose. The agent’s memory persists across conversations and follows the agent between models and computers. That is continuity for the same agent; it does not give every unrelated assistant automatic access.

If the concept is new, what agent memory is explains the basics. This article focuses on judging Letta’s saved state rather than designing an entire memory system.

Why do some guides describe memory blocks instead?

You may encounter Letta examples built around core memory blocks and archival memory. Read the documentation version before copying their assumptions into a new setup. Letta’s shared memory guide↗ (opens in a new tab) explicitly identifies shared memory blocks as a legacy pattern and recommends shared memory repositories for that job.

The useful question stays the same across versions: what is always shown to the model, and what must it look up? The context window is the information the model can work with at one time. Information can remain saved without appearing in that window for every answer. Our guide to agent memory versus context develops that distinction.

When following a tutorial, check its SDK, storage model, and inspection commands against your installation. Avoid a setup that partly follows old block examples and partly follows current file-based instructions without understanding which system owns each piece of information.

How do you verify that an edit really persists?

Use a small, harmless correction that has one clear expected answer. For example, give a fictional project the name Cedar, ask the agent to remember it, then change the name to Harbor. A successful response in the same conversation is only the first check: the model could be answering from the messages you just sent.

Letta’s memory configuration guide↗ (opens in a new tab) documents explicit remembering, memory inspection, and background dreaming that consolidates information. Inspect the saved record after your correction. Background consolidation also deserves review because a helpful summary can still broaden a narrow instruction into a rule you never intended.

1. Record the expected final fact and the scope it applies to before testing.
2. Ask the agent to save it, then inspect the memory file and the saved change.
3. Start another conversation with the same agent and ask a neutral question about the project.
4. Check the result after any configured background memory processing, including whether the old fact remains elsewhere.
5. Repeat after the restart or computer change your normal workflow requires.

For cloud-backed memory, check that the saved change has synchronized; for a local-only setup, include backup and recovery in your test. A file visible on one computer and a durable record available to the next session are different milestones. Record both outcomes rather than labeling the whole test “works.”

What changes when several agents share memory?

Letta distinguishes the memory owned by one agent from a shared repository owned by an organization. In the shared model, cloud-hosted agents attach the same repository, edit their checkouts, and exchange saved changes through Git. Review the vendor’s sharing instructions rather than assuming that two agents with similar names already see the same files.

Test two readers and two editors. After agent A changes a fictional project note, confirm when agent B receives it. Then have each make a different change and inspect how the final record is reconciled. The point is to discover your workflow’s actual synchronization behavior before colleagues rely on an outdated copy.

Also separate seeing information from permission to change it. Decide who may attach the repository, who can edit shared instructions, and how you remove access. A sentence telling an assistant to avoid another project is guidance, not proof that the other project’s files are inaccessible. Use the agent memory security guide for the broader questions.

What belongs in memory rather than the project record?

A useful assistant memory may include how to navigate the codebase, which explanation style helps you, and lessons from repeated work. A shared agreement should state what a person chose and the work it affects. Keep those meanings distinct even if your assistant can store both kinds of text.

Say a team approves a simpler signup form but has not yet tested email delivery. Save the approval as a decision and the missing check on the task. “The team prefers simplicity” is a reasonable summary of a preference; it does not tell the next developer what was approved or whether the implementation works.

fenbs keeps tasks, Decisions and rules, Where we left off, and History together. It is useful when people and supported AI apps need the same explicit project record. See how fenbs works for the read, work, and save loop that keeps that record current.

How to do this with fenbs

1. Create a free account and add a project with one real task you expect another session to continue.
2. Record the human-approved decisions and standing rules. Add the current next step and any unresolved question without turning it into an agreement.
3. Use Integrations to connect a supported AI app through browser sign-in. Ask it to read Rules and Where we left off before working.
4. Save progress before the session ends. In a fresh connected session, check that the assistant distinguishes completed work, untested changes, and decisions still waiting on a person.

fenbs does not synchronize Letta memory files or host your custom agent. If your goal is building a stateful assistant into your own application, evaluate Letta’s developer tools directly. fenbs fits the separate need for shared project work across people and supported assistants.

For the larger design, continue with agent memory architecture. The memory tools hub covers other approaches. Choose a small persistence test you can repeat, then expand only after edits, boundaries, and handoffs behave as expected.