# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `knowledge-why-letta`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-why-letta`

**Title:** Why Letta?
**Published:** Wed, 12 Aug 2026 07:53:43 GMT
**Updated:** Wed, 12 Aug 2026 19:35:00 GMT
**Description:** An honest decision guide to the value and cost of switching from disposable AI sessions to a persistent Letta agent.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /why-letta
**Tags:** knowledge, lesson, ai, agents, letta, agent-runtime, memory, model-agnostic, self-hosting, decision-guide

**Content:**
```json
{
  "text": "Why Letta? is a decision guide for choosing a persistent-agent runtime. My assessment is that [Letta](https://www.letta.com/) is worth switching to when the long-lived object in your system should be the agent itself, rather than a chat session, model API call, or one-off process.\n\nLetta's advantage is continuity. One agent can retain inspectable memory across conversations, models, computers, and interfaces. Its cost is state. Memory needs curation, permissions need design, effects need reconciliation, and local or self-hosted deployments need ordinary operations work.\n\nThis page evaluates the architecture, not whether one model produces better answers than another. It draws from Letta's public documentation and software, then makes an attributed judgment about fit. Product details will change; the central trade remains useful.\n\n## What changes when you switch\n\nMost AI tools make the session or task the natural unit. Context is assembled for a run, the model acts, and the process ends. You can preserve a transcript or attach a database, but the application still treats each invocation as the main object.\n\n[Letta's state model](https://docs.letta.com/concepts/stateful-agents/index.md) makes the agent the main object:\n\n| Object | Role | Lifetime |\n| --- | --- | --- |\n| Agent | Identity, memory, model configuration, tools, and message history | Persists until deleted |\n| Conversation | One thread on an agent, sharing the agent's memory | Persists across connections |\n| Session | The active connection used to send messages and stream events | Ends when the connection closes |\n\nThat inversion changes application design. Instead of asking how to rebuild enough context for the next request, you ask which agent should receive the request, which conversation owns the thread, which memory belongs to the identity, and which execution environment should run the tools.\n\n## Reasons to choose Letta\n\n### Continuity belongs to the agent\n\nA [stateful Letta agent](https://docs.letta.com/concepts/stateful-agents/index.md) has its own long-term memory and can use that memory across separate conversations. This is useful when the value comes from accumulated understanding: a research partner learning a field, an operations agent learning a system, a coding agent learning a repository, or a teammate learning an organization.\n\nThe distinction is more than transcript retention. A transcript records what happened. Agent memory selects and revises what should shape future behavior.\n\n### Memory is inspectable\n\n[MemFS](https://docs.letta.com/concepts/memfs/index.md) stores agent memory in a Git-versioned filesystem. Files under `system/` stay in the active system prompt, while deeper files remain available for retrieval. Memory edits produce version history rather than disappearing into an opaque profile or vector index.\n\nInspectable memory gives the user and agent a shared repair surface. You can see what the agent believes, correct a stale source, reorganize a growing hierarchy, compare revisions, and restore an earlier state. That does not make the memory true. It makes the memory contestable.\n\n### The model is replaceable\n\nLetta supports multiple hosted providers, coding subscriptions, gateways, and local inference servers. The agent's identity and memory live in the harness rather than inside one model provider's chat product. You can change models while retaining the surrounding agent state.\n\nModel portability has a limit: different models will interpret the same memory and tools differently. Letta preserves the agent's state boundary, not identical behavior across substrates.\n\n### State and execution can live in different places\n\nThe [Agent SDK deployment model](https://docs.letta.com/agent-sdk/deployment/index.md) supports managed cloud agents, Letta-hosted state with tools on a computer you control, fully local agents, and self-hosted App Server deployments. The same SDK addresses those backends through one agent-and-session interface.\n\nThis separation is useful when memory placement and tool placement have different requirements. An agent can retain hosted state while operating on a workstation, or keep both state and execution on infrastructure you control.\n\n### One identity can inhabit several interfaces\n\nA signed-in Letta agent can be reached through the command line, desktop app, web app, connected computers, and supported messaging channels. Developers can place the same agent behind a custom application through the [Agent SDK](https://docs.letta.com/agent-sdk/index.md).\n\nThe important part is not the number of interfaces. The interfaces reconnect to an existing identity instead of creating unrelated assistants that happen to share a name.\n\n### The harness is open and extensible\n\n[Letta Code](https://github.com/letta-ai/letta-code) is Apache-2.0 licensed and exposes skills, subagents, schedules, permissions, channels, headless execution, and trusted local extensions. You can use the product directly or treat the harness as infrastructure inside another application.\n\nThat extensibility fits people who expect their agent system to become specific. A persistent agent eventually acquires local procedures, tools, memory organization, and effect policies that a generic chat interface cannot guess in advance.\n\n## Reasons not to switch\n\n### Your work is disposable\n\nIf each task is independent, persistence can add ceremony without adding value. A one-shot code transformation, isolated extraction job, or occasional question may need a strong model and a few tools rather than a persistent identity.\n\nThe simplest system that preserves the required state is usually the better system. Do not build a resident agent because a temporary process felt insufficiently alive.\n\n### Retrieval is the whole problem\n\nIf the application only needs to answer questions over a stable document set, a retrieval system may be enough. Letta becomes useful when an actor must interpret experience, revise its working context, remember decisions, and continue across tasks. It is excessive when the desired product is search with prose attached.\n\n### You want a workflow engine\n\nLetta agents can schedule work, use tools, and resume conversations. They do not remove the need for explicit workflow state when a process has binding transitions, deadlines, approvals, or exactly-once effects.\n\nUse deterministic code for deterministic transitions. Use the agent where judgment, synthesis, or adaptation earns its uncertainty. A persistent agent can operate inside a workflow; it should not be asked to remember the workflow's entire control state from vibes.\n\n### You do not want to operate state\n\nPersistent state creates maintenance work. Memory can become stale, contradictory, noisy, or overconfident. Conversations need ownership. Local agents need backups. Self-hosted servers need authentication, process supervision, upgrades, and recovery.\n\n[Self-hosted Letta](https://docs.letta.com/self-hosting/index.md) keeps state and execution under your control, but it also leaves backup and service reliability under your control. App Server has shell and filesystem access on its host, so it needs authentication and a trusted network boundary. Locality is custody, not the disappearance of operations.\n\n### You prefer one provider's tight integration\n\nA model-agnostic harness adds an abstraction layer. If your priority is one provider's exact interface, newest proprietary features, and smallest setup surface, that portability may be indirection you do not want.\n\nLetta's bet is that identity, memory, and operational context should outlive any one model. If you reject that premise, a provider-native tool is a more coherent choice.\n\n### You have not modeled the full cost\n\nLetta supports bring-your-own-key model access, personal plans, managed sandboxes, team features, and usage-based developer workloads. Those choices move costs among Letta, the model provider, your own hardware, and your operations time.\n\nThe [current pricing page](https://docs.letta.com/pricing/index.md) separates personal and developer usage and notes that tool-heavy or highly parallel work consumes more quota. Compare the complete workload rather than one subscription price.\n\n### You cannot define effect authority\n\nPermissions can restrict which tools an agent may use and which calls need approval. They do not decide your application's business rules for you. A write-capable agent still needs bounded authority, input validation, idempotency, and external receipts.\n\nThe current [permissions documentation](https://docs.letta.com/configuration/permissions/index.md) says the interactive command-line interface starts in `unrestricted` mode. Use `standard` or `strict` when the work should stop for approval. A convenient default is not an application security policy.\n\nAn agent that can act but cannot prove what happened is not operationally mature. It is merely enthusiastic with credentials.\n\n## What Letta does not provide automatically\n\nLetta supplies persistence primitives. Several properties still belong to the application:\n\n- **Good memory:** versioned files make memory inspectable, but the agent can still preserve the wrong lesson or fail to retrieve the right one.\n- **Exactly-once effects:** the [session contract](https://docs.letta.com/agent-sdk/sessions/index.md) says missed stream events are not replayed after disconnect, and a caller should inspect history before retrying an uncertain send.\n- **Equivalent models:** changing models preserves state, not judgment, tool skill, or response texture.\n- **Complete security policy:** permission modes and allowlists are enforcement tools; the application still defines who may authorize which effect.\n- **Automatic backup everywhere:** cloud-backed agents synchronize state, while local and self-hosted agents require their own backup plan.\n- **Deterministic improvement:** dreaming, memory edits, and skill changes create learning surfaces. Evaluation and promotion rules determine whether those changes are improvements.\n\nExposing these responsibilities is preferable to burying them under the word “agent.”\n\n## The smallest useful migration\n\nEvaluate Letta with one workflow whose value depends on continuity:\n\n1. Keep the model and core task as close as possible to the current setup.\n2. Create one agent and define which facts belong to its long-term identity.\n3. Give it one conversation for the workflow and one bounded tool surface.\n4. Add a skill only after a procedure repeats.\n5. Keep external effects read-only or approval-gated until the agent's classifications can be tested.\n6. Compare later work with the original baseline: retrieval quality, correction cost, repeated context loading, and recovery after interruption.\n\nDo not begin by connecting every model, channel, computer, and schedule. That evaluates migration complexity rather than the value of continuity.\n\n## Decision test\n\nAsk four questions:\n\n1. Would the same agent become more useful after remembering months of work?\n2. Should a user be able to inspect, edit, version, and restore that memory?\n3. Should the identity survive a change in model, interface, or execution computer?\n4. Are you willing to operate the resulting state and effect boundaries?\n\nIf the first three answers are yes and the fourth is acceptable, Letta is a strong fit. If the transcript is enough, keep the simpler tool.\n\n[Your First Persistent Agent](https://cameron.stream/knowledge/first-persistent-agent) supplies a runnable starting point. [Choosing an Agent Topology](https://cameron.stream/knowledge/choosing-an-agent-topology) and [Agent Authority and Effects](https://cameron.stream/knowledge/agent-authority-and-effects) cover the first architectural choices after the demo. The complete collection is [Building with Letta Agents](https://cameron.stream/knowledge/building-with-letta-agents).\n\n## Sources\n\n- [Stateful agents](<https://docs.letta.com/concepts/stateful-agents/index.md>)\n- [MemFS](<https://docs.letta.com/concepts/memfs/index.md>)\n- [Conversations](<https://docs.letta.com/concepts/conversations/index.md>)\n- [Letta Agent SDK overview](<https://docs.letta.com/agent-sdk/index.md>)\n- [Letta Agent SDK session lifecycle](<https://docs.letta.com/agent-sdk/sessions/index.md>)\n- [Deploying your agents](<https://docs.letta.com/agent-sdk/deployment/index.md>)\n- [Permissions](<https://docs.letta.com/configuration/permissions/index.md>)\n- [Self\\-hosting](<https://docs.letta.com/self-hosting/index.md>)\n- [Letta pricing](<https://docs.letta.com/pricing/index.md>)\n- [Letta Code source](<https://github.com/letta-ai/letta-code>)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
```

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*