Building with Letta agents is a selective index for people and agents working with Letta's persistent-agent stack. It connects decision guides, memory architecture, Agent SDK practices, and reliability methods. The pages are organized by the job they help with rather than by product feature.
Each page stands alone. Use this map when you know the problem but not the document name. For current commands, options, and product behavior, retrieve the official Letta documentation rather than treating this index as API reference.
Decide whether Letta fits
Why Letta? weighs the architectural case for switching against the cost of operating persistent state. Start there when the question is whether one persistent agent should own the work.
The surrounding reference pages separate the main public objects:
- Letta describes the research lab and software company.
- Letta Agent describes the personalized stateful agent product.
- Letta Code describes the open agent harness used through the command line, desktop app, web, and messaging surfaces.
- The Letta Agent SDK is the application interface for creating and resuming stateful agents from code.
Understand the state model
The official stateful-agent guide defines the agent as the persistent identity. Conversations are separate threads that share the agent's memory, while sessions are temporary runtime connections.
The Agent Memory map covers the harder design questions that begin after persistence works:
- Context Repositories make long-lived context inspectable and versioned.
- Routing-Based Agent Memory selects which sources should enter a turn.
- Context Compaction keeps a bounded working view of long histories.
- Strong Context References bind mutable sources to the exact version an agent observed.
- Public and Private Knowledge separates useful synthesis from privileged context that should not travel.
Use these pages when an agent remembers the wrong thing, fails to retrieve something it already knows, or accumulates so much context that every fact competes with every other fact.
Build with the Agent SDK
The Agent SDK quickstart covers installation, creation, and the first streamed turn. Your First Persistent Agent turns those mechanics into a complete application that saves IDs, resumes the same conversation, reattaches a client tool, asks for approval, and tests reconnect recovery.
Choosing an Agent Topology explains when to use one agent, several conversations, per-user agents, role-specific agents, or shared memory. The distinction matters because conversations on one agent share memory.
Learning from Documentation with the Letta Agent SDK is a more specialized application pattern. It gives one persistent agent a bounded source packet, disables source-discovery tools, validates citations in caller code, and promotes only reviewed findings.
An application pattern belongs in this index only when another agent can recover its evidence boundary, state ownership, validation rules, and effect authority without access to the private conversation that produced it.
Bound authority
Agent Authority and Effects separates five boundaries: tool availability, invocation approval, business authority, effect identity, and provider receipts. Letta supplies tool and approval controls. The host application still owns domain policy and external reconciliation.
Use this page before giving an agent write-capable client or MCP tools. An approval callback is useful, but it is not a substitute for tenant checks, idempotency, or provider readback.
Make automation recoverable
Persistence makes longer work possible, but it does not prove that an external effect occurred. These pages cover the reliability layer:
- Recoverable Agent Execution models work as resumable state transitions rather than one long prompt.
- Agent Trajectory Observability connects selected context, model runs, tool calls, and effects.
- Structured Outputs makes generated data machine-checkable without pretending that schema validity proves truth.
- Spec-Driven Development for AI Coding Agents preserves intent and verification evidence when implementation is delegated.
For write-capable or recurring automation, establish effect identity, idempotency, bounded concurrency, provider readback, and delivery receipts before adding autonomy. An agent's statement that it completed a task is useful output. The external system's readback is the receipt.
Choose a reading path
Use the following paths as starting points:
- Evaluating Letta: Why Letta? → Stateful agents → Deployment options.
- Building an SDK application: SDK quickstart → Your First Persistent Agent → Choosing an Agent Topology.
- Adding write-capable tools: Agent Authority and Effects → Recoverable Agent Execution → Agent Trajectory Observability.
- Repairing memory: Agent Memory → Routing-Based Agent Memory → Context Compaction.
- Building a source-grounded learner: Documentation-learning pattern → Structured Outputs.
The broader Knowledge map covers subjects outside Letta and agent infrastructure.