## Выбор базы данных, который плохо устаревает

Компания создает одного агента для поддержки клиентов. Он хранит наблюдения в базе данных Postgres, Mongo, Redis — во всем, что уже работает в команде. Несколько месяцев спустя другая команда создает агент работоспособности учетной записи. Кто-то их соединяет, потому что человеку надоело копировать контекст между инструментами. Это соединение, общая таблица базы данных, случайно становится многоагентным общим состоянием.

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

Агент поддержки обрабатывает разочарованного клиента и сохраняет: «клиент выразил недовольство ценой, рассматривая альтернативы». Агент по оценке здоровья читает это и понижает рейтинг аккаунта. Агент продления считывает пониженный рейтинг, генерирует и отправляет предложение со скидкой. Все в течение нескольких минут. Ни одного человека в курсе.

Первоначальное наблюдение агента поддержки было ошибочным. Клиент был разочарован ошибкой в ​​выставлении счета, а не в ценах. But the LLM-mediated memory extraction compressed the interaction into a misleading summary, and that summary propagated through shared state as ground truth.

Поиск работал на каждом этапе. Ошибка была в написании. Nothing in the system could detect that the initial observation was unfaithful to its source, or trace the causal chain from bad write to bad action.

## Почему одноагентные системы маскируют проблему

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

Сегодня здесь находятся почти все. Боль носит скрытый характер. Никто не может ответить на основные вопросы: что узнал агент, когда и из какого источника это противоречило чему-то, что он хранил на прошлой неделе. Но система явно не ломается. Доверие незаметно подрывается.

## Что меняется при использовании нескольких агентов

Когда агент А записывает наблюдения, которые агент Б читает и на основании которых действует, возникает другая топология сбоя.

**Усиление противоречия.** Два агента хранят противоречивые факты об одном и том же объекте в результате разных взаимодействий. Третий агент прибывает, чтобы принять меры, и видит любой факт, который появляется на слое поиска, без каких-либо оснований для вынесения решения между ними. Без журнала наблюдений, предназначенного только для добавления, с временными метками и указанием источника, невозможно разобраться в противоречии.

**Каскадная автоматическая перезапись.** Агент А обновляет запись. Агент B, работающий на устаревшем чтении, записывает свое собственное обновление, которое неявно отменяет изменение агента A. В изменяемой базе данных это практически невозможно обнаружить. В журнале, предназначенном только для добавления, с наблюдениями, связанными с хешем, это структурно невозможно.

**Разрушение границы доверия.** Общее состояние означает, что каждый агент доверяет записи другого. Но агенты имеют разные возможности, контексты подсказок и профили ошибок. A specialized financial analysis agent and a general-purpose support agent probably shouldn't have equal write authority over the same entity state. В плоской базе данных без ограничений по схеме, кто и что может писать, они это делают.

## Четыре фазы

Отрасль движется по предсказуемой траектории.

### 1. «Просто используйте Postgres» (или [просто используйте файл уценки](/posts/the-markdown-memory-ceiling))

Manus, Claude Code и OpenClaw используют в качестве памяти обычные текстовые файлы. Конвергентная эволюция, а не общий сценарий. When a team reaches for a database, memory gets bolted onto whatever is already there: RAG over Postgres with pgvector, Redis for session state, embeddings in Pinecone. Любой путь подходит для простых случаев использования. Ментальная модель такова: агентам необходимо что-то запоминать, файлы или базы данных хранят данные, проблема решена.

### 2. Оптимизация поиска

Products like Mem0, Zep, and MemPalace accept that agents need a dedicated memory abstraction but frame the problem as retrieval quality. How to get the right context into the prompt at the right time. This solves a problem developers can already feel: bad recall, bloated context windows, irrelevant retrievals. But this phase leaves the write path unaudited. Whatever the LLM extracts is treated as ground truth.

This phase will dominate for the next year or two because retrieval pain is legible. Разработчики замечают, когда агент забывает или извлекает неверную информацию. Write corruption is illegible. Агент действует уверенно в плохом состоянии, и никто не осознает этого, пока не проявятся последующие последствия.

### 3. The trust crisis

This arrives when agents move from low-stakes assistants to high-stakes actors, managing money, making procurement decisions, handling compliance workflows, operating autonomously over days or weeks. The question shifts from "did the agent retrieve the right thing?" to "can I prove what the agent knew, when it knew it, and whether that knowledge was legitimate?"

High-profile failures where agents acted on corrupted memory state will force this shift. Enterprise buyers will demand audit trails. Регуляторы в сфере финансов и здравоохранения потребуют детерминированного происхождения.

### 4. The bifurcation

The industry splits. Путь А: в существующие базы данных добавляются агентные примитивы. Postgres gets extensions for observation logging and entity resolution. Supabase or PlanetScale ships an "agent memory" product layer. This captures many use cases where trust requirements are moderate.

Path B: purpose-built agentic state infrastructure for agents operating across trust boundaries, maintaining long-running autonomous state, or needing cryptographic provenance. The key invariants (append-only, hash-linked, schema-constrained, deterministic entity resolution) are architectural commitments that can't be reliably retrofitted as database extensions.

This is the path where agentic systems reach their full potential. Agents that can trust their own state, trace their own reasoning, and coordinate with other agents without silent corruption are qualitatively more capable than agents running on best-effort memory.

Целостность записи не является функцией безопасности, закрепленной постфактум. Это основа, которая делает возможной автономную работу.

## How multi-agent systems will actually get built

Most won't be designed as multi-agent systems. They'll accrete.

**Hub-and-spoke with a human hub** is the current dominant pattern. One primary agent faces the user and delegates subtasks to specialized agents. Общее состояние — это контекстное окно основного агента. Write-integrity risk is low. But this topology has a hard ceiling: the hub agent bottlenecks and can't maintain context across long-running workflows. This maps to phases 1 and 2: "just use Postgres" or a retrieval layer works fine because one agent controls the state.

**Pipeline agents** come next. Sequential handoffs where each agent processes and enriches a work item. Проводить квалификацию для исследования компании, составления разъяснительной работы и планирования встреч. Write integrity starts mattering here. If the research agent stores incorrect company data, every downstream agent calibrates wrong. This is where teams start sliding from phase 2 into phase 3: retrieval still works, but the trust crisis is building beneath the surface.

**Event-driven agents with shared context** follow. Multiple agents subscribe to events from a shared environment (CRM, codebase, communication channel), maintain their own perspectives, and write observations back to a common store. Нет оркестратора. This is phase 3 in full: concurrent writes from agents with different interpretive frameworks, no coordinator to catch contradictions, and write integrity becomes genuinely dangerous.

**Постоянные автономные агенты с длительным состоянием** являются конечным состоянием. Агенты работают непрерывно, поддерживают развивающиеся модели мира, периодически синхронизируются с другими агентами или общим хранилищем правды. Контекстные окна не могут служить памятью. Этим агентам требуется постоянное хранилище с реальными гарантиями целостности. Это фаза 4: бифуркация. Либо ваша инфраструктура была создана для этого, либо нет.

Ключевое противоречие заключается в том, что многие разработчики выбирают свою СХД в топологиях номер один и два, когда риск совместного состояния незначителен. Они выбирают любую базу данных, которая у них уже есть, и добавляют таблицу воспоминаний. К тому времени, когда они достигают топологий три и четыре, архитектурные обязательства уже заложены. Переход от изменяемого состояния к состоянию, допускающему только добавление, не является заменой библиотеки. Это реструктуризация.

## Поверхность интеграции, которая имеет значение

Выигрышная архитектура, вероятно, заключается не в том, чтобы «заменить вашу базу данных», а в том, чтобы «настроиться между вашими агентами и вашей базой данных».

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

На практике два слоя общаются друг с другом. Агент считывает запись о клиенте из Postgres, запускает анализ и записывает свои наблюдения (оценка работоспособности, риск оттока, рекомендуемые действия) на уровень целостности записи со ссылкой на исходную запись. Второй агент запрашивает уровень целостности на предмет всех наблюдений об этом клиенте, получает согласованный снимок с указанием происхождения и действует на его основе. Если что-то пойдет не так, вы прослеживаете цепочку: какой агент что написал, когда, на основании каких исходных данных. Бизнес-база данных никогда не загрязняется состоянием, генерируемым агентами, а уровень агентов никогда не теряет следа того, откуда поступают его наблюдения.

Различие между «бизнес-данными, написанными человеком» и «состоянием наблюдения, написанным агентом», является наиболее четким объяснением того, почему необходим новый уровень данных. Вы не заменяете их базу данных. Вы добавляете слой для категории данных, которой не существовало до того, как агенты начали писать автономно.

## Что я строю

Это то, что делает [Neotoma](https://github.com/markmhendrickson/neotoma). Наблюдения, доступные только для добавления. Происхождение, связанное с хешем. Запись с ограничениями схемы. Детерминированное разрешение объекта. Каждое наблюдение, записываемое агентом, отслеживается, проверяется и является последовательным с первого дня.

Я запускал через него свой собственный агентный стек. Несколько агентов (сортировка электронной почты, управление задачами, финансы, планирование контента) пишут в один и тот же магазин. Для меня проблема мультиагентного общего состояния не является гипотетической. Это то, с чем я сталкиваюсь каждую неделю, когда извлечение одного агента противоречит извлечению другого или когда устаревшее чтение приводит к последующим действиям в отношении плохого состояния.

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