What is Letta? The AI agent whose research everyone else ships
Letta is an open-source agent harness, and it is also the research lab that published the memory ideas its competitors now ship. OpenClaw's documentation cites Letta's sleep-time compute paper as the basis for its background memory consolidation, and Letta's own June 2026 research names OpenClaw as one of the harnesses that adopted its approach. This page covers what Letta is, how its split between identity, conversation, and machine works, whether you can fork an agent, how to stop one reading files it has no business in, what it costs, and why comparing it to OpenClaw on features misses the actual difference. The short answer: the product rebuilt itself this year, the version is 0.32.11, and the reason it resembles everything else is that everything else read its papers.
Letta is an open-source program you install on your own machine that runs AI agents which remember. That last word is doing the work. Most tools you have used start every conversation from nothing and forget it when you close the window. A Letta agent keeps a repository of what it has learned about you and your work, carries it into every future conversation, and edits it as it goes.
It is also something less obvious, and it is the reason this page exists. Letta is a research lab, and the memory features you have seen appear in other AI agents over the past two years mostly started as papers these people wrote. One of those agents cites their work by arXiv number in its own documentation.
We run agents in production and we run both of the systems compared here, so this page is written from operating them. Everything below was checked on September 16, 2026 against Letta 0.32.11, published the day before. Sources are listed at the end.
Letta rebuilt itself this year, so most of what you will read about it is out of date
Start here, because it will save you a wasted afternoon.
Letta began as MemGPT, a 2023 research project out of UC Berkeley's Sky Computing Lab, published as a paper on managing an agent's limited context. The company formed in 2024 around it and raised a $10 million seed round led by Felicis that September. For two years, "Letta" meant a Python server you ran in Docker and talked to over a REST API. That is what the tutorials describe. That is what the framework roundups compare.
That version is retired. The original repository now says the V1 API server lives on an archive branch and that active projects should use the current source, a TypeScript harness you install from npm in one line:
npm install -g @letta-ai/letta-code
The old repository holds 24,757 stars and the history. The new one was created in October 2025, holds 3,350 stars and 371 open issues, and had code pushed to it the morning we checked. The npm package is at version 0.32.11, published September 15, 2026.
Two practical consequences. Anything you read about Letta that mentions Docker, Postgres, or a Python client is describing the retired product. And a project at 0.32.11 with daily commits is one to adopt for what it does this week, not for what its documentation implies about next quarter.
Letta is a research lab first, and its competitors cite its papers
Here is the part that gets lost when Letta is filed next to other agent tools. Letta is not primarily a company that ships a CLI. It is a research lab that publishes on agent memory, and the product is downstream of the papers.
The credentials are unusually easy to check. Founders Charles Packer and Sarah Wooders did their PhDs at Berkeley's Sky Lab under Joseph Gonzalez and Ion Stoica, the latter a co-founder of Databricks and Anyscale, and both professors joined the company as advisors when it came out of stealth in September 2024 with a $10 million seed round led by Felicis. The angel list on that round included Jeff Dean, chief scientist at Google DeepMind, and Clem Delangue, the CEO of Hugging Face. People who fund AI infrastructure for a living put their own money into this one.
The research trail is public and it runs in both directions.
MemGPT, the 2023 paper, introduced the idea that an agent should manage a limited context the way an operating system manages limited RAM, paging information in and out. That framing is now so standard that people use it without knowing where it came from.
In April 2025 the same team published Sleep-time Compute with UC Berkeley: let a model think about a context during idle time, before anyone asks a question, and you cut the compute needed at question time by roughly five times on their benchmarks. WIRED covered it that August.
Now go read OpenClaw's documentation. Its background memory consolidation, the feature it calls dreaming, is described in the docs shipped with the version we run with this line: "Background consolidation is informed by sleep-time compute (arXiv:2504.13171)." That is Letta's paper, cited by number, in a competitor's manual.
And Letta noticed. Their June 2026 research post on memory models says agentic memory management, agent dreaming, and skill learning have become "central features in agent harnesses such as Letta Code, Claude Code, DeepAgents, and OpenClaw."
So when two of these tools look alike, the reason is not that one copied the other's feature list. It is that one of them wrote the research and the others read it. Letta also publishes the yardsticks the field measures itself with, including Context-Bench for context engineering, Recovery-Bench for whether an agent can dig itself out of a mess it made, and a leaderboard ranking models on agentic memory.
There is a commercial reading of this, beyond the trivia. Letta's stated next step is memory models: models trained specifically to create and curate memory, rather than general models prompted into doing it. If that works, it is not a feature another harness can ship, because it lives one layer down in the model itself. That is the bet you are evaluating when you evaluate Letta, and it is the only part of this comparison that will still matter in two years.
What a Letta agent is: an identity, its memory, and nothing else
The single idea underneath Letta is that an agent is separate from the conversation you are having with it and separate from the computer it runs on. Most tools fuse all three. Letta splits them, and the split is the reason the product feels different once you have used it for a week. An agent is a persistent identity: a name, a personality and system prompt, model and tool settings, and long-term memory. Letta's documentation describes it as something you return to "across sessions, computers, and interfaces instead of starting from scratch each time."
A conversation is one thread of messages. One agent can have many, and they all share the agent's memory. Something the agent learned while you were debugging a deploy on Tuesday is available in the thread where you are writing a proposal on Thursday. The docs draw the line in one sentence: use separate agents when you want independent memory, separate conversations when you want parallel threads that share it.
A computer is where the agent actually runs commands and touches files. It is a third setting, changeable without the agent losing anything, because identity and memory do not live on the machine. The same agent can work on your laptop today and a cloud server tomorrow. Letta even lets an in-progress conversation move between machines, which they call teleportation.
Once those three are separate, the question "how many agents can I run" stops being interesting. You create one when you want a genuinely different identity with its own memory, and a conversation when you just want a clean thread.
Memory is a git repository the agent commits to on its own
Letta calls its memory system MemFS, and it is the most concrete thing in the product. Each agent owns a git repository. The agent's memory lives in it as Markdown files. Every time the agent learns something and writes it down, that is a commit.
Storing agent memory as Markdown in a git repo is not unique to Letta, and anyone who tells you it is has not looked around. OpenClaw does the same thing, to the point of running git init on a new workspace for you. The difference is what git is being used for. In OpenClaw the repository is a backup you commit and push yourself, and the documentation presents it that way. In Letta the repository is the machinery: the agent commits every edit without being asked, that repository is what carries memory between your laptop and a server, and background memory processes work in separate checkouts and merge their results back.
The layout decides what the agent is thinking about. Files under system/ load into the agent's prompt on every single turn, so that is where identity and standing rules go. Everything else stays out of the way until needed. The file tree itself is always visible to the agent, so folder and file names work as signposts it follows to find the right page. Letta borrowed the idea, and says so, from the progressive-disclosure pattern used for agent skills.
There is no vector database in the default setup. The agent finds things in its memory the way you would, by searching and reading files, with semantic search available as an optional add-on. For a system whose entire pitch is memory, choosing plain files over a specialized index is a real decision, and it is the one that makes the memory legible to you. You can open the folder. You can read the commit log. You can see the exact sentence your agent decided to remember about your business, and delete it if it is wrong.
Letta runs a background process over that repository, which they call dreaming. Subagents review recent conversations while you are doing something else, consolidate what mattered, and commit the updates. It is configurable, it costs model tokens, and in its default form it does not ask you before writing. Worth knowing before you turn it on.
Yes, Letta forks, and it forks at three different levels
If your instinct is that the opening moves of a conversation determine everything that follows, and that a thread which reaches a good point could sensibly go two ways, Letta was built by people who agree with you. The company publishes a document called the Context Constitution governing what goes into an agent's context, in what order, and for how long, and describes its agents as learning by managing their own context rather than by retraining.
Branching shows up in three places.
The conversation. /fork branches the current thread, carrying its in-context history, so the copy can go a different direction without touching the original. There is also /btw, which forks in the background to answer a side question and hands you the answer without derailing what you were doing. A fork subagent does the same thing programmatically, inheriting the parent's full context and tools.
The memory. Because MemFS is git, the agent's accumulated knowledge has version history by default. Background memory agents work in separate git worktrees and merge their changes back, which is how Letta lets several processes reorganize memory at once without stepping on each other. Their engineering write-up on context repositories is the clearest explanation of the design if you want the reasoning.
The whole agent. AgentFile is an open format that serializes an entire stateful agent into one file: system prompt, memory, message history, tool definitions with their source code, and model configuration. letta --import <path> creates a new agent from one. That is checkpointing at the level of the whole personality, and it is also how you hand an agent to somebody else. One caveat worth stating: the AgentFile documentation still sits in the retired V1 section of the docs even though the import flag is current, so treat the format as useful rather than settled.
Letta and OpenClaw answer different questions, and one common belief about OpenClaw is wrong
We operate both, and the comparison people expect is the wrong one.
First, a correction, because it is the assumption we hear most often. OpenClaw is not a one-agent-per-machine system, and it does not have to take over the computer it runs on. The multi-agent documentation shipped with the version we run opens by describing how to run multiple isolated agents in a single process, each with its own workspace, its own configuration directory, and its own conversation database. Adding one is a command:
openclaw agents add work
Each agent gets separate files, separate credentials, separate history, and separate routing, so a message arriving on one chat account reaches one agent and not the others. If you passed on OpenClaw because you believed it could only host a single assistant, that belief was false. We wrote the full picture of the system in What is OpenClaw?.
With that cleared up, the real difference is what each project organizes itself around.
OpenClaw's question is how a person reaches an agent. One long-lived process owns every connection to Telegram, Slack, WhatsApp, Discord and the rest, and it can start conversations with you on a schedule or in response to an event. The center of gravity is the channel.
Letta's question is what an agent retains. The center of gravity is the memory repository, and everything else, including its own messaging channels, arranges itself around keeping one identity coherent across every machine and interface you use it from.
Those are starting points rather than territories, and the two have converged much further than a comparison table would suggest. Both are TypeScript. Both self-host. Both take whichever model provider you prefer, including local ones. Both have skills, subagents, and scheduled tasks. Letta ships channels for Slack, Discord, Telegram, WhatsApp and Signal, which is OpenClaw's home ground. OpenClaw keeps agent memory as Markdown in a git repository, initializes that repository for you, and runs background consolidation, which is Letta's.
A feature comparison of these two is therefore close to useless, and the section above explains why. They are not converging by coincidence. OpenClaw's memory design cites Letta's research in its own documentation, so of course the features rhyme.
What is actually left to compare is small and worth stating precisely. On memory, both keep files you can read in a repository you own; Letta commits every edit unprompted and uses that repository to carry memory between machines, while OpenClaw commits when you tell it to and keeps the workspace on the host. On reach, OpenClaw was built from the first day around being messaged and messaging you back, and it shows: its gateway comes up first and every interface, terminal included, is a way to reach it, where Letta starts a server only once you want an agent answering a chat account. That is the difference you feel in the first five minutes, and it is why one reads as a coding tool and the other as infrastructure. On scale, OpenClaw carries 389,807 GitHub stars against 3,350 on Letta's current repository, which is the difference between a problem someone has already solved for you and one you get to solve yourself.
The honest way to choose is not feature by feature. Pick OpenClaw if the value is an agent that reaches you where you already talk. Pick Letta if you are making a bet on where agent memory is heading and want to be standing next to the people writing it. Running both is coherent, and it is what we do: the gateway that answers your phone does not have to be the harness that learns your codebase.
Permission rules are not a sandbox, and the default is to allow everything
The question we get from everyone experimenting with agents on a personal machine is how to stop one from wandering into folders it has no business in. Letta gives you three levers, and they are not equally strong.
Permission modes decide how much the agent asks before acting. The documentation is blunt about the default: the interactive CLI starts in unrestricted mode, which allows tool calls unless a rule blocks them. standard asks before shell commands, edits, and subagents. acceptEdits allows file edits and asks about the rest. strict asks before every single call, including reads. You cycle the first three with Shift+Tab.
Rules narrow it further, and they persist. A .letta/settings.json file in a project takes allow and deny lists with patterns, so you can permit the two commands you actually want and deny the ones that would ruin your day:
{
"permissions": {
"allow": ["Bash(pnpm lint)", "Bash(pnpm test)", "Read(src/**)"],
"deny": ["Bash(rm -rf:*)", "Read(.env)"]
}
}
Stronger than either, and less widely used: you can control which tools get loaded at all. Starting the agent with --tools "Read,Glob,Grep" gives it no ability to write or run anything, because the capability is absent from its context rather than gated behind a prompt. An agent that was never handed a delete tool cannot be talked into using one.
There is also a guard you do not have to configure. A tool call that targets another agent's memory directory is refused even in unrestricted mode, so one agent cannot rewrite another's history by accident.
Now the honest part, which applies equally to both systems in this article. None of the above is isolation. Permission rules constrain software that agrees to be constrained, and they operate inside your filesystem, where your documents and your keys already live. OpenClaw's own documentation makes the same admission about its workspace, saying it is the default working directory rather than a hard boundary, and that its optional sandboxing "is not a perfect security boundary" even when switched on.
Real separation means changing where the agent runs rather than what it is allowed to do. In Letta that means changing its computer: a managed cloud sandbox, or a virtual machine or container of your own that you connect and let the agent work inside. Moving an agent does not carry your local files or secrets across, which is the entire point. For anything experimental, a cheap throwaway VM is a better answer than a carefully written deny list, and it takes less thought to get right.
Running Letta with no Letta account, on your own hardware
Letta self-hosts in two shapes, and the first requires no account at all.
The local runtime keeps all state, memory, messages and provider connections on your machine, and the two ways into it are not the same. The documentation is exact about it: "The CLI runs agents in-process. The desktop app uses a background App Server on your machine." So typing letta gives you an agent inside that terminal process and leaves no service behind when you close it, while the desktop app keeps one running. For a central always-on box, that App Server hosts your agents and exposes them to your own applications:
letta server --backend local --listen ws://127.0.0.1:4500
Messaging channels run as a separate process alongside it. There is a TypeScript SDK for embedding agents into your own software, a GitHub Action, and a headless mode for scripts and CI.
Two limits to plan around. Self-hosted agents are not reachable through Letta's web app and are not backed up for you, so that git repository holding everything your agent knows is yours to protect. And hosting locally does not mean computing locally: if you point Letta at Anthropic or OpenAI, your prompts still go there. Keeping inference on your hardware too means connecting a local model runtime such as Ollama or LM Studio.
What it costs: three agents free, twenty for $20, and the model bill on top
Letta's pricing as of September 16, 2026:
The free tier is $0 and caps you at three stateful agents, bringing your own API keys or an existing coding plan. Pro is $20 a month for up to twenty agents, remote sandboxes, and quota on Letta's routed model selection. The API plan is $20 a month for unlimited agents, charged at $0.10 per active agent per month plus a per-second rate for tool execution. Teams are $20 per seat.
The subscription is the small number. Letta's own guidance says casual coding use tends to run past $100 a month in model usage, and heavy use past $200, which matches what we see running agents daily. They recommend pairing the tool with a flat-rate coding plan instead of paying per token, and that advice is sound.
If the three-agent cap is what stops you experimenting, note that running fully local requires no account and therefore no cap.
What Letta is bad at
It is young, and the pace shows. A pre-1.0 version number, a product that replaced its own architecture this year, and 371 open issues add up to a tool that will change under you. Features get renamed mid-documentation; the docs currently call the same thing both "the Letta Harness" and "Letta Code" depending on the page.
The written record is worse than the software. Because the retired Python server carried the name for two years, most search results, tutorials, and comparison articles describe a product that no longer exists. You cannot trust anything about Letta that is not dated, including this page in six months.
The memory that makes it good also makes it opinionated. An agent that rewrites its own system prompt and consolidates lessons in the background is doing something you have to supervise, because a wrong lesson learned confidently is worse than no memory at all. Budget time for reading what it wrote about you.
And the ecosystem is small. When something breaks at 11pm, the number of people who have already hit it is in the thousands rather than the hundreds of thousands.
Who should run Letta
If your problem is that your AI tools forget everything, Letta is the most direct answer available and the memory design is worth studying whether or not you adopt it. Install it, run /init in a project you know well, work with it for a week, and read the git log of its memory afterward. That last step is the one that tells you whether the idea works for you.
If you want to know where agent memory is going rather than where it is, read the research page before you install anything. The papers are ahead of the product, which is unusual, and it is the clearest signal available about what these tools will do next year.
If your problem is reaching an agent from your phone, or having it start the conversation, that is a different tool, and OpenClaw is the one we would point you at first. There is no rule against running both, and we do.
If your problem is that a part of your business is waiting on somebody to do work a machine could do, the choice of harness is the last question rather than the first.
If you would rather not run it yourself
Choosing between these two is an afternoon of reading. What comes after is the work: deciding what an agent is allowed to touch, what it should remember about your customers and what it must never retain, where it runs so a mistake stays contained, and which of your systems stay off limits entirely. None of that arrives in the box, and getting it wrong is not a bug report.
That is what we do. It runs on your infrastructure, under your provider keys, with no markup on model costs, and you own it when we are done.
The useful thing to look at is not a description of the process but the work we have already shipped: a knowledge assistant searching internal documents, a booking system that removed ten hours of admin a week, an agent-operated drone fleet. If one of those looks like your problem wearing different clothes, that is the conversation worth having. How we run a deployment covers the mechanics.
Tell us what you are trying to automate and we will tell you whether an agent is the right shape for it, including when the answer is that it is not.
Sources
All checked September 16, 2026, against Letta 0.32.11 and OpenClaw 2026.9.2.
Letta's own material
- Letta documentation, including stateful agents, conversations, MemFS, memory and dreaming, permissions, subagents, computers, self-hosting, the CLI reference, and pricing
- AgentFile, the serialization format, documented in the retired V1 section
- Introducing Context Repositories and Letta Code: a memory-first coding agent, source of the design reasoning and the Terminal-Bench claim
- The Context Constitution
- letta-ai/letta and letta-ai/letta-code on GitHub, source of the archive notice and, through the GitHub API, every star and issue count above
- The npm registry entry for
@letta-ai/letta-code, source of the version and publish date
The research
- Letta's research index, source of the publication trail from MemGPT in 2023 to memory models in 2026
- Sleep-time Compute: Beyond Inference Scaling at Test-time, Letta and UC Berkeley, April 2025, the paper OpenClaw's dreaming documentation cites
- Memory Models: Towards Agents That Learn, June 2026, source of the memory-model direction and of the sentence naming Letta Code, Claude Code, DeepAgents and OpenClaw as harnesses that adopted token-space learning
- Do Large Language Models Dream of AI Agents?, WIRED, August 2025, on sleep-time compute
- Context-Bench and Recovery-Bench, the benchmarks Letta publishes
Background
- MemGPT: Towards LLMs as Operating Systems, the 2023 paper Letta grew out of
- Berkeley AI research lab spinout Letta raises $10M seed financing led by Felicis, September 26, 2024
OpenClaw, for the comparison
- The multi-agent, agent-workspace, sandboxing and dreaming documentation shipped with OpenClaw
2026.9.2, source of theopenclaw agents addcommand, the automaticgit initon a new workspace, the background memory consolidation, and the sandboxing caveat, also published at docs.openclaw.ai - openclaw/openclaw on GitHub, source of the star count