Урок 9.5. Letta: stateful agents и память как операционная система

Цель лекции

Разобрать Letta, бывший MemGPT, как пример agent runtime, где память является частью жизненного цикла stateful agent, а не только внешним retrieval service.

Ожидаемый результат

Читатель понимает модель Letta: memory blocks, files, archival memory, tools, persistent state и self-editing context. Он умеет отличать Letta-style architecture от Mem0/Zep-style memory service.

Зачем это нужно

Mem0 и Zep в основном отвечают на вопрос:

Как внешняя memory layer хранит и возвращает нужный контекст?

Letta ставит вопрос иначе:

Как построить агента, который живет долго,
сохраняет состояние и сам управляет своим контекстом?

Это ближе к идее Memory-as-an-OS из Module 05. Агент имеет ограниченное context window, но может использовать разные типы памяти и инструменты, чтобы переносить информацию между active context и external memory.

Основная идея

Letta - это framework/runtime для stateful agents. В центре не только storage, а agent harness: агент, его контекст, инструменты, память, состояние и серверный runtime.

Память в Letta устроена иерархически:

важные сведения могут жить прямо в context window как memory blocks;
большие документы могут подключаться как files;
менее срочные или большие воспоминания могут храниться во внешней archival memory;
внешние базы/RAG могут быть доступны через tools или MCP;
агент может обновлять часть памяти через tool-calling.

Ключевые термины

Термин	Короткое определение
`Stateful agent`	Агент, состояние которого сохраняется между взаимодействиями.
`Memory block`	Структурированный блок памяти, который находится в контексте агента и может быть read-write или read-only.
`Core memory`	Наиболее важная память, доступная агенту напрямую в prompt/context.
`Archival memory`	Внешняя долговременная память, к которой агент обращается через search/insert tools.
`Self-editing memory`	Способность агента самостоятельно обновлять свои memory blocks через tools.
`Agent runtime`	Серверная среда, которая хранит agent state, messages, tools, memory и executions.
`Context hierarchy`	Порядок, в котором разные источники контекста попадают в окно модели.

Иерархия контекста

flowchart TD A["User message"] --> R["Letta agent runtime"] R --> B["Memory blocks in context"] R --> F["Files opened or searched"] R --> M["Built-in memory tools"] R --> T["External tools or MCP"] M --> C["Core memory update"] M --> D["Archival memory insert or search"] T --> E["External RAG or app database"] B --> X["Context window"] F --> X D --> X E --> X X --> L["LLM step"] L --> M L --> T L --> O["Response or action"]

Ключевая мысль: Letta не просто "достает память перед LLM call". Он дает агенту инструменты управления памятью.

Memory blocks как core memory

Memory block - это структурированный раздел, который всегда виден агенту в контексте.

Примеры blocks:

persona:
  You are a concise technical tutor.

human:
  User is Ivan. He prefers Russian technical prose.

project:
  Current project is AI Agent Memory Guide 101.

policies:
  Never store secrets. Ask before saving sensitive personal data.

Почему это важно:

retrieval не нужен для самых критичных facts;
агент всегда видит свою persona, user facts and policies;
блоки можно делать read-only;
блоки можно шарить между агентами;
описание блока помогает агенту понять, что туда писать.

Ограничение: context window не бесконечен. Если положить туда слишком много, core memory превратится в context rot.

Archival memory

Archival memory нужна для сведений, которые не должны постоянно находиться в prompt, но могут понадобиться позже.

Примеры:

прошлые эпизоды;
заметки по проектам;
длинные summaries;
старые обсуждения;
редко используемые preferences;
research notes.

Паттерн:

Core memory:
- кто пользователь;
- текущие цели;
- критичные правила.

Archival memory:
- подробная история;
- old project notes;
- less important facts;
- searchable long-term traces.

Агент может использовать built-in tools для вставки и поиска archival memories.

Self-editing memory

Одна из ключевых идей Letta/MemGPT: агент может сам решить, что память нужно изменить.

Пример:

User: From now on, answer in Russian unless I ask otherwise.

Agent internal action:
- call memory_replace or memory_insert on the human/preferences block.

Future behavior:
- default language becomes Russian.

Это мощно, но рискованно.

Нужны ограничения:

read-only policy blocks;
approval for sensitive memory;
audit of memory tool calls;
tests for accidental overwrite;
limits on block size;
conflict handling.

Letta как Agent-as-a-Service

Letta-style architecture шире, чем memory SDK.

Обычно runtime отвечает за:

agents;
messages;
memory blocks;
tools;
long-running execution;
persistence;
server API;
SDK;
optional managed deployment or self-hosted server.

Это ближе к platform for stateful agents, чем к одному storage component.

Лучшие сценарии использования

Letta особенно подходит, когда агент:

живет долго;
имеет persona and goals;
сам вызывает tools;
должен помнить свой рабочий контекст;
выполняет многошаговые задачи;
возвращается к старым задачам;
нуждается в explicit memory management;
может пользоваться custom tools and files.

Примеры:

autonomous research assistant;
personal work agent;
coding coworker;
long-running operations assistant;
Slack/Discord/Telegram coworker;
multi-agent system with shared blocks.

Чем Letta отличается от Mem0 и Zep

Вопрос	Mem0	Zep/Graphiti	Letta
Центр тяжести	User memory records	Temporal knowledge graph	Stateful agent runtime
Кто управляет памятью	Framework + app logic	Framework/platform + graph logic	Agent через tools + runtime
Что всегда в prompt	Обычно selected memories	Retrieved context	Memory blocks
Сильная сторона	Personalization facts	Temporal relationships	Long-lived agent state
Риск	Over-personalization	Graph complexity	Agent corrupts its own context

Letta лучше выбирать не потому, что "там есть память", а когда вам нужен агент, который сам управляет своим состоянием.

Мини-пример: агент обновляет core memory

Псевдокод:

python
from letta_client import Letta

client = Letta(token="...")

agent = client.agents.create(
    name="course-assistant",
    memory_blocks=[
        {
            "label": "human",
            "value": "User prefers Russian explanations.",
        },
        {
            "label": "project",
            "value": "Project: AI Agent Memory Guide 101.",
        },
    ],
)

client.agents.messages.create(
    agent_id=agent.id,
    messages=[
        {
            "role": "user",
            "content": "Теперь давай примеры сначала, а теорию после.",
        }
    ],
)

В Letta-style agent правильное поведение может включать tool call, который обновит block human или preferences.

Evaluation для stateful agents

Обычный unit test:

input -> output

недостаточен.

Для Letta-style agents нужно тестировать:

memory read;
memory write;
memory update;
accidental overwrite;
tool-call correctness;
state evolution;
multi-turn behavior;
long-running executions;
recovery after restart.

Letta отдельно развивает eval-подход к stateful agents, потому что модель выбора LLM для agentic memory может отличаться от обычных LLM leaderboards.

Инфраструктурные требования

Letta может быть тяжелее простого memory SDK, потому что требует runtime.

Нужно учитывать:

server deployment;
database for persistent state;
model provider;
tool execution environment;
secrets management;
memory block governance;
concurrency;
backups;
observability;
evals.

Self-hosting обычно проще, чем строить всю систему с нуля, но сложнее, чем подключить легковесный SDK для user preferences.

Типичные ошибки

Ошибка 1: давать агенту право менять все blocks.

Policy, compliance и critical instructions должны быть read-only.

Ошибка 2: переполнять core memory.

Если все положить в prompt, agent memory снова превратится в context rot.

Ошибка 3: не логировать memory tool calls.

Если агент сам изменил память, это должно быть видно.

Ошибка 4: считать archival memory заменой RAG.

Для больших document corpora часто лучше external RAG или file/search tools.

Ошибка 5: не тестировать state evolution.

Ошибки Letta-style agents часто проявляются не в первом ответе, а через 20 turns.

Ошибка 6: путать runtime и storage.

Letta управляет agent state, но source-of-truth business data все равно может жить в ваших системах.

Когда выбрать Letta

Выбирайте Letta, если:

нужен долгоживущий агент;
агент должен самостоятельно редактировать часть памяти;
важны memory blocks and persona;
нужен agent runtime, а не только retrieval API;
есть tool-heavy workflows;
вы готовы тестировать stateful behavior.

Не выбирайте Letta как первый инструмент, если:

нужно просто хранить 10 user preferences;
нет long-running state;
agent не должен сам менять память;
команда не готова управлять runtime;
high-stakes policies требуют жесткого внешнего контроля.

Источники для дальнейшего чтения

Letta docs: https://docs.letta.com/
Letta memory blocks: https://docs.letta.com/v1-sdk/memory/memory-blocks
Letta context hierarchy: https://docs.letta.com/v1-sdk/memory/context-hierarchy
Letta Leaderboard: https://www.letta.com/blog/letta-leaderboard/

Краткое резюме

Letta - это не просто memory store. Это runtime для stateful agents, где память живет в иерархии: memory blocks в контексте, files, archival memory, external RAG and tools.

Главный trade-off: Letta дает агенту больше автономии в управлении памятью, но требует governance, evals и наблюдаемости за memory tool calls.

Вопросы для самопроверки

Чем memory block отличается от retrieved memory?
Почему self-editing memory одновременно полезна и опасна?
Какие данные лучше держать в core memory, а какие в archival memory?
Почему Letta ближе к agent runtime, чем к simple memory SDK?
Какие evals нужны для stateful agents?

Что дальше

В следующей лекции мы сравним Mem0, Zep и Letta как архитектурные выборы: где выигрывает compact personalization, где temporal graph, а где agent-managed state.