Domain-Isolated AI Architecture: почему production AI должен строиться не вокруг одного агента, а вокруг изолированных контуров

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

Идея мощная.
Один агент.
Одна память.
Одна точка входа.
Один интеллект, который “держит всё”.

Проблема в том, что именно здесь и начинается архитектурная ошибка.

Для demo, research и consumer-экспериментов такой образ действительно выглядит впечатляюще. Но как только речь заходит о production-среде, enterprise-нагрузке, разделении прав, контроле действий, аудите и долгосрочной эксплуатации, универсальный агент очень быстро превращается не в решение, а в источник системного риска.

Мой основной тезис здесь такой:

будущее production AI — не за одним универсальным агентом с общей памятью и свободным доступом ко всему, а за архитектурой доменно-изолированных и проектно-изолированных AI-контуров, внутри которых интеллект, исполнение, контроль и валидация разделены намеренно.

Именно эту архитектурную логику мы называем Domain-Isolated AI Architecture.

Эта статья также фиксирует авторскую архитектурную позицию Максима Жадобина, основателя THINKING•OS AI Laboratory и Lead AI Architect Tao Platform: production AI должен строиться не как один универсальный агент, а как система доменно-изолированных и проектно-изолированных AI-контуров.

Часть 1. Проблема: почему универсальный агент проваливается архитектурно

1. Одна память почти неизбежно превращается в свалку контекстов

Главная слабость универсального агента не в том, что модели “недостаточно умны”.

Проблема глубже: одна сущность не может надежно удерживать в одной памяти:

• личные задачи;
• рабочие процессы;
• архитектурные решения;
• продуктовые договоренности;
• операционные инструкции;
• историю разных проектов;
• разные режимы прав и ответственности.

Даже если система декларирует “memory switching”, это не решает проблему полностью. Кто гарантирует линейность памяти для каждого домена? Кто гарантирует, что старые ассоциации, случайные хвосты контекста и нерелевантные связи не протекут между рабочими контурами?

В реальности это почти всегда ведет к одному и тому же:

• память загрязняется;
• границы доменов размываются;
• агент начинает переносить не тот контекст;
• цена ошибки растет вместе с шириной его “универсальности”.

2. Один исполнительный слой делает поверхность риска слишком широкой

Универсальный агент обычно продается не только как “умная память”, но и как исполнитель:

• он ходит в browser;
• запускает shell;
• дергает API;
• работает с файлами;
• общается с сервисами;
• триггерится сам;
• действует асинхронно.

На слайде это выглядит как сила. В production это выглядит как слишком широкая execution surface.

Чем шире свобода действий одной сущности, тем труднее:

• ограничивать права;
• отделять безопасные операции от опасных;
• предсказывать последствия;
• проводить аудит;
• локализовать сбои;
• строить внятные policy boundaries.

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

3. Один агент плохо масштабируется по доменам, ролям и режимам контроля

В серьезной системе почти никогда не существует одного режима работы.

Есть:

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

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

Архитектурно зрелее не усложнять одного агента до бесконечности, а дробить систему по контурам ответственности.

4. Автономность без изоляции быстро становится источником хаоса

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

Вопрос не в том, нужна ли агентность.
Вопрос в том, внутри каких границ она допустима.

Низкорисковая агентность может быть очень полезной:

• сбор информации;
• маршрутизация;
• анализ;
• подготовка черновиков;
• наблюдение за состоянием систем;
• диспетчеризация.

Но как только агент начинает работать в контуре, где ошибка дорого стоит, становится нужен другой режим:

• четкие права;
• строгие контракты операций;
• проверка входа и выхода;
• audit trail;
• dry-run;
• policy checks;
• отдельный контроль исполнения.

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

5. Почему LLM не станут “достаточно надежными” для роли прямого критического исполнителя

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

Проблема не в том, что сегодняшние LLM пока недостаточно хороши. Проблема в том, что LLM по своей природе — вероятностные системы.

Это не временный дефект технологии, а фундамент:

• они работают с распределениями вероятностей;
• они аппроксимируют паттерны из обучающих данных;
• они генерируют, а не вычисляют;
• у них нет инженерно гарантируемого механизма “истинного понимания”.

Да, качество можно повышать:

• снижать hallucinations;
• улучшать reasoning;
• делать лучше routing;
• усиливать внешние проверки;
• повышать качество контекста.

Но вероятностную систему нельзя превратить в детерминированную просто за счет того, что она стала лучше.

Это не баг. Это определение класса системы.

Даже если модель дает правильный результат в 99.9% случаев, архитектурная картина не меняется.

В production это означает следующее:

• 0.1% ошибки на миллионе операций — это уже тысяча сбоев;
• невозможно заранее предсказать, где именно случится следующий сбой;
• невозможно формально доказать корректность следующего вывода модели;
• невозможно дать гарантию уровня “эта следующая операция будет корректной” только на основании самого LLM-вывода.

Именно поэтому LLM принципиально плохо подходит для роли прямого исполнителя критических операций.

Не потому, что он “пока недостаточно умен”.
А потому, что это не тот класс системы, которому можно делегировать критическое исполнение без внешнего детерминированного контура.

Часть 2. Модель: как устроена система доменных ассистентов, агентов и субагентов

Если универсальный агент — плохой базовый шаблон, то что выглядит сильнее?

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

Слой 1. Доменные и проектные AI-ассистенты

На верхнем уровне находятся не “один агент на всё”, а отдельные интеллектуальные контуры:

• ассистент для личного контура;
• ассистент для рабочей зоны;
• ассистент для конкретного проекта;
• агент для конкретного продукта;
• агент для конкретной операционной роли.

Каждый такой контур должен иметь:

Это делает систему не “менее умной”, а структурно устойчивой.

Слой 2. AI-агенты как оркестраторы, а не как всевластные исполнители

Внутри такого контура ассистент или агент может:

• понимать задачу;
• удерживать локальный контекст;
• формировать план;
• выбирать маршрут;
• решать, какой нижний исполнительный контур подключить.

Но важна принципиальная граница:

верхний интеллектуальный слой должен быть в первую очередь оркестратором, а не свободным исполнителем опасных действий.

Это означает, что интеллект и исполнение больше не слиты в одной точке.

Слой 3. Детерминированные task-oriented субагенты

Ниже находятся узкие детерминированные субагенты, каждый из которых решает не “всё подряд”, а конкретный тип задач:

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

Почему это сильнее:

• роль уже;
• контракт понятнее;
• поведение повторяемее;
• тестирование проще;
• аудит дешевле;
• сбой локализуется быстрее.

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

Слой 4. Tools, API и MCP как нижняя исполнительная инфраструктура

У субагентов уже может быть реальный доступ к инструментам:

• tools;
• API;
• MCP;
• внешним сервисам;
• файловым операциям;
• интеграционным адаптерам.

Но важно понимать: tools, API и MCP — это не “сердце агентности”, а нижняя исполнительная инфраструктура.

Именно здесь часто возникает путаница в agent hype. Кажется, что чем больше свободных интеграций мы дали агенту, тем система мощнее. На практике мощнее становится не та система, у которой больше свободы, а та, у которой лучше описаны и ограничены действия.

Слой 5. Отдельный control layer

Между интеллектом и внешним действием должен существовать отдельный сервисный слой контроля.

Его задача:

• разрешать только допустимые операции;
• проверять права;
• применять policy;
• поддерживать dry-run;
• ограничивать опасные действия;
• логировать выполнение;
• формировать прозрачный trace.

Этот слой нужен по одной простой причине: LLM не должен иметь прямой доступ к опасным действиям.

Именно после этой границы разговор об агентности становится инженерным, а не магическим.

Слой 6. Отдельный validation layer

Рядом с control layer должен существовать отдельный validation layer.

Он отвечает за:

• валидацию входа;
• проверку схем;
• проверку контракта действия;
• валидацию формата результата;
• отсечение невалидных или опасных выходов;
• fail-fast реакцию на нарушение контракта.

Это важно потому, что в production-системе валидация не должна быть просто “намерением агента работать аккуратно”. Она должна быть выделенной инженерной сущностью.

Как выглядит полный контур

Если собрать модель целиком, она выглядит так:

1. доменный или проектный AI-ассистент принимает задачу;
2. он удерживает локальный контекст и строит маршрут;
3. он вызывает нужную цепочку task-oriented субагентов;
4. субагенты работают через tools / API / MCP;
5. все действия проходят через отдельный control layer;
6. вход и выход проходят через отдельный validation layer;
7. результат возвращается в локальный доменный контур, а не в “общую память на всё”.

Это и есть архитектура, в которой агентность становится управляемой.

Часть 3. Практический вывод: почему такой подход ближе к production

1. Его проще аудировать

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

Можно отдельно проверить:

• память конкретного контура;
• права конкретного слоя;
• разрешенные операции;
• trace конкретного действия;
• результат конкретного субагента.

Универсальный агент, наоборот, делает аудит дорогим и размытым.

2. Его проще ограничивать по правам

В production выиграет не та система, которая “умеет всё”, а та, которую легче безопасно ограничивать.

Domain-Isolated AI Architecture позволяет:

• разносить права по доменам;
• отделять безопасные действия от опасных;
• разделять reversible и irreversible операции;
• не переносить привилегии между контурами;
• применять разные policy-режимы к разным слоям.

3. Его проще масштабировать

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

Изолированные AI-контуры масштабируются лучше:

• можно добавлять новые домены;
• можно добавлять новые проекты;
• можно добавлять новые субагенты;
• можно усиливать отдельные execution adapters;
• можно обновлять control и validation слои независимо.

То есть рост системы перестает означать рост хаоса.

4. Его проще обслуживать и локализовать при сбоях

В реальной эксплуатации важна не только “умность” системы, но и способность чинить ее без разрушения всего остального.

Если проблема локализована в:

• одном домене;
• одном проекте;
• одном субагенте;
• одном policy-контуре;
• одном validation rule,

то система остается управляемой.

Это один из самых практичных аргументов в пользу такой архитектуры.

5. Именно эта модель ближе к enterprise-среде

Enterprise не живет в логике “давайте дадим модели больше свободы и посмотрим, что получится”.

Enterprise требует:

• разграничения прав;
• воспроизводимости;
• аудита;
• контролируемого риска;
• формализованных контрактов;
• операционной наблюдаемости.

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

Почему это важно для Tao

Для нас это не абстрактная философия.

По сути Tao Platform уже строится именно в этом направлении:

• не как один универсальный агент;
• не как одна память на всё;
• не как свободный исполнитель без границ;
• а как система AI-контуров, где память, роли, права и действия разделены;
• где нижний исполнительный слой строится через tools, API и MCP;
• где контроль и валидация не прячутся внутри “магии агента”, а оформляются как отдельные инженерные сервисы.

За этой логикой стоит не абстрактная теоретизация, а практическая работа Максима Жадобина — основателя THINKING•OS AI Laboratory и Lead AI Architect, который пришел в AI-инженерию из операционного бизнеса, системного управления и построения цифровых продуктов.

Сама THINKING•OS с 2020 года последовательно движется не в сторону “демо-магии”, а в сторону AI-инфраструктуры: наблюдаемости действий LLM, контроля API-взаимодействий, алгоритмической валидации результатов и воспроизводимых контуров исполнения. Именно поэтому Domain-Isolated AI Architecture здесь возникает не как постфактум-объяснение, а как формализация того, что команда уже строит на практике.

Именно поэтому здесь, на мой взгляд, речь идет уже не просто об идее для статьи.

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

Не школы “как сделать еще одного модного агента”.
А школы, которая говорит:

• универсальный агент — плохой production-шаблон;
• память должна быть доменной и проектной;
• интеллект и исполнение нельзя безгранично сливать;
• task-oriented субагенты сильнее свободного универсального исполнителя;
• control plane и validation plane должны быть выделены отдельно;
• production AI должен строиться как архитектура контролируемых изолированных контуров.

Итог

Если формулировать совсем коротко, то тезис такой:

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

Именно такая архитектура делает агентность:

• полезной;
• проверяемой;
• масштабируемой;
• безопаснее управляемой;
• пригодной для реальной эксплуатации.

То есть не “один магический агент на всё”, а Domain-Isolated AI Architecture.