Одно место, где определяется действующий факт

Когда несколько агентов работают с одними и теми же фактами, факты меняются, а агенты узнают об изменениях не одновременно. Срок платежа наглядно показывает эту проблему.

Предположим, в счёте INV-2041 указано, что оплатить его нужно до 22 октября, а в более позднем письме поставщик переносит срок на 29 октября. Один агент читает счёт, другой — письмо, третий готовит платежи на неделю на основе того, что сумел найти. Первый отвечает «22 октября», второй — «29 октября», а третий называет дату, которая встретилась ему первой. В такой схеме ничто не определяет, какая дата действует, поэтому человеку, управляющему агентами, приходится проверять самому.

Именно этот пример со счётом я придумал, но лежащая в его основе схема реальна. Я использую агентов в трёх инструментах, подключённых к одному экземпляру Neotoma. Процесс проверки почты сохраняет входящие письма с указанием источника и превращает сообщения, требующие действия, в задачи; сеансы Claude Code, Codex и Cursor подхватывают одни и те же задачи и планы. Эта система и моя работа над Neotoma как всеобъемлющей системой учёта послужили отправной точкой для статьи.

Воспоминание решает другую задачу

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

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

В начале года я называл Neotoma слоем памяти и слоем истины. Я перестал так говорить, потому что пришёл к выводу: «память» — неверная категория для Neotoma. Она вызывает путаницу, и люди постоянно сравнивали Neotoma с продуктами для памяти. Мне нужно, чтобы агент сохранял точные данные о самых разных вещах в форме, которую можно проверить. Простое название для места, где всё это хранится, — система учёта.

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

Что Neotoma делает сегодня

Я разрабатываю Neotoma — систему учёта для ИИ-агентов. Её исходный код открыт по лицензии MIT; она работает локально, в выбранном пользователем каталоге данных. Ниже описано то, что опубликованный пакет (версия 0.25.0 в npm) делает сегодня.

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

Наблюдения относятся к сущностям. Идентификатор сущности определяется её типом и идентифицирующими полями. В пределах одного экземпляра и при одинаковых правилах идентификации одинаковые идентифицирующие значения детерминированно дают один и тот же ID. Поэтому два агента, сохраняющие один и тот же счёт, записывают данные в одну сущность.

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

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

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

Вернёмся к счёту. Записи обоих агентов попадают в одну сущность. Теперь срок оплаты — 29 октября, и поле указывает на наблюдение из письма. Сумма по-прежнему указывает на первое наблюдение, поскольку она не менялась. Платёжный агент читает 29 октября, а наблюдение о 22 октября остаётся в перечне вместе со своим источником.

Агенты обращаются к Neotoma через сервер MCP, REST API и интерфейс командной строки. Руководство по установке объясняет, как подключить поддерживаемые инструменты и среды. Чтобы совместно использовать записи, направьте каждый инструмент к одному экземпляру и профилю данных или к одной точке входа MCP; разные точки входа могут использовать разные базы данных.

Люди могут просматривать свои записи во входящем в комплект приложении Neotoma.

Принятый подписанный запрос может установить проверенную личность агента. Действующие разрешения с ограниченной областью определяют допустимые действия; одной подписи недостаточно для получения права действия.

Куда это движется

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

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

Ateles развивает это направление с операционной стороны. В проекте адаптеров Ateles адаптеры приносят в Neotoma сведения из таких систем, как почта, календари и хостинги кода, а санкционированные действия передают обратно в эти системы. Neotoma хранит записи; подключённые инструменты выполняют работу.

Полное описание замысла с текущим состоянием каждой части находится в README.

Система учёта, а не просто поиск

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

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

npm install -g neotoma
neotoma init
neotoma setup --tool claude-code

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

Руководство по установке находится по адресу neotoma.io/install. Код и система отслеживания задач размещены на GitHub: github.com/markmhendrickson/neotoma.