Урок 13.4. Memori: agent-native memory из действий, сессий и атрибуции

План лекции

Сначала мы разберем, чем Memori отличается от Cognee and Supermemory. Его главный тезис: память должна строиться не только из слов пользователя, но и из того, что агент делает - tool calls, decisions, outcomes, sessions and execution traces.

Затем перейдем к основным primitives Memori: attribution, entity, process, session, automatic persistence, recall and Advanced Augmentation. После этого обсудим варианты внедрения через SDK, MCP, OpenClaw, Hermes and BYODB. В конце проверим, где Memori особенно полезен, какие риски есть у такого подхода and как тестировать agent-native memory.

Цель лекции

Понять Memori как agent-native memory infrastructure: LLM-agnostic слой, который превращает agent execution and conversations в structured persistent state для production systems.

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

После лекции читатель умеет объяснить:

• почему Memori делает акцент на действиях агента, а не только на conversational facts;
• зачем нужны entity_id, process_id and session;
• что такое Advanced Augmentation;
• как Memori подключается к LLM clients and agent platforms;
• в каких задачах Memori полезнее обычного memory SDK.

Короткая карточка инструмента

Memori описывает себя как LLM-agnostic, datastore-agnostic and framework-agnostic слой. Это важное позиционирование: проект пытается встроиться в уже существующую архитектуру, а не заставить команду переписать весь agent stack.

Почему "что агент делает" важнее, чем кажется

Во многих memory systems источником памяти считается dialogue transcript:

user said X
assistant answered Y
extract facts
store facts

Но production agent часто ценен не словами, а действиями:

• вызвал tool;
• получил ошибку;
• выбрал workaround;
• обновил ticket;
• отправил email;
• сделал deploy;
• откатил миграцию;
• нашел root cause;
• принял решение не выполнять risky command.

Если память видит только conversation text, она теряет operational knowledge. Агент может помнить, что пользователь любит краткие ответы, но забыть, что в прошлый раз deploy сломался из-за устаревшего lock file. Memori закрывает именно эту дыру: agent memory должна включать execution state.

Базовая mental model

Memori можно представить как слой, который оборачивает LLM client or agent runtime и добавляет persistent memory в background.

Смысл схемы: память не живет отдельно от runtime. Она привязывает interaction к субъекту, процессу and сессии. Благодаря этому later recall может быть не просто "найди похожее", а "восстанови relevant state для этого entity in this process".

Ключевые primitives

Эти primitives полезны тем, что заставляют проектировать memory ontology заранее. В memory systems хуже всего работает "просто положим все в одну коллекцию". Memori подталкивает к вопросу: кто действует, какой процесс действует, в какой сессии and какой state надо перенести дальше.

Attribution как основа безопасности и качества

В README Memori прямо указано: чтобы получать пользу, нужно attribute LLM interactions to an entity and a process; без attribution Memori не может создавать memories.

Это кажется мелкой SDK-деталью, но архитектурно это центральное правило.

Плохая схема:

all_messages -> memory

Хорошая схема:

entity_id=user_123
process_id=support_agent
session_id=session_456
messages/tool_results -> memory

Attribution решает сразу несколько задач:

• не смешивает пользователей;
• отделяет memory разных agents;
• позволяет анализировать поведение конкретного process;
• помогает удалять или экспортировать memory по entity;
• дает основу для audit trail.

Если Supermemory использует containerTag как удобный scope, то Memori делает attribution более явной и многомерной.

Session management

Session нужна, когда agent task состоит из нескольких шагов. Например:

1. Пользователь просит проанализировать incident.
2. Агент читает logs.
3. Агент вызывает monitoring API.
4. Агент сравнивает deploy history.
5. Агент формулирует root cause.
6. Агент создает ticket.

Если все эти actions хранятся как независимые memories, later recall может потерять причинную связь. Session позволяет сохранить целостность эпизода.

В терминах курса это уже не просто semantic memory. Это episodic memory with action traces.

Advanced Augmentation

Memori Advanced Augmentation обогащает memories на нескольких уровнях: entity, process and session. В README перечислены типы enrichment:

• attributes;
• events;
• facts;
• people;
• preferences;
• relationships;
• rules;
• skills.

Главная идея: raw messages and raw tool outputs плохо подходят для будущего recall. Их нужно преобразовать в structured state.

Например, после troubleshooting-сессии система может сохранить:

Такой результат гораздо полезнее полного transcript. Агенту не нужно перечитывать весь прошлый диалог, чтобы понять, что важно сейчас.

Agent-native memory vs conversation-native memory

Conversation-native memory хорошо отвечает на вопрос:

Что пользователь сказал?

Agent-native memory отвечает на более широкий вопрос:

Что произошло в ходе работы агента?

Разница особенно заметна в tasks with tools.

Именно поэтому Memori хорошо подходит к coding agents, support agents, data agents and workflow agents.

Интеграция через SDK

Memori имеет Python and TypeScript SDK. README показывает простой pattern:

Memori().llm.register(client).attribution(entity, process)

Для архитектора важнее не синтаксис, а форма integration:

Такой wrapper pattern удобен: команда может оставить OpenAI, Anthropic, Gemini or another provider, но добавить memory behavior вокруг вызовов. Это снижает migration cost.

Supported LLMs and frameworks

README перечисляет поддержку Anthropic, Bedrock, DeepSeek, Gemini, Grok/xAI and OpenAI, включая Chat Completions and Responses API. Также указаны unstreamed, streamed, synchronous and asynchronous modes.

Из frameworks упоминаются Agno, LangChain and Pydantic AI. Для курса важно вынести общий принцип: memory layer должен быть provider-agnostic там, где это возможно.

Если память жестко привязана к одному LLM SDK, она становится частью vendor lock-in. Memori пытается быть тонким слоем вокруг разных clients.

MCP, OpenClaw and Hermes

Кроме SDK, Memori предоставляет integrations for agent tools.

MCP-вариант позволяет подключить память к clients вроде Claude Code, Cursor, Codex, Warp or Antigravity. Здесь memory становится tool, который agent может вызывать через protocol.

OpenClaw plugin захватывает structured memory after each turn: tool calls, decisions and outcomes. Это особенно близко к идее agent-native memory.

Hermes integration дает explicit tools вроде recall and recall summary. Это полезно, когда agent должен сам контролировать момент retrieval, а не получать память всегда автоматически.

Разные способы integration нужны для разных maturity stages. На раннем этапе удобно подключить MCP. В product backend лучше SDK. Для gateway-style agent runtime подходит plugin.

BYODB and enterprise deployment

Memori подчеркивает, что работает с existing data infrastructure and supports BYODB. В README также упоминаются managed cloud, single-tenant cloud, VPC and on-premises.

Это важный enterprise signal. Для компаний память агента - чувствительный слой. Она может содержать:

• customer data;
• internal decisions;
• tool outputs;
• code snippets;
• credentials accidentally pasted by users;
• legal or financial context.

Поэтому вопрос deployment не второстепенен. Иногда hosted API подходит для прототипа, но production требует VPC or on-prem. BYODB помогает вписать memory layer в уже существующие policies around backups, encryption, access control and retention.

Типы памяти из курса

Memori особенно интересен для procedural and episodic aspects. Он помогает сохранять не только "что известно", но и "как агент работал".

Мини-кейс: DevOps agent

Представим agent, который помогает с деплоем.

Без Memori он помнит только текущий чат. Если deploy уже падал из-за Poetry lock, через неделю агент снова может повторить ошибочный шаг.

С Memori можно сохранить:

В следующей сессии agent получает не transcript, а reusable operational state. Это и есть ценность agent-native memory.

Мини-кейс: customer support agent

Support agent использует tools: CRM, billing, logs, ticket system. В таком сценарии память только из conversations неполна. Нужно помнить actions:

• какие tickets уже проверены;
• какой workaround сработал;
• какой customer environment нестандартный;
• какие actions нельзя повторять;
• какой escalation path был выбран.

Memori может сохранять session outcome and process rules. Это позволяет агенту не только отвечать "похоже на прошлый случай", но и помнить, какие шаги уже были выполнены.

Как тестировать Memori

Тестировать нужно не только recall facts. Нужно проверять lifecycle.

Для quality evaluation полезно составить synthetic scenarios: две похожие сессии, два разных пользователя, один устаревший факт, один повторяющийся workflow and один tool failure.

Сравнение с Supermemory

Supermemory удобен, когда нужно быстро дать AI product persistent user context. Memori сильнее выделяет agent lifecycle: кто действует, какой process действует, какая session образует episode.

Сравнение с Cognee

Cognee graph-first: он строит knowledge graph from data and relationships. Memori agent-first: он привязывает memory к execution context.

Если вы строите research memory по массиву документов, Cognee может быть естественнее. Если вы строите agent runtime, который должен помнить decisions, tool outcomes and process rules, Memori ближе к задаче.

На практике эти подходы можно комбинировать:

Memori хранит "что агент сделал". Cognee хранит "как knowledge entities связаны". Вместе они могут дать более полную память.

Риски и ограничения

Первый риск - скрытая сложность background augmentation. Если система сама извлекает rules, preferences and skills, команда должна понимать, как отлаживать ошибки. Неправильно извлеченное правило может повторяться долго.

Второй риск - over-capture. Agent execution может содержать sensitive tool outputs. Нужно решать, какие tools разрешено сохранять, какие поля маскировать and какие events вообще не должны попадать в memory.

Третий риск - attribution mistakes. Если process_id or entity_id выбран неправильно, memory будет точной, но примененной не там.

Четвертый риск - evaluation gap. Agent-native memory труднее тестировать, чем обычный RAG, потому что качество зависит от sequences of actions, not just static queries.

Практический rollout

Для внедрения Memori лучше идти постепенно.

1. Начать с одного agent process.
2. Явно определить entity_id, process_id, session boundaries.
3. Сохранять только conversation summaries and tool outcomes low-risk типа.
4. Добавить recall in manual mode, чтобы видеть, что агент получает.
5. Проверить cross-entity and cross-process isolation.
6. Добавить Advanced Augmentation for rules/preferences.
7. Только после этого подключать sensitive tools and enterprise data.

Такой подход позволяет поймать ошибки scoping before memory becomes invisible infrastructure.

Антипаттерны

Первый антипаттерн - считать attribution технической формальностью. На самом деле это contract ownership.

Второй антипаттерн - сохранять raw tool outputs без redaction. Это прямой путь к privacy incidents.

Третий антипаттерн - давать агенту всю session history вместо structured memory. Тогда memory layer не снижает token pressure.

Четвертый антипаттерн - не отделять process memory от user memory. Preference пользователя и habit конкретного agent workflow - разные вещи.

Чек-лист выбора Memori

Memori стоит рассмотреть, если:

• агент выполняет multi-step tasks;
• важны tool calls, decisions and outcomes;
• нужно различать entity, process and session;
• команда хочет LLM/provider-agnostic memory layer;
• есть enterprise deployment requirements;
• память должна отражать не только разговоры, но и execution;
• полезны integrations with MCP, OpenClaw or Hermes.

Если же вам нужен только поиск по документам, Memori может быть избыточен. Если нужна глубокая graph traversal аналитика, стоит сравнить с Cognee or Zep.

Источники

• GitHub repository: https://github.com/MemoriLabs/Memori
• README sections on quickstart, attribution, sessions and Advanced Augmentation: https://github.com/MemoriLabs/Memori/blob/main/README.md
• Memori product/docs entry: https://memorilabs.ai
• Memori BYODB entry from README: https://memorilabs.ai/docs/memori-byodb/

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

Memori показывает важный architectural pattern: память агента должна учитывать не только диалог, но и выполнение. Entity, process and session образуют каркас, который помогает хранить structured persistent state без смешивания пользователей, агентов and эпизодов.

Главная сила Memori - agent-native orientation. Он подходит там, где агент работает с tools, принимает решения, выполняет workflows and должен переносить опыт между сессиями.

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

1. Почему память из transcript неполна для tool-using agents?
2. Чем entity отличается от process?
3. Зачем нужна session в multi-step task?
4. Какие типы enrichment входят в Advanced Augmentation?
5. Какой риск возникает при неправильном attribution?
6. Почему raw tool outputs нельзя бездумно сохранять в memory?
7. Чем Memori отличается от Supermemory?
8. В каком случае Cognee будет естественнее, чем Memori?

Что дальше

В следующей лекции мы разберем memU - memory layer с акцентом на user memory, learning from conversations and agent personalization. После Memori важно увидеть более компактный подход к memory extraction and retrieval, чтобы сравнить agent-native и user-centric patterns.