Ты наверняка уже видел, как компании пытаются «запустить агентов в прод». На демо всё красиво: агент читает документы, лезет в CRM, вспоминает прошлые разговоры и бодро делает вид, что он почти сотрудник месяца.
А потом начинается взрослая жизнь. И ломается не модель. Ломаются данные.
Потому что типичный «агентский» стек в компании сегодня — это зоопарк: отдельно векторное хранилище (для поиска по смыслу), отдельно обычная база (транзакции), отдельно граф (связи), отдельно архивное озеро данных (там лежит всё, что когда-либо накопилось). Между ними — трубопроводы синхронизации. Пока нагрузка маленькая, оно кое-как живёт. Как только становится по-настоящему «в проде» — контекст устаревает, права доступа расползаются, а агент начинает отвечать уверенно… но на позавчерашних данных.
Oracle на этой неделе выкатила свою позицию: если агенты ломаются на уровне данных, значит, чинить надо там же. И предлагает сделать базу данных не просто местом хранения, а «контрольным слоем» для агентского ИИ.
Главная ставка: одна память вместо четырёх
Ключевая штука в анонсе называется Unified Memory Core. Звучит как название энергетика, но смысл довольно практичный: Oracle хочет, чтобы разные типы данных жили и обрабатывались в одном транзакционном движке.
Реляционные таблицы, JSON, графы, векторы, пространственные данные, колоночные форматы — всё это должно работать без отдельного слоя синхронизации.
Важная деталь: база обещает «железную» согласованность (та самая ACID — есть такая скучная аббревиатура, смысл простой: данные не превращаются в кашу, даже когда много запросов одновременно). И эта согласованность распространяется на все типы данных сразу. То есть агент не должен помнить одно, а база в этот момент жить по другому календарю.
Oracle ещё и прямо говорит: данные у клиентов живут не только у Oracle. И это, честно, редкий момент реальности в корпоративных презентациях.
Векторы на Iceberg: чтобы озеро не было болотом
Вторая заметная часть — Vectors on Ice. Если у тебя (или у твоей компании) данные в архивном озере на Apache Iceberg, Oracle предлагает делать векторный индекс «у себя», но так, чтобы он напрямую ссылался на таблицы Iceberg. И отдельно подчёркивает совместимость с таблицами, которыми управляют Databricks и Snowflake.
Фишка в том, что индекс должен обновляться автоматически, когда меняются данные. Цель — одним запросом смешивать «поиск по смыслу» по озеру и нормальные запросы по данным внутри Oracle, без плясок с выгрузками и постоянными пересборками индексов.
Это как перестать носить продукты из холодильника в кладовку, чтобы умный помощник мог найти йогурт. Пусть он уже научится открывать дверь там, где йогурт реально стоит.
Отдельная векторная база — но с выходом «во взрослую»
Третья штука — Autonomous AI Vector Database. Это управляемая векторная база «free-to-start» (то есть можно начать бесплатно), построенная на движке Oracle 26ai.
Позиционирование простое: заходишь с векторов, как делают многие, а потом — если становится тесно — одним кликом переходишь на полноценную Autonomous AI Database.
Тут Oracle явно подмигивает рынку узкоспециализированных векторных баз: мол, отдельное хранилище для поиска по смыслу — нормальный старт, но дальше тебе всё равно понадобится больше типов данных, и вот тогда начинаются переезды и склейка инфраструктуры.
MCP-сервер: агентам — вход без «самописных переходников»
Четвёртая часть — Autonomous AI Database MCP Server. MCP — это, по сути, стандартный способ подключить внешнего ИИ-агента к любому инструменту, не городя кастомный код для каждого случая. Коротко: агент заходит в базу по единому протоколу, без самодельных «переходников».
Самое интересное тут не «подключение», а контроль доступа. Oracle делает акцент: правила на уровне строк и колонок применяются автоматически, даже если агент «просит лишнего». То есть агент может быть болтливым и самоуверенным, но база всё равно будет тем самым занудой-охранником, который смотрит пропуск и не ведётся на «ну мне очень надо».
Где реально болит у компаний
Во всей этой истории есть одна здравая мысль: проблемы агентского ИИ в компаниях чаще упираются не в «какая у вас модель» и не в «какой у вас промпт».
Они упираются в четыре скучные штуки: доступ (кто что может читать), управление (как это администрировать), задержки (как быстро агент получает актуальное) и согласованность (чтобы данные не расходились по разным углам).
Когда агентская система собрана из разрозненных хранилищ, это превращается в настоящий аттракцион: отдельные политики, отдельные логи, отдельные пайплайны, и всё это ради одного «умного помощника», который должен просто нормально отвечать сотруднику поддержки или менеджеру продаж.
Oracle фактически говорит: «Хватит городить память агента снаружи. Давайте память и контроль держать там, где данные живут по-настоящему — в базе».
Так это прорыв или ребрендинг?
Скептики тоже есть: сегодня векторный поиск, интеграции для работы агента с базой знаний и поддержка архивных озёр — уже не экзотика. Это базовая комплектация у многих платформ.
Но Oracle делает ставку не на «у нас тоже есть векторы», а на архитектуру: одна транзакционная основа для всего, без прослойки синхронизации, плюс единые права доступа.
И тут всё упрётся в практику: выдержит ли этот Unified Memory Core реальную нагрузку и реальное разнообразие данных, или окажется красивой идеей, которая хорошо смотрится в презентации и чуть хуже — в пятницу вечером, когда у тебя инцидент.
Пока же сама мысль здравая: агентам не хватает не интеллекта, а дисциплины в данных. А дисциплину обычно наводят не в чате, а там, где хранится «единственная версия правды».
Как в бухгалтерии: можно сколько угодно спорить в курилке, но потом всё равно открываешь базу — и видишь, кто кому и сколько должен. И неожиданно становится тихо.
Занимаюсь внедрением ИИ для бизнеса. Детали — в телеграме