Это тринадцатый и заключительный материал текущей серии «ИИ-компания». В ней я последовательно разбираю, как ИИ-агенты меняют ответственность, структуру, роли, экономику и практику управления организацией.
Мы уже рассмотрели компанию как граф задач, роли как временные контракты, ответственность за агентную работу, стоимость принятого результата, пределы микрокомпании и человеческие решения, которые нельзя автоматически передать системе.
Но между всеми этими частями остаётся ещё один слой.
Память.
Если несколько агентов участвуют в одном процессе, недостаточно просто дать каждому инструкции и доступ к инструментам. Они должны понимать, что происходило до них, какие решения уже приняты, откуда взялись данные, какая версия считается действующей и что должен получить следующий участник процесса.
Без этого компания не становится агентной. Она получает несколько быстрых исполнителей, каждый из которых начинает работу со своей версии реальности.
Один агент может жить в чате. Организация — нет
Пока человек работает с одним агентом, память часто выглядит как история переписки.
В начале диалога я объясняю задачу. Затем добавляю контекст, исправляю ошибки и принимаю промежуточные решения. Агент использует предыдущие сообщения и продолжает работу.
Проблема становится заметной, когда процесс выходит за пределы одного разговора.
Например, при подготовке статьи для pimenov.ai один агент может проверить, нет ли на сайте дублирующего материала. Другой собирает первичные источники. Следующие готовят структуру, текст, критическую проверку и иллюстрации. После этого материал нужно собрать для Notion, проверить сохранность ссылок и сопоставить черновик с опубликованной страницей.
Это уже не один диалог. Это последовательность задач, инструментов, состояний и решений.
Если каждый новый агент получает всю историю целиком, контекст быстро разрастается. В него попадают устаревшие версии текста, длинные результаты инструментов, отброшенные гипотезы и решения, которые позднее были пересмотрены.
Если же новый агент не получает историю, он начинает исследование заново, повторяет выполненную работу или использует решение, которое давно перестало быть актуальным.
Значит, организации нужна способность восстанавливать необходимое состояние работы вместо передачи бесконечной истории разговоров.
Агенту нужно помнить разговор. Организации нужно помнить, почему её текущее состояние считается правильным.
Общий контекст — ещё не общая память
Слова «контекст», «память», «база знаний» и «история» часто используются как синонимы. Технически это разные вещи.
Google Agent Development Kit разделяет три уровня: Session содержит историю одного разговора, State хранит изменяемые данные текущего взаимодействия, а MemoryService позволяет искать информацию из прошлых сессий и других источников. История сообщений не равна знаниям организации. Google ADK: Memory
Похожее разделение есть в OpenAI Agents SDK. Сессии поддерживают историю взаимодействия, а отдельный экспериментальный механизм agent memory извлекает уроки из предыдущих запусков и сохраняет их за пределами текущего диалога. OpenAI Agents SDK: Sessions и Agent memory
Anthropic описывает ещё одну границу: контекст модели остаётся конечным ресурсом. Поэтому в длинных процессах используются сжатие истории, структурированные заметки и внешние артефакты, которые при необходимости возвращаются в контекст. Effective context engineering for AI agents
Получается простая схема:
- память хранит потенциально полезный опыт;
- поиск выбирает релевантные фрагменты;
- контекст содержит то, что агент видит прямо сейчас;
- источник истины определяет, какое состояние считается действующим.
Смешивание этих уровней создаёт опасную иллюзию. Агент может найти похожий фрагмент в памяти, но это ещё не означает, что фрагмент актуален, подтверждён и разрешён для использования.
Что должна помнить ИИ-компания
ИИ-компания должна уметь восстановить:
- какой результат требуется;
- кому он предназначен;
- кто владеет результатом;
- в каком состоянии находится задача;
- какие решения уже приняты;
- какие гипотезы были отвергнуты;
- откуда получены данные;
- какая версия является действующей;
- какие действия выполняли люди и агенты;
- кто имеет право продолжить процесс;
- где работа должна остановиться;
- что передать следующему участнику.
Так память превращается из функции чат-бота в часть устройства организации.
Что агенты должны знать друг о друге
Агентам не требуется читать все переписки остальных агентов.
Исследователь не обязан знать внутреннее рассуждение агента, который готовит изображения. Издателю не нужен полный черновой поиск автора. Проверяющему не обязательно видеть каждую отвергнутую формулировку.
Для совместной работы агенту достаточно знать роль другого агента, его возможности и полномочия, текущую задачу, статус, созданные артефакты, уровень проверки результата, возникшие ограничения и ожидаемый формат передачи.
Это управляемая видимость рабочего состояния без попытки создать «коллективное сознание».
Агентам не нужно знать всё друг о друге. Им нужно понимать, какой результат создан, насколько ему можно доверять и что должно произойти дальше.
Семь контуров организационной памяти
Для практической работы я предлагаю разделить память ИИ-компании на семь контуров.
Перед нами авторская модель, которую я собираю в процессе разработки серии и одновременно проверяю на собственных процессах pimenov.ai. Статуса общепринятого стандарта у неё нет.
1. Рабочая память
Содержит промежуточные данные одного запуска: найденные фрагменты, временные расчёты, черновые формулировки, результаты инструментов и текущие предположения. Большая часть этой информации не должна становиться постоянной.
2. Состояние задачи
Отвечает на вопрос: где сейчас находится работа? Например: источники собраны, структура принята, текст ожидает проверки, черновик записан в Notion, публикация требует отдельного подтверждения.
3. Событийная память
Хранит последовательность значимых действий: кто создал результат, кто его изменил, кто подтвердил, какая версия была опубликована, где возникла ошибка и был ли выполнен откат.
4. Фактическая память
Содержит подтверждённые сведения об объектах организации: клиенте, материале, договоре, задаче, источнике, решении, платеже или публикации. Здесь память соприкасается с онтологией. Онтология определяет смысл сущностей и связей, память сохраняет их конкретные состояния и изменения.
5. Эпизодическая память
Сохраняет опыт предыдущих запусков. Например, при прошлой записи статьи в Notion потерялись внешние ссылки или заголовок обещал тридцать признаков, которых не было в тексте. Пока это отдельные события. Организация может извлечь из них правила.
6. Процедурная память
Содержит знания о том, как выполняется работа: workflow, критерии приёмки, шаблоны, навыки агентов, stop-lines, порядок публикации и восстановление после ошибки.
7. Источник истины
Определяет каноническое состояние объекта. Для задачи им может быть Plane, для редакционного текста — Notion, для версии программы — Git, для опубликованного материала — фактическая страница сайта.
Источник истины нельзя заменить пересказом, сохранённым в памяти агента. Если агент помнит, что статья опубликована, но сайт доступен для проверки, нужно проверить сайт.
Векторная база не является памятью компании
Векторный поиск отвечает на вопрос: какие фрагменты похожи по смыслу на запрос?
Он не гарантирует, что найденный фрагмент актуален, подтверждён, относится к текущей версии, доступен этому агенту или даёт право совершить действие.
Исследование Mem0 показывает, что выборочное извлечение сохранённых фактов может снижать объём передаваемого контекста и на конкретном разговорном бенчмарке давать лучший результат, чем передача полной истории. Однако опубликованные показатели получены авторами Mem0 на собственном решении и не доказывают такой же эффект для любой организационной системы. Исследование Mem0
Векторный индекс помогает найти память. Граф знаний помогает понять связи. Журнал событий показывает последовательность. Источник истины сообщает текущее состояние. Эти механизмы дополняют друг друга, а не заменяют.
Федеративная память вместо одной огромной базы
Интуитивно кажется, что для общей памяти нужно собрать всю информацию компании в одном месте. На практике копия начинает расходиться с системами, в которых реально происходят изменения.
Поэтому я предлагаю понятие федеративной памяти ИИ-компании.
Федеративная память — это архитектура, в которой канонические данные остаются в своих системах, но становятся доступны агентам через общие идентификаторы, правила и механизмы поиска.
Она позволяет агенту определить, с каким объектом он работает, где находится источник истины, что можно получить из памяти, что требуется перепроверить и куда разрешено записать изменение.
Канонические базы могут оставаться раздельными. Общими становятся идентичность объектов, смысл связей и правила работы с ними.
Паспорт памяти
Сохранённый текст без происхождения опасен.
Предположим, агент находит запись: «Материал утверждён». Но кто его утвердил? Когда? Какую версию? Разрешена ли запись в Notion? Означает ли утверждение текста разрешение на публикацию?
Чтобы память можно было использовать в реальной работе, одной записи недостаточно. Ей нужен паспорт.
Паспорт памяти — авторский термин серии. Это набор свойств, сопровождающих значимую запись:
- идентификатор объекта;
- тип информации;
- источник;
- автор или агент;
- время создания и последней проверки;
- статус: гипотеза, наблюдение, подтверждённый факт или решение;
- срок актуальности;
- уровень доступа;
- ссылка на исходный артефакт;
- связь с предыдущей и заменившей версиями;
- владелец, который может подтвердить или исправить запись.
Этот подход согласуется с семейством стандартов W3C PROV, опубликованным в 2013 году и остающимся действующей базовой моделью описания происхождения данных. PROV связывает информацию с создавшими её сущностями, действиями и участниками, помогая восстанавливать авторство, преобразования и основания результата. W3C PROV-O
Паспорт не делает утверждение истинным автоматически. Он позволяет понять, почему оно появилось и как его проверить.
Контракт памяти
Даже качественно описанная память становится источником ошибок, если любой агент способен записывать в неё любые выводы.
Агент прочитал три комментария и решил, что обнаружил рыночный тренд. Другой агент нашёл эту запись и использовал её как подтверждённый факт. Третий построил на её основе рекомендацию клиенту. Первоначальная гипотеза постепенно превратилась в «корпоративное знание», хотя человек никогда её не принимал.
Для предотвращения такой эскалации нужен контракт памяти.
Контракт памяти определяет, что агент обязан сохранять, что остаётся временным, что записывается как наблюдение, кто подтверждает решение, какую память агент может читать, какие поля изменять, сколько живёт запись и как разрешается конфликт версий.
Исследовательская работа Collaborative Memory предлагает разделение приватной и общей памяти и моделирует изменяющиеся права через связи между пользователями, агентами и ресурсами. Статуса отраслевого стандарта у этой архитектуры нет. При этом она показывает важную границу: совместной памяти требуются и хороший поиск, и управление доступом. Collaborative Memory
Право найти информацию, право считать её истинной и право действовать на её основании — три разных полномочия.
Передача между агентами
Память становится рабочей, когда один участник способен передать результат другому без пересказа всей истории.
В передачу должны входить идентификаторы задачи и связанных объектов, цель, входные материалы, созданный результат, принятые решения, открытые допущения, ограничения, статус проверки, необходимые права, следующий шаг, владелец и ссылки на доказательства.
Это можно назвать конвертом передачи.
Схожую функцию выполняют задачи, контексты и артефакты в протоколе A2A. Протокол описывает взаимодействие агентов и передачу результатов, но сам по себе не создаёт организационную память или корпоративный источник истины. A2A Protocol: Core Concepts
Практический пример Антона Быстрова
Идея этой статьи получила дополнительное развитие после обсуждения материала «Организация как граф задач».
Антон Быстров предложил посмотреть на созданный им проект redis-agent-bus. В нём реализован коммуникационный слой для нескольких LLM-агентов.
Система использует два канала. Redis хранит оперативные данные и сообщения с TTL, heartbeat, стабильным конвертом, дедупликацией по msg_id и указанием происхождения кэша. Общая папка хранит долговечные Markdown-документы: каждый агент записывает собственное мнение, чужие файлы не редактируются, а отдельный агент собирает сводку.
Это хороший пример того, почему общей памяти недостаточно одной технологии. Redis подходит для быстрого изменяющегося состояния, документы — для долговечных результатов, Git — для истории версий и авторства, агент-сводщик — для контролируемого объединения выводов.
Публичный репозиторий показывает референсную реализацию коммуникационного слоя. Он не является законченной операционной системой компании и не включает полную онтологию, сквозной граф задач, развитую модель прав и механизм утверждения корпоративных фактов.
Антон указывает, что паттерн извлечён из производственного контура QuantumStocks, состоящего из 19 LLM-агентов и 13 заданий. Предметная логика не опубликована, поэтому эти сведения следует воспринимать как описание автора, а не как независимо проверенный результат.
Быстрое состояние должно уметь устаревать. Долговечное знание должно сохранять авторство. Значимое утверждение должно сопровождаться доказательством.
Память может сохранять не только опыт, но и ошибки
В память могут попасть ошибочный вывод, устаревшее решение, неподтверждённая гипотеза, ложная связь, недоверенный контент или данные, которые не должны быть доступны другим агентам.
Anthropic отдельно обращает внимание на риск отравления постоянной памяти: вредоносный или ошибочный контекст способен сохраняться между сессиями и влиять на последующие действия агента. How we contain Claude across products
Поэтому памяти необходимы фильтрация перед записью, разделение факта и инструкции, сроки актуальности, управление версиями, права доступа, журнал изменений, возможность отзыва и проверка источника.
Организация, которая ничего не забывает, не обязательно умнее. Она может просто дольше сохранять собственные ошибки.
Как эта модель уже проявляется в pimenov.ai
В работе над pimenov.ai организационная память распределена между несколькими системами.
Plane хранит карту серии, задачи, статусы и принятые решения. Notion — редакционные версии материалов. Git — изменения программного и инфраструктурного контура. Публичный сайт показывает фактический результат публикации. Диалоги и исследовательские сессии содержат рабочий контекст. Источники подтверждают внешние утверждения.
Мои комментарии, наблюдения, консультации и разговоры с людьми добавляют в систему новые переменные, которых не было в исходном плане.
Сама серия «ИИ-компания» появилась не из заранее составленного редакционного календаря. Она выросла из повторяющихся вопросов людей, консультаций, реакции на первые публикации и слабых сигналов, которые начали складываться в общую проблему.
Агенты могут поддерживать уже описанный процесс. Но человек продолжает изменять его, добавляя новый смысл и неожиданный контекст.
Минимальный эксперимент
Проверять концепцию можно на одном редакционном процессе:
тема → исследование → структура → текст → проверка → утверждение → черновик → публикация → проверка результата.
Исследователь собирает доказательства. Автор превращает доказательства и личный опыт в текст. Проверяющий ищет ошибки и разрывы логики. Издатель записывает утверждённую версию и проверяет результат.
Человек формулирует смысл, добавляет личный контекст, принимает спорные решения, разрешает внешние действия, утверждает результат и меняет сам процесс при появлении нового сигнала.
В общую память попадает не вся работа агентов, а ограниченный набор объектов: тема, задача, источник, утверждение, решение, версия материала, замечание, подтверждение, публикация и наблюдаемый результат.
Каждая значимая запись получает паспорт. Каждая роль — контракт памяти. Каждая передача — конверт.
Линии остановки
- Агент не превращает собственный вывод в подтверждённый факт.
- Утверждение без источника сохраняется только как наблюдение или гипотеза.
- Устаревшая память не заменяет доступный источник истины.
- Клиентский и личный контекст не становится общим автоматически.
- Найденная запись не даёт права совершать внешнее действие.
- Противоречие между версиями останавливает процесс.
- Необратимое решение нельзя принимать только на основании извлечённой памяти.
- Запись должна иметь владельца и способ отзыва.
- Агент не получает больше контекста, чем требуется его роли.
Как проверить один процесс
Возьмите процесс, в котором участвуют два или более агента, и ответьте на десять вопросов:
- Где находится каноническое состояние задачи?
- Как агент понимает, что видит последнюю версию?
- Какие данные существуют только внутри одной сессии?
- Что сохраняется после завершения задачи?
- Где фиксируются принятые решения?
- Можно ли восстановить источник каждого значимого утверждения?
- Какие агенты могут читать и изменять эту информацию?
- Как устаревшая запись выводится из использования?
- Что происходит при конфликте двух версий?
- Как следующий участник получает результат без передачи всей истории?
Если ответ на большинство вопросов звучит как «это находится где-то в переписке», у организации ещё нет общей памяти. Есть только накопленный контекст.
Четыре уровня зрелости
Личная память. Каждый человек или агент хранит собственный контекст. Работа продолжается, пока активен конкретный участник.
Общее состояние. Появляются задачи, документы, статусы и ссылки, доступные нескольким участникам. Правила записи и проверки ещё не определены.
Управляемая память. Записи получают происхождение, статусы, сроки актуальности и права. Решения отделяются от гипотез, а источники истины — от поисковых индексов.
Организационная память. Система сохраняет опыт разных процессов, извлекает из него процедуры, передаёт работу между агентами и людьми и позволяет восстановить основания каждого значимого решения.
Даже на последнем уровне память не становится автономным источником смысла. Решение о том, какой новый сигнал важен и какое правило следует изменить, остаётся отдельной человеческой функцией.
Что такое общая память ИИ-компании
Общая память ИИ-компании — это не место, где лежит вся информация.
Это способность организации сохранять значимые состояния и решения, различать временное и долговечное, связывать записи с источниками и авторами, находить релевантный контекст, ограничивать чтение и запись, замечать противоречия, выводить устаревшее знание из использования и передавать работу без потери смысла.
Компания начинает помнить не тогда, когда сохраняет каждый разговор.
Она начинает помнить, когда умеет объяснить, что произошло, почему текущее состояние считается правильным и кто имеет право изменить его дальше.
Именно такая память соединяет отдельных агентов в организацию.
Источники
- Google Agent Development Kit — Memory
- Google Agent Development Kit — Session
- Google Agent Development Kit — State
- OpenAI Agents SDK — Sessions
- OpenAI Agents SDK — Agent memory
- Anthropic — Effective context engineering for AI agents
- Anthropic — How we built our multi-agent research system
- Anthropic — How we contain Claude across products
- W3C — PROV-O
- A2A Protocol — Core Concepts
- Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
- Collaborative Memory: Multi-User Memory Sharing in LLM Agents with Dynamic Access Control
- Антон Быстров — redis-agent-bus
Следующий шаг
Если вы хотите оценить не только память, а весь агентный контур компании, начните с материала «10 контуров ИИ-компании: как отличить новую операционную модель от набора ИИ-инструментов».
Он поможет проверить результат, процессы, контекст, исполнение, доступы, ответственность, наблюдаемость, устойчивость, экономику и человеческое участие как одну систему.
По теме
Если захотите разобрать один процесс своей компании и определить, какая память нужна людям и агентам, где должен находиться источник истины и какие права нельзя передавать автоматически, можем обсудить это вместе.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov