Как дать ИИ-агенту память всей компании

Большинство компаний начинают работу с ИИ одинаково: у каждого сотрудника появляется свой чат, свой промпт и своя папка с документами. Первые недели это даёт скорость. Затем возникает новый вид организационного долга: один агент знает актуальную цену, второй — старую; третий помнит договорённость с клиентом, но команда об этом не знает; четвёртый снова задаёт вопрос, который уже решили вчера.

Проблема не в том, что модели плохо помнят. Проблема в архитектуре. Если каждый агент живёт в отдельном контексте, компания получает не цифровую команду, а набор изолированных стажёров.

Рабочая система строится вокруг общей памяти: единого слоя фактов, решений, процедур и событий, к которому агенты обращаются по правилам. Такой слой не заменяет CRM, документы или таск-трекер. Он связывает их и даёт агентам актуальный контекст для конкретной задачи.

У памяти компании есть как минимум четыре разных типа данных. Их нельзя складывать в одну бесформенную ленту.

Факты — продукты, условия, роли, клиенты, ограничения, актуальные ссылки. Это то, что должно быть истинно сейчас.

Решения — что команда выбрала, кто утвердил, когда решение вступило в силу и что оно заменило.

Процедуры — повторяемые способы работы: как выпускать статью, проверять лид, выдавать доступ, проводить релиз.

События — сообщения, оплаты, звонки, ошибки, изменения статусов. События помогают восстановить историю, но не всегда являются актуальной истиной.

Если эти типы смешать, агент начинает принимать старое обсуждение за действующее решение, обещание — за выполненный факт, а случайный комментарий — за процедуру.

Полезная единица памяти должна быть атомарной и проверяемой. Не «обсуждали новую цену», а: «С 26 августа базовый воркшоп продаётся по условиям из продуктового SSOT; прежнее публичное предложение снято».

Для каждого факта нужны поля: содержание, источник, время действия, область доступа, уровень доверия и связь с предыдущей версией. Тогда агент может ответить не только что он знает, но и почему считает это актуальным.

Версионирование критично. Исправленный факт не стоит просто перезаписывать: новая запись должна явно отменять или заменять старую. Это позволяет восстановить историю решения и не использовать устаревший контекст.

Архитектура общей памяти не обязана начинаться с большой платформы. Минимальный рабочий контур выглядит так:

Источники истины: CRM, продуктовый SSOT, Kanban, база документов, логи.

Слой нормализации переводит сырые события в факты, решения и наблюдения.

Индекс памяти объединяет полнотекстовый и векторный поиск, временные фильтры и области доступа.

Политики записи и чтения определяют, кто может добавлять, активировать, исправлять, отзывать и видеть записи.

Журнал аудита фиксирует, кто и на основании чего прочитал или изменил память.

В нашей практике для совместной работы людей и агентов можно использовать связку: реляционная база для канонических записей, векторный индекс для смыслового поиска, Git для процедур и конфигурации, Kanban для текущего исполнения. Например, Teable подходит как визуальный интерфейс к рабочим таблицам, а Git — для версионируемых процедур. Это не означает, что один инструмент становится всей памятью.

Общая память без границ быстро превращается в риск. Агенту по контенту не нужны платёжные данные клиентов. Агенту поддержки не нужен полный журнал личных переписок команды. А внешнему подрядчику не нужны внутренние финансовые решения.

Поэтому область доступа задаётся для каждой записи и каждого агента. Доступ выдаётся только по роли и задаче. Секреты и лишние персональные данные не сохраняются. Чтение, запись и активация фактов разделяются. Деньги, массовые отправки, доступы и production должны требовать отдельного подтверждения. В реализации все изменения должны попадать в журнал аудита, а ошибочную запись должно быть возможно отозвать.

Это превращает память из «большого общего чата» в управляемую инфраструктуру.

Качество памяти определяется не объёмом, а качеством поиска. Перед ответом агент должен собрать релевантный контекст, а не выгрузить всё подряд.

Практический retrieval-пайплайн включает: фильтр по области доступа, поиск по точным словам, смысловой поиск, приоритет свежих и активных записей, расширение через связанные сущности и финальную проверку источника.

Важно различать recall и доказательство. Найденная запись подсказывает, где искать, но критический факт нужно подтвердить во владеющей системе: цену — в SSOT, статус лида — в CRM, релиз — по live SHA, публикацию — по целевому URL.

Компания с общей памятью может запускать несколько агентов без постоянного пересказа контекста. Один агент фиксирует подтверждённое решение, второй использует его в продажах, третий проверяет исполнение, четвёртый анализирует результат.

Похожий принцип появляется в современных системах совместной работы людей и агентов. Например, Block описывает BUZZ как рабочее пространство, где люди и агенты работают в общих контекстах. Практический вывод для бизнеса прост: агент должен видеть не весь интернет и не всю историю компании, а правильный набор данных, инструментов и ограничений для своей роли.

На воркшопе Codex + Hermes мы собираем личного ИИ-помощника и настраиваем его под реальные рабочие задачи. Общая память компании — следующий уровень: она появляется, когда несколько таких помощников начинают работать по единым фактам и процедурам.

Выберите один процесс с высокой стоимостью потери контекста: продажи, поддержка, контент или релизы.

Назначьте владеющие источники: где хранится продуктовая истина, клиентский статус, задача и технический результат.

Опишите три типа записей: факты, решения, наблюдения.

Добавьте идентификатор источника, время действия и область доступа.

Подключите поиск по точным словам и смыслу.

Введите правило: критические действия всегда перепроверяются в живой системе.

Запустите одного агента на одном процессе и измерьте число повторных уточнений, ошибок и время до результата.

Не начинайте с переноса всех документов. Начните с точки, где команда чаще всего теряет уже известное решение.

Проверить, работает ли память, можно по операционным метрикам: агент реже задаёт вопросы, на которые компания уже ответила; снижается число решений на устаревших данных; сокращается время поиска владельца и следующего действия; исправление факта распространяется на связанные процессы; по важному ответу можно показать источник, если агент возвращает ссылки на использованные карточки, сообщения и документы; доступ к чувствительным данным остаётся ограниченным.

Дополнительно полезно измерять бизнес-эффект: скорость ответа лидам, долю задач без ручного пересказа, конверсию после корректного контекста и число инцидентов из-за старых условий.

Общая память — не архив и не магия. Это управляемый слой между источниками истины и агентами. Он хранит атомарные факты, различает решения и события, учитывает время, ограничивает доступ и заставляет проверять критические данные в живых системах.

Если вы только начинаете, соберите личного помощника под один рабочий процесс. Затем добавляйте общую память там, где несколько людей и агентов должны действовать по одной версии правды.