AI‑оркестрация задач: как несколько AI‑агентов управляют одним проектом без хаоса

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

Рынок уже прошёл точку «одного чат-бота». Согласно обзору BotHub на Habr, запросы на мультиагентные системы выросли на 1445% с первого квартала 2024 по второй квартал 2025 года. По данным исследования «Сбераналитики», 39% российских организаций уже используют AI-агентов для бизнес-задач, а ещё 23% находятся на стадии масштабирования. Подключить ИИ — с этим справляются. Вопрос в том, что происходит дальше, когда агентов становится больше одного.

Дальше — архитектура их взаимодействия: как распределить роли, где провести границы ответственности и как не превратить три полезных инструмента в источник рассинхронизации.

Что такое AI‑оркестрация и почему одного агента уже недостаточно

AI-оркестрация — это формализованный метод координации нескольких моделей и агентов, объединённых в единую систему с явными правилами взаимодействия. Whitepaper Zennolab описывает три стадии: декомпозиция задачи на этапы, координация ролей и обмена данными, мониторинг и масштабирование. Принципиальное отличие от ситуации, когда вы просто открываете несколько вкладок с разными AI-сервисами и копируете результаты вручную.

Разница между «одним универсальным агентом» и «системой специализированных агентов с оркестратором» — примерно та же, что между универсальным сотрудником и командой с чёткими ролями. Универсал кажется удобным, пока задач мало. Когда проект разрастается, он становится узким горлышком: переключение между контекстами увеличивает количество ошибок, а перегруженный контекст снижает качество каждого отдельного ответа.

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

Ключевой принцип любого работающего фреймворка оркестрации: сначала определяется целевой артефакт (отчёт, протокол, бэклог задач), потом — роли агентов. Не наоборот. Если начать с выбора агентов, а потом думать, что они должны производить, получается именно тот разнобой, с которого начинается большинство провалов. Фреймворк SaleAI формализует эту последовательность: артефакт, роли, формат обмена, метрики.

Для менеджеров проектов, руководителей отделов и всех, кто управляет сложными процессами с несколькими потоками работ, оркестрация уже является частью операционной реальности — 67% разработчиков регулярно используют AI-ассистентов и агентов, по данным обзора трендов на Habr, а мультиагентные платформы масштабируются из пилотов в продакшн.

Роли AI‑агентов, которые закрывают реальные операционные разрывы

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

Агент-аналитик: час ручного сбора статусов — это потеря, а не аналитика

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

Роль агента-аналитика — мониторинг прогресса, выявление рисков, формирование отчётов. Он работает с данными из трекера задач, загруженными файлами (xlsx, pdf, выгрузки из CRM) и формирует сводки в читаемом формате. Конкретный сценарий: агент еженедельно сканирует статусы задач и автоматически сигнализирует о карточках без движения более трёх дней — без запроса со стороны менеджера.

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

Агент-секретарь: скрытый налог в 2,5 часа еженедельно

После каждой встречи кто-то должен сесть и вручную перенести договорённости в задачи. Этот «кто-то» — чаще всего самый занятой человек в команде. При пяти встречах в неделю потери составляют 2,5 часа чистого времени. Если средняя ставка PM — 2500 руб./час, это 325 000 руб. в год на одного менеджера, потраченных на работу, которую агент выполняет за минуты.

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

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

Крупные задачи зависают в статусе «в работе» неделями — не потому что команда ленится, а потому что никто не разобрал их на конкретные шаги с понятными исполнителями. Подробнее о методологии дробления целей — в материале о декомпозиции задач.

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

Агент-маршрутизатор: назначение без актуальных данных — рулетка

Агент назначает исполнителей на основе данных о текущей загрузке и компетенциях, зафиксированных в системе. Что происходит, если карта навыков не актуальна? Допустим, агент назначил задачу по React разработчику с тегом «frontend», который три месяца назад перешёл в DevOps — задача зависла на двое суток, пока менеджер не заметил ошибку вручную. Поддерживать карту навыков команды в актуальном состоянии — управленческая задача, которую агент не решит за вас. Регулярно сверять, что умеет каждый член команды, и отражать это в системе нужно до того, как агент начнёт маршрутизировать задачи.

В Shtab AI доступны специализированные агенты с конкретными ролями: PM, Аналитик, Исследователь, Разработчик, OKR-эксперт, HR. Каждый действует в рамках своей экспертизы, что делает ответы точнее, чем у универсального ассистента, которому задают вопросы обо всём подряд. Подробнее о том, как эти роли взаимодействуют в рамках одного проекта, — в материале о трёх типах AI-ассистентов в управлении проектами.

Матрица RACI для людей и ботов: кто отвечает, кто проверяет

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

Ключевое правило гибридной команды: агент может быть R (Responsible — исполнитель) или I (Informed — получает информацию), но A (Accountable — несёт ответственность за результат) остаётся за человеком. Агент не понимает политического контекста, неформальных договорённостей и последствий ошибки для клиентских отношений. Ответственность предполагает способность нести последствия решения — юридические, репутационные, финансовые. Агент этой способностью не обладает. В низкорисковых автономных процессах с чёткими правилами эскалации (например, автоматическая категоризация входящих обращений) граница может сдвигаться — это осознанное управленческое решение, а не настройка по умолчанию.

Почему «Приоритизация бэклога» — A/R для PM, а не для команды? Потому что приоритизация требует знания бизнес-контекста, стратегических целей и ограничений бюджета, которые команда видит фрагментарно. Агент-аналитик здесь получает информацию (I) для контекста будущих отчётов, агент-ассистент консультирует (C) по загрузке, но решение принимает PM. Команда консультирует по трудоёмкости и зависимостям.

Эта таблица отвечает на вопрос, который возникает при любом сбое: кто принял это решение и кто несёт за него ответственность? Если ответ «агент сам решил» — матрица не настроена.

В документации Shtab AI есть прямое указание на этот принцип: «Подтверждение действий — проверяйте каждое действие агента вручную или разрешите работать автономно. Выбор за вами». Для менеджера это означает конкретное решение: на каком этапе процесса агент работает автономно, а на каком останавливается и ждёт подтверждения.

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

Где несколько агентов выигрывают, а где достаточно одного

«Узкий агент с точностью 90% в своей области эффективнее одного гипер-агента с точностью 65% на всех задачах» — этот тезис из дискуссий на Habr звучит убедительно, но требует уточнения. Мультиагентная система не лучше одного агента по умолчанию. Она лучше в конкретных условиях.

Несколько агентов оправданы, когда процесс порождает несколько параллельных артефактов, которые требуют разных типов обработки и независимой валидации. Если процесс линейный — один артефакт на выходе, один поток данных на входе — монолитный агент справится быстрее и дешевле.

Два критерия для принятия решения. Первый: сколько параллельных артефактов производит процесс одновременно? Если один — один агент. Если три и более, причём параллельно, — нужна оркестрация. Второй: нужна ли перекрёстная валидация? Если результат одного агента должен проверяться с другой стороны — второй агент с независимым контекстом снижает вероятность ошибки. Разнородность данных на входе (структурированные таблицы, голосовые заметки, PDF-документы) усиливает аргумент в пользу специализации, но сама по себе не является достаточным основанием.

Типичный паттерн провала: компания подключает пять агентов к линейному процессу согласования документа. Каждый агент вносит правки в свою копию, без единого источника данных и без чётких правил передачи версий. Итог — конфликтующие правки, три версии «финального» документа и увеличение времени согласования на 30% по сравнению с ручным процессом. Ошибка — в решении, принятом до анализа процесса: количество агентов определили раньше, чем поняли структуру потока.

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

Кейс: как мультиагентная оркестрация сократила время обработки с 42 до 6 минут

Согласно кейсу, опубликованному на Habr, российская ритейл-компания (сегмент e-commerce, команда поддержки из 40+ операторов, внедрение в 2024 году) столкнулась с типичной операционной проблемой: обработка каждого возврата требовала 42 минуты ручной работы. Процесс включал три параллельных потока — проверку статуса заказа, валидацию причины возврата и формирование решения по компенсации. Именно параллельность сделала этот кейс подходящим для мультиагентной архитектуры.

После внедрения узкоспециализированных агентов время обработки одного кейса сократилось до 6 минут, нагрузка на операторов снизилась на 80%. Каждый агент отвечал за один поток: первый проверял статус в системе учёта, второй валидировал причину по базе правил, третий формировал решение на основе результатов первых двух.

Что сделало оркестрацию рабочей — не сами модели, а архитектура вокруг них. Каждый агент имел строго определённый вход и выход, без возможности «залезть» в зону соседнего. Агенты передавали друг другу структурированные объекты, а не свободный текст — это исключало ошибки интерпретации. Оператор подключался только при срабатывании триггера эскалации (нестандартная причина возврата, сумма выше порога), в остальных случаях цепочка работала автономно.

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

Схожий эффект зафиксирован в кейсе Promega: использование ChatGPT Enterprise для оркестрации задач по созданию черновиков email-кампаний, переводу текстов и генерации кода для анализа данных дало экономию 135 часов за полгода.

Как настроить границы ответственности и точки контроля

Первый шаг — определить целевые артефакты процесса до того, как думать об агентах. Что должно появиться на выходе? Отчёт о рисках, протокол встречи, декомпозированный бэклог — это конкретные документы, а не абстрактные «результаты». Если вы не можете назвать артефакт, вы не готовы подключать агентов.

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

Что происходит, когда артефакт составной — например, отчёт включает и аналитику рисков, и список задач по итогам? В этом случае агенты работают последовательно: аналитик формирует раздел с рисками, ассистент на его основе генерирует задачи, итоговый документ собирает оркестратор или менеджер. Каждый агент отвечает за свой фрагмент, а не за весь артефакт целиком.

Третий шаг — описать формат обмена данными между агентами. Что агент-секретарь передаёт агенту-ассистенту? Не «итоги встречи», а структурированный список решений с полями: формулировка, ответственный, срок. Агент-ассистент на основе этого создаёт задачи с заполненными атрибутами. Чем точнее описан формат передачи, тем меньше ошибок интерпретации.

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

Пятый шаг — зафиксировать правила версионирования. Если агент обновляет артефакт, предыдущая версия должна сохраняться. Без этого невозможно отследить, когда и почему изменился приоритет задачи или формулировка решения.

В Shtab AI режим планирования реализует именно эту логику: агент сначала составляет план, задаёт уточняющие вопросы и только потом выполняет. Для каждого агента можно включить подтверждение действий — это встроенный чекпоинт, который не нужно настраивать отдельно.

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

Ошибки, которые превращают оркестрацию в хаос

Большинство провалов мультиагентных систем — управленческие. Модели работают корректно. Архитектура вокруг них — нет.

Нет единого источника данных. Агент-аналитик работает с выгрузкой из трекера задач двухнедельной давности. Агент-ассистент создаёт задачи на основе актуального бэклога. Агент-секретарь фиксирует договорённости встречи, которая изменила приоритеты. Три агента — три разные версии реальности проекта. Результат: конфликтующие рекомендации, дублирующиеся задачи, потерянный контекст. Решение — Single Source of Truth в таск-менеджере, к которому подключены все агенты. Когда бизнес-подразделение и IT-отдел работают с разными данными, задачи «перебрасываются» между ними без продвижения. Единый источник данных устраняет этот «футбол»: все агенты и все люди видят одну и ту же картину проекта.

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

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

Отсутствие метрик качества работы агентов. Без замера точности рекомендаций, количества ложных эскалаций и времени обработки невозможно понять, помогает ли агент или создаёт дополнительную нагрузку. Еженедельный аудит выходных артефактов агента — минимальная гигиена.

Связанная тема — как выстроить приоритизацию задач так, чтобы агент понимал, что срочно, а что нет: об этом подробно в материале о приоритизации задач.

Что дальше: оркестрация как управленческая компетенция

Менеджеру проекта не нужно разбираться в архитектуре нейронных сетей. Достаточно уметь отвечать на два управленческих вопроса: какие процессы в команде параллельны и многоартефактны, и при каких условиях агент останавливается и передаёт решение человеку. Из ответов на них вытекает конкретная архитектура.

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

Конкретный план для старта. Сначала — аудит процессов: выгрузите все повторяющиеся задачи команды из трекера и отметьте те, которые производят несколько параллельных артефактов. Если таких задач меньше трёх — возможно, вам пока достаточно одного хорошо настроенного агента. Затем — RACI для гибридной команды: пропишите, какие роли в ваших процессах может взять агент (R или I), и где A остаётся за человеком. Наконец — пилот на одном процессе: запустите агентов на одном конкретном потоке работ и замерьте время и количество ошибок до и после. Минимальный цикл для статистически значимой выборки — один полный спринт при условии не менее 20 обработанных кейсов. Если время обработки снизилось, а количество эскалаций к человеку не выросло — архитектура работает.

Кейс ритейл-компании из этой статьи показал сокращение с 42 до 6 минут. Ваш первый пилот, скорее всего, даст скромнее — 20–30% экономии времени на рутинных операциях. Этого достаточно, чтобы обосновать масштабирование на следующий процесс.

Если ваши процессы итеративные и построены на спринтах, специфика оркестрации в них отличается — там разобрана логика координации агентов внутри коротких циклов: как AI меняет Agile-процессы.

FAQ

Что такое оркестрация ИИ-агентов?

Управление и координация нескольких специализированных AI-моделей, объединённых в единую систему с формализованным протоколом обмена данными. Отличие от «просто нескольких ботов» — наличие явных правил: какой агент какой артефакт производит, в каком формате передаёт данные следующему, и при каких условиях останавливается для проверки человеком.

Сколько AI-агентов нужно для управления проектом?

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

Может ли AI-агент быть ответственным (Accountable) в матрице RACI?

В подавляющем большинстве бизнес-процессов — нет. Агент может быть Responsible (исполнитель конкретного артефакта) или Informed (получает данные для контекста). Финальная ответственность за результат остаётся за менеджером, потому что ответственность предполагает способность нести последствия — юридические, репутационные, финансовые.

Как избежать конфликтов между несколькими AI-агентами в одном проекте?

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