Три уровня агентного ИИ: почему у 96% компаний есть агенты, а в проде живёт только каждый девятый

Что произошло

Крупный сдвиг: почти у всех предприятий уже есть агентный ИИ — но почти нигде он не работает в реальном продакшене.

• OutSystems опросила почти 1 900 ИТ‑руководителей по всему миру.
  • 96% организаций уже запустили AI‑агентов хотя бы где‑то.
  • Лишь каждая девятая довела агентов до работы в проде и на масштабе.
• Databricks проанализировала данные 20 000+ организаций, включая 60% Fortune 500.
  • Многоагентные workflows на их платформе выросли на 327% всего за четыре месяца.
• OutSystems зафиксировала ещё один тревожный тренд:
  • 94% компаний боятся «AI‑зарослей» — роста сложности, техдолга и рисков безопасности.
  • Только 12% имеют централизованное управление агентами.

Параллельно инфраструктура дозрела до продакшена:

• Вызов инструментов (tool calling) есть у всех крупных LLM.
• Появились зрелые фреймворки для оркестрации агентов: LangGraph, CrewAI, Microsoft Agent Framework.
• Model Context Protocol (MCP) стандартизирует доступ агентов к внешним данным и API.
• Agent‑to‑Agent Protocol (A2A) от Google, теперь под управлением Linux Foundation, уже поддерживают более 50 крупных вендоров: Salesforce, SAP, ServiceNow, Workday и другие.
• Databricks показывает: компании, которые внедрили инструменты AI‑governance, доводят в прод в 12+ раз больше AI‑проектов, чем те, кто governance игнорирует.

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

Зачем это нужно

Проблема не в технологиях, а в выборе задач и управлении

Большинство корпоративных команд делает одно и то же:

• строит агентов там, где достаточно обычного workflow‑движка или правил;
• выбирает не тот «уровень» реализации:
  • тащит low‑code туда, где нужен кастомный бэкенд;
  • или, наоборот, пишет сложный runtime ради простого FAQ‑бота;
• думает о governance как о чекбоксе для комплаенса «потом», а не как о части архитектуры «сейчас».

Результат: десятки пилотов, красивые демо, впечатлённые комитеты и негласное признание — в прод это не живёт.

Автор статьи много лет строил агентные системы для логистики, ритейла и B2B‑сервисов и видит повторяющийся паттерн: провалы происходят до первой строки кода. На этапе, когда никто не задал базовый вопрос: «А здесь вообще нужен агентный ИИ?»

Три сдвига, которые меняют архитектуру

1. От одного агента к многоагентным системам
   Монолитный «агент‑всё‑в‑одном» (рутинга, поиска, рассуждений и исполнения) уходит. На его место приходят специализированные агенты с чёткими интерфейсами.

   Пример из финансов:

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

2. Стандартизация протоколов

   • MCP отвечает за вертикаль: как агенты ходят в базы, API и инструменты через типизированный манифест и стандартный вызов.
   • A2A — за горизонталь: как агенты находят друг друга, делегируют подзадачи и координируют workflows.

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

3. Governance как главный ускоритель
   Databricks показывает: компании с AI‑governance инструментами запускают в прод в 12+ раз больше AI‑проектов.

   Успешные команды:

   • строят пайплайны оценки качества;
   • ведут аудиторские логи;
   • закладывают human‑in‑the‑loop (HITL) до масштабирования, а не после первого инцидента.

Что меняет для рынка

Три уровня агентного ИИ

Автор предлагает смотреть на агентные системы через три «типа сборки» и чёткую последовательность решений.

Tier 1 — low‑code‑агенты: быстро, но с потолком

Low‑code‑платформы за последние 18 месяцев сильно подросли:

• Microsoft Copilot Studio, Salesforce Agentforce и аналоги:
  • больше коннекторов;
  • лучше генеративная оркестрация;
  • гибче настройка тематических моделей.

Базовый паттерн один:

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

Кому это заходит: бизнес‑команды (аналитики, citizen‑developers, операционный ИТ), которые хотят сами собрать и поддерживать бота без постоянного участия разработчиков.

Но статистика бьёт по розовым очкам:

• Gartner: только 5% пилотов на Copilot Studio дошли до масштабного развёртывания.
• Европейский телеком с мощной ИТ‑командой и полным Microsoft EA потратил 6 месяцев и не запустил ни одного прод‑агента.

Где low‑code упирается в потолок:

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

2. Полные логи по payload
   Платформа пишет транскрипты диалогов и краткие логи коннекторов, но не даёт структурированную запись каждого API‑вызова с параметрами.

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

4. Разбор инцидентов
   Часто нельзя посмотреть confidence‑score LLM или альтернативные варианты ответа. Диагностика ошибок превращается в угадайку.

Ключевая проверка для low‑code:

Ответьте «да» на все пункты:

• use case может полностью принадлежать бизнес‑команде;
• хватает стандартных коннекторов;
• нет SLA по задержке строже 3 секунд;
• нет требований по payload‑уровневому комплаенсу и аудиту каждого поля.

Если всё сошлось — low‑code не компромисс, а правильный выбор. Если хоть один пункт «нет» — идём дальше.

Tier 2 — pro‑code‑агенты: архитектура для серьёзных задач

Продакшн‑паттерн сейчас — многоагентная архитектура:

• специализированные агенты по доменам;
• MCP для доступа к инструментам и данным;
• A2A — для делегирования задач между агентами;
• над всем этим — слой governance и observability.

Пример для комплаенса во финансах:

• Агент 1: понимает запрос и классифицирует интент.
• Агент 2: ищет и подтягивает нужные документы.
• Агент 3: выполняет саму проверку на соответствие требованиям.

Каждый агент:

• решает узкую задачу;
• имеет чёткий контракт ввода/вывода, типизированный через JSON Schema;
• передаёт управление дальше по понятной границе.

Почему монолитные агенты ломаются:

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

Специализация и жёсткое разделение ролей снимают эти проблемы.

Главный принцип: LLM только рассуждает и координирует, а детерминированные функции‑инструменты исполняют.

Пример для комплаенса:

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

Если дать LLM право решать, прошёл ли документ по правилу, вы теряете:

• воспроизводимость;
• прозрачную аудиторскую цепочку;
• детерминированность там, где она критична.

MCP в этой картине — стандартный интерфейс к инструментам:

• MCP‑сервер публикует типизированный манифест;
• любой совместимый агентный runtime может его считать на старте;
• инструменты версионируются и деплоятся отдельно;
• один и тот же инструмент переиспользуется множеством агентов без кастомного клея.

A2A расширяет систему по горизонтали:

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

Над этим слоем обязательно строится observability:

• пайплайны оценки качества;
• распределённые трейсы через все границы агентов и MCP‑инструментов;
• HITL‑гейты там, где риск неприемлем.

Команды, которые добавляют это «после первого инцидента», потом месяцами перестраивают всё вокруг.

Гибрид: где на самом деле заканчиваются успешные проекты

Многоагентная архитектура не отменяет гибридный подход, а делает его логичным:

• low‑code на поверхности общения с пользователем;
• pro‑code / многоагентный бэкенд за сложные задачи и аналитику;
• единый слой governance над обоими.

Кейс из логистики:

Задача — ассистент в Teams для аккаунт‑менеджеров:

• статус отгрузок;
• здоровье аккаунта;
• конкурентный контекст.

Бизнес хотел всё сделать в Copilot Studio. Инженеры — написать кастомный runtime. Оба подхода в чистом виде не подходили.

Что сработало:

• Copilot Studio обрабатывает все частые и простые запросы:
  • трекинг отгрузок;
  • статус аккаунта;
  • открытые кейсы;
  • всё через стандартные Power Platform‑коннекторы, без кастомного кода.
  • это покрывает около 78% всех запросов.
• Сложные запросы, требующие многократного обращения к данным и аналитики:
  • конкурентная позиция по конкретному направлению;
  • риск оттока по портфелю клиентов;
  • анализ продления контракта; отправляются по аутентифицированному HTTP‑действию в pro‑code многоагентный сервис в Azure.

На бэкенде:

• агент‑retrieval тянет историю сделок и рыночную аналитику через MCP‑инструменты;
• агент‑synthesis собирает рекомендацию и считает confidence;
• результат уходит обратно в low‑code‑слой в виде структурированного JSON;
• Copilot Studio рендерит его как Adaptive Card в Teams.

Ключевой момент: HITL‑гейт был заложен до запуска.

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

Граница проста:

• low‑code — для массовых, простых диалогов;
• pro‑code — для глубокой аналитики и сложного рассуждения.

Именно так действуют команды, которые реально выводят агентов в прод.

Что это значит для вас

Четыре «ворот» перед тем, как вообще думать про агентов

Перед выбором платформы прогоните use case через четыре вопроса. Никакие новые протоколы не меняют экономику рассуждений LLM.

Ворота 1 — логика полностью детерминирована?

Если вы можете перечислить все валидные выходы для всех валидных входов и покрыть это юнит‑тестами, LLM не нужен.

• Правила в движке работают за микросекунды.
• Нет стоимости инференса.
• Нет «правдоподобно‑неверных» ответов.

Пример: NeuBird AI запустила production‑агентов для операций, которые уже обработали более миллиона алертов и сэкономили предприятиям $2+ млн инженерных часов.

• Всё, что можно выразить правилами для триажа алертов, реализовано в детерминированном коде.
• LLM решает только те кейсы, где одного паттерн‑матчинга мало.

Чёткая граница между правилами и LLM — основа надёжности.

Ворота 2 — нужна нулевая толерантность к галлюцинациям?

Databricks пишет, что более 80% новых баз данных сейчас создают AI‑агенты. Поверхность для ошибок из‑за галлюцинаций резко выросла.

Если ошибка — это событие комплаенса, LLM выбывает автоматически, независимо от версии модели и качества промпта:

• финансовые расчёты;
• медицинская логика;
• регуляторные решения.

Здесь нужны:

• детерминированный код;
• или классический ML с ограниченным, контролируемым пространством выходов.

Ворота 3 — нужен SLA по задержке < 100 мс?

Инференс стал быстрее, но не настолько:

• платёжные транзакции;
• real‑time fraud‑скоринг;
• управление запасами в реальном времени.

Многоагентная система с MCP‑вызовами инструментов даёт P50 в секундах, а не в миллисекундах.

Эти задачи требуют транзакционной архитектуры, а не LLM‑агентов.

Ворота 4 — нужна регуляторная объяснимость?

A2A помогает агентам договариваться между собой, но не делает рассуждения LLM регуляторно воспроизводимыми.

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

Здесь нужен:

• детерминированный workflow;
• структурированный аудит‑лог на каждом шаге.

Если use case не проходит хоть одни ворота — не тратьте время на агентов.

Пять типичных провалов (один — новый)

Четыре классических ошибки всё ещё повсюду. Пятая появилась на масштабе.

1. Маршрутизация данных через LLM там, где достаточно API‑вызова
   Прямой запрос к API даёт статус аккаунта за < 10 мс.
   Если вы гоняете запрос через LLM‑агента:

   • добавляете сотни миллисекунд;
   • жжёте токены на каждом вызове;
   • парсите текст, хотя данные и так структурированы.

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

2. Бизнес‑правила в промптах
   Правила, зашитые в текст промпта:

   • «плывут» при обновлении модели;
   • дают вероятностный результат;
   • ломаются нестабильно и плохо воспроизводимо.

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

   • юнит‑тесты;
   • версионирование;
   • независимый деплой через MCP.

3. Нет approval‑гейта на CRUD‑операциях
   Создание, изменение и удаление без человеческого одобрения рано или поздно выстрелят на кейсе, который тесты не покрыли.

   Approval нужно проектировать до запуска, а не после инцидента с:

   • финансовой проводкой;
   • клиентской коммуникацией;
   • удалением данных.

4. Монолитный агент «на все случаи»
   Один агент, который «умеет всё», закономерно приходит к:

   • конфликтам тем;
   • переполнению контекста;
   • неуправляемой поддержке.

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

5. Нерегулируемый зоопарк агентов — новая, но уже массовая проблема
   OutSystems: 94% компаний этим обеспокоены, только 12% имеют централизованный ответ.

   Когда команды строят агентов независимо и на разных стэках, без общих стандартов и аудит‑инфраструктуры, они получают новый вид «теневого ИТ», только хуже:

   • эти системы не просто хранят данные, а принимают решения.

   Лекарство одно: относиться к governance как к части архитектуры до деплоя, а не как к формальности после сбоя.

Как принимать решения по уровням

Логика выбора уровня не изменилась:

1. Нужны ли вообще LLM?

   • Нужны понимание естественного языка или генерация?
   • Если нет — строим детерминированную систему и останавливаемся.

2. Подходит ли low‑code?
   Если:

   • бизнес‑команда может владеть решением от и до;
   • хватает стандартных коннекторов;
   • нет SLA по задержке < 3 секунд;
   • нет требований к аудиту каждого поля payload — выбираем low‑code.

3. Нужен ли pro‑code?
   Если требуются:

   • кастомная оркестрация;
   • многоагентная координация;
   • наблюдаемость уровня аудита — идём в pro‑code с MCP и A2A.

4. Нужен ли гибрид?
   Если одновременно нужны:

   • удобный диалоговый интерфейс для пользователей;
   • глубокое рассуждение и аналитика на бэкенде — строим гибрид с единым слоем governance.

Главное изменение последних месяцев — не в протоколах, а в выводах из данных:

• компании с governance‑инструментами доводят до прод в 12+ раз больше AI‑проектов;
• пайплайны оценки, распределённые трейсы, HITL‑гейты и централизованный жизненный цикл агентов — не «оверхед», а основа перехода от экспериментов к продакшену.

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

Что делать дальше

Если у вас есть пилоты, которые не доходят до продакшена

1. Прогоните каждый use case через четыре ворота выше до следующего спринта.
   • Уже первые ворота («логика детерминирована?») отсеют заметную часть.
2. Всё, что проходит все четыре, — реальные кандидаты для инвестиций в прод.
3. Используйте чек‑лист по воротам на каждом архитектурном ревью.

Если вы только запускаете новый проект с агентами

1. Не открывайте ни одну платформу, пока не ответите на вопросы четырёх ворот.
2. Когда стало ясно, что агент нужен и понятен уровень:
   • для low‑code‑кейсов — начинайте с Copilot Studio и его guided setup;
   • для pro‑code‑паттернов с MCP и многоагентной координацией — с Foundry Agent Service или аналогичных сервисов.
3. Стройте governance до масштабирования:
   • пайплайн оценки качества;
   • распределённые трейсы;
   • HITL‑гейты.

Если вы уже вывели агентов в продакшен

1. Проанализируйте, где у вас:
   • детерминированные правила случайно живут в промптах;
   • LLM участвует там, где достаточно API;
   • нет approval‑гейтов на чувствительных CRUD‑операциях.
2. Проверьте, насколько централизовано вы управляете:
   • жизненным циклом агентов;
   • стандартами оценки;
   • аудит‑логами.
3. Поделитесь опытом с коллегами в профессиональных сообществах — сейчас это ценнее маркетинговых кейсов от вендоров.

Что это значит для вас как для пользователя и заказчика ИИ‑систем

Если вы:

• CIO / CDO / Head of AI — у вас есть формальный повод сказать «нет» лишним пилотам и сфокусироваться на задачах, которые проходят четыре ворот.
• руководите продуктами или бизнес‑линиями — вы можете требовать от ИТ не «бот любой ценой», а решение, которое:
  • либо честно реализовано на правилах;
  • либо обоснованно использует агентов там, где без них не обойтись.
• работаете в ИТ‑инфраструктуре или безопасности — у вас появился понятный язык разговора с бизнесом про риски AI‑зарослей и необходимость централизованного governance.
• разрабатываете или интегрируете AI‑сервисы — вы можете точнее выбирать, когда достаточно Copilot Studio, а когда нужен свой многоагентный runtime с MCP и A2A.

Главный вывод: агентный ИИ — не магический слой, который нужно «натянуть на всё». Это ещё один инструмент в архитектурной коробке. Его сила проявляется только там, где вы честно прошли четыре ворот и заранее заложили governance, а не пытаетесь прикрутить его после первого инцидента.

---

Читайте также

• OpenAI обновила правила: как теперь работают данные, приватность и доступ к сервисам
• OpenAI запустила GPT‑Image‑1.5: быстрее, точнее и дешевле генерация картинок
• Claude Cowork в Amazon Bedrock: как раздать ИИ‑ассистента всем сотрудникам и не вытащить данные из AWS