Мulti-agent orchestration — это уровень координации, который позволяет нескольким ИИ-агентам работать над единой бизнес-целью, обмениваясь контекстом и автоматически передавая задачи друг другу. Без него агент квалификации лидов может пометить потенциального клиента как приоритетного, но агент по работе с клиентами никогда не увидит эту оценку, и сотрудники будут вручную сопровождать каждый этап передачи.

В этом руководстве объясняется, как работает оркестрация мультиагентных систем и как управлять агентами по мере масштабирования. В нем также показано, как команды используют monday agents для координации ИИ в отделах продаж, маркетинга, ИТ и операций, на практическом примере, который вы можете адаптировать под свои рабочие процессы.

Попробовать monday agents

Основные выводы

Оркестрация превращает агентов в команду: Уровень координации, который распределяет работу, управляет передачей задач и проверяет результаты, — это то, что заставляет отдельных агентов работать вместе.
Общий контекст превыше всего: Агенты могут координироваться лишь настолько эффективно, насколько позволяют данные, которые они видят. Подключите их к единому слою данных, охватывающему все отделы, иначе передача задач нарушится.
Знайте, когда оркестрация действительно необходима: Используйте одного агента для узких задач и автоматизацию для фиксированных правил. Выбирайте оркестрацию, когда работа охватывает разные команды и требует принятия решений в точках передачи задач.
Управление делает масштабирование безопасным: Ограниченные разрешения, журналы аудита, точки контроля (approval gates) и четкие правила автоматизации позволяют вашей организации внедрять ИИ в разных отделах, не теряя над ним контроль.
monday agents делают практическое внедрение доступным: Готовые агенты, конструктор агентов без кода и встроенные механизмы утверждения человеком (human-in-the-loop) позволяют командам создать один работающий рабочий процесс и масштабировать его после того, как он начнет работать стабильно.

Что такое multi-agent orchestration?

Multi-agent orchestration — это способ совместной работы нескольких специализированных ИИ-агентов над одной бизнес-целью. Уровень координации распределяет работу, передает контекст между агентами, проверяет результаты и определяет дальнейшие действия. Без оркестрации у вас есть несколько работающих параллельно агентов. С ней — у вас есть команда.

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

Мультиагентная система против multi-agent orchestration против координации

Эти три термина часто используют как синонимы, но они означают разные вещи.

Мультиагентная система: Совокупность существующих агентов. Агент квалификации лидов, картограф зависимостей и рисков, а также генератор отчетов о статусе вместе образуют мультиагентную систему.
Multi-agent orchestration: Логика, которая их координирует. Она определяет, кто и что делает, в каком порядке, с каким общим контекстом и кто утверждает результат.
Координация агентов: Повседневное поведение, которое обеспечивает оркестрация. Передача задач, общие записи и триггеры — все это координация в действии.

4 задачи оркестратора

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

Планирование: Разбивка сложной цели на отдельные подзадачи, с которыми отдельные агенты могут справиться независимо.
Назначение: Сопоставление каждой подзадачи с агентом, способным ее решить. Исследовательский агент занимается сбором данных; агент по написанию текста готовит документ; агент по коммуникации отправляет электронное письмо.
Координация: Управление последовательностью выполнения и зависимостями между агентами. Агент по написанию текста не может составить чертеж обзора, пока исследовательский агент не предоставит данные.
Оценка: Проверка результатов на предмет качества и полноты перед их передачей на следующие этапы или представлением на рассмотрение человеку.

Почему одного ИИ-агента перестает хватать

Один агент может ускорить один шаг в рабочем процессе. Но если окружающие процессы передачи задач остаются ручными, весь рабочий процесс в целом остается медленным. Именно здесь организации сталкиваются с ограничениями локальных решений. Исследование McKinsey показало, что лидеры 5.3 times more likely сообщают о создании ценности на уровне предприятия при перепроектировании рабочих процессов вокруг ИИ — по сравнению всего с 6%, которые видят такой эффект, если рабочие процессы остаются без изменений. Три конкретных типа сбоев объясняют почему.

Тип сбоя 1: Накопление ошибок снижает надежность сквозного процесса

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

Вот как это проявляется:

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

Тип сбоя 2: Распространение агентов приводит к дублированию и отклонениям

Распространение агентов (agent sprawl) происходит тогда, когда команды создают собственные ИИ-агенты без какой-либо координации. В результате вы получаете пересекающиеся агенты, работающие на основе несогласованной логики. Компания Gartner прогнозирует, что к 2028 году среднее предприятие из списка Global Fortune 500 будет использовать over 150,000 AI agents (по сравнению с менее чем 15 в 2025 году), в то время как сегодня лишь 13% организаций считают, что у них есть надлежащее управление для их контроля. Без оркестрации маркетинговая команда создает агента для исследования конкурентов, в то время как отдел продаж создает практически идентичного. Каждый из них берет данные из разных источников и выдает противоречивые инсайты.

Отклонения возникают со временем, когда команды независимо друг от друга обновляют своих агентов:

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

Тип сбоя 3: Межфункциональная работа требует общего контекста

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

Рассмотрим агента по продажам, готовящего информацию по сделке (deal brief):

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

Как работает multi-agent orchestration

Оркестрация связывает ИИ-агентов с помощью 5 базовых блоков. Вот что делает каждый из них и что ломается без него.

Базовый блок 1: Декомпозиция задач

Декомпозиция задач означает разбиение цели на этапы. Когда вы запрашиваете «квартальный бизнес-обзор по каждому клиенту», уровень оркестрации разбивает эту задачу на отдельные подзадачи:

Выгрузить данные об использовании
Рассчитать показатели эффективности (health scores)
Подготовить проект обзорного документа
Отправить сообщение

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

Базовый блок 2: Маршрутизация

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

Маршрутизация эффективна ровно настолько, насколько хороши описания ваших агентов. Нечеткие роли направляют работу не по адресу.

Строительный блок 3: Передача задач (Handoffs)

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

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

Строительный блок 4: Общее состояние

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

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

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

Строительный блок 5: Точка проверки

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

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

Сквозной пример: как все 5 строительных блоков работают вместе

Вот как эти элементы взаимодействуют в конкретном «рабочем процессе тикетов техподдержки»:

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

4 шаблона оркестрации, которые работают для бизнес-команд

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

Шаблон 1: Менеджер-исполнители

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

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

Шаблон 2: Планировщик-исполнитель-критик

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

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

Шаблон 3: Маршрутизатор + специалисты

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

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

Шаблон 4: Общая доска состояния (Shared-state blackboard)

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

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

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

Попробуйте monday agents

Один агент, автоматизация рабочих процессов или многоагентная оркестрация?

Если вы уже используете автоматизацию или единого ИИ-ассистента, вы можете задасться вопросом, нужна ли вам оркестрация. Вот как это решить.

Правило принятия решений 1: Является ли задача узкой и есть ли у нее один владелец?

Достаточно одного агента. Ответы на вопросы клиентов из базы знаний, суммирование заметок о встречах или подготовка чернового варианта документа — все это относится к данной категории.

Правило принятия решений 2: Является ли путь фиксированным и основанным на правилах?

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

Правило принятия решений 3: Охватывает ли работа несколько отделов, требует ли экспертной оценки и включает ли передачу задач или проверку?

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

Хорошее эмпирическое правило: разделяйте агентов там, где человек передал бы работу другому. Если бы вы передали задачу коллеге с другой экспертизой, именно здесь заканчивается зона ответственности одного агента и начинается зона ответственности другого.

Многоагентная оркестрация между отделами: практический пример

Большинство материалов по оркестрации ограничиваются одной предметной областью. Наибольшую отдачу приносит ситуация, когда агенты обмениваются контекстом между маркетингом, продажами, ИТ, операционным отделом и проектным офисом (PMO) в рамках единого рабочего процесса.

Рабочий процесс от лида до встречи

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

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

Продажи: Агент квалификации лидов оценивает лида на предмет соответствия и сигналов намерения, а затем записывает оценку и приоритет на доску CRM.
Сервис: Агент сигналов поддержки проверяет недавние разговоры службы поддержки с компанией потенциального клиента и помечает все, о чем следует знать менеджеру по продажам.
PMO / Операционный отдел: Картограф зависимостей и рисков проверяет открытые обязательства по поставкам. Если у компании потенциального клиента есть незавершенные проекты, он отмечает риски, связанные с графиком или рабочей нагрузкой.
Брифинг: Агент брифинга по подготовке к сделке компилирует сводку и намечает следующие шаги, извлекая контекст от трех предыдущих агентов.
Одобрение человеком: Рабочий процесс приостанавливается для проверки менеджером перед любым исходящим действием. Менеджер видит полный контекст и одобряет или корректирует рассылку.
Выполнение: Доски и дашборды обновляются автоматически. Рассылка отправляется, а карточка сделки отражает актуальный статус.

Дополнительные примеры по отделам

Та же логика работает и в других отделах. Еще три примера:

Решение IT-заявок: агент распределения заявок классифицирует входящие запросы, устанавливает приоритет и направляет нужному специалисту. Агент базы знаний ищет подходящие статьи. Агент «мониторинга SLA» отслеживает время отклика и эскалирует проблемные заявки до того, как будут нарушены обязательства.
HR-рекрутинг: агент поиска находит и ранжирует кандидатов. Агент скрининга оценивает резюме по критериям. Агент планирования организует собеседования без лишней переписки по электронной почте.
Маркетинговые исследования: агент «исследования конкурентной разведки» отслеживает изменения на рынке. Агент аналитики выявляет пробелы в контенте. Агент отчетности компилирует полученные данные в еженерочный дайджест для команды.

Где ломается мультиагентная оркестрация и как сильные команды предотвращают это

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

Типичные сбои, на которые стоит обратить внимание

Когда оркестрация ломается, это происходит по знакомым сценариям:

Застрявшие задачи: один агент завершает работу, но следующий агент никогда не подхватывает ее. Никто не замечает этого до тех пор, пока не истечет дедлайн.
Скрытые сбои: агент сталкивается с ошибкой и останавливается, никого не предупреждая. Рабочий процесс кажется зависшим, но никто не знает почему.
Циклы повторных попыток: агент продолжает выполнять одно и то же действие, тратя впустую вызовы API и вычислительные ресурсы без каких-либо результатов.
Неконтролируемые расходы: агенты генерируют работу быстрее, чем организация успевает ее проверять, что приводит к неожиданным счетам.
Противоречивые результаты: два агента выдают противоречивые результаты, потому что они были созданы независимо друг от друга с разной логикой.
Отсутствие прозрачности: руководство не видит, что делают агенты, поэтому никто не доверяет им большего.

Влияние сбоев оркестрации на бизнес

Вот во что вам обходятся эти сбои:

Более медленная обработка лидов, когда агенты скоринга зависают
Пропущенные SLA, когда агенты триажа заявок дают сбой молча
Дублирование исследований, когда команды создают пересекающиеся агенты
Противоречивые ответы клиентам, когда агенты используют разные базы знаний

Что включает в себя правильно настроенная оркестрация

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

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

Система оценки агентов: 5 метрик для отслеживания

Отслеживайте эти метрики, чтобы оценить эффективность оркестрации и понять, что можно улучшить:

Время передачи задачи: время между выводом данных одним агентом и действием следующего агента. Долгое время передачи указывает на узкие места.
Коэффициент отмен: как часто шлюзы утверждения приводят к отклонению или доработке. Снижающийся коэффициент отмен сигнализирует о растущем доверии.
Время цикла: время от запуска рабочего процесса до получения готового результата. Эта сквозная метрика показывает, ускоряет ли оркестрация работу.
Риск нарушения SLA: процент рабочих процессов, которые приближаются к нарушению обязательств по уровню сервиса или уже нарушают их.
Точность по этапам рабочего процесса: коэффициент ошибок для каждого агента, позволяющий определить, какие из них нуждаются в доработке.

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

Управление — это то, что позволяет командам уверенно масштабировать ИИ. Благодаря ему организации могут расширять возможности агентов в разных отделах, зная, что защитные механизмы находятся на месте. Благодаря ему они расширяют сферы деятельности по отделам, зная, что защитные механизмы на месте. Потребность стремительно растет: по данным отчета Deloitte State of AI in the Enterprise 2026, почти три четверти компаний (74%) планируют внедрить агентский ИИ в течение двух лет, однако лишь 21% сообщают о наличии зрелой модели управления автономными агентами. Четыре механизма делают это возможным.

Механизм управления 1: Ограниченные разрешения

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

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

Механизм управления 2: Журналы аудита

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

Какой именно агент внес изменения
С какими данными он работал
Что послужило причиной действия

Именно это обеспечивает подотчетность агентов.

Механизм управления 3: Одобрение с участием человека

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

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

Механизм управления 4: Что одобрять, а что автоматизировать

Решение зависит от уровня риска и обратимости:

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

Требования комплаенса

Ищите сертификаты SOC 2 Type II, ISO 27001 и HIPAA. Они показывают, что платформа соответствует стандартам защиты данных, контроля доступа и ведения журналов аудита.

Как ИИ-агенты связываются через протоколы MCP и A2A

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

MCP: подключение агентов к платформам и данным

MCP (Model Context Protocol) — это открытый стандарт, который позволяет внешним ИИ-ассистентам безопасно считывать данные внутри рабочей платформы и совершать с ними действия. Он обеспечивает коммуникационный мост между агентами, созданными за пределами вашего основного рабочего пространства, и данными, которые необходимы этим агентам для эффективной работы.

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

Конкретный пример: торговый представитель просит Claude «обобщить, что именно блокирует запуск четвертого квартала по доскам Product, Marketing и RevOps». С помощью MCP Claude считывает информацию с соответствующих досок и возвращает сводку по разным командам. Представитель получает единый, непротиворечивый ответ, основанный на актуальных данных.

A2A: соединение агентов друг с другом

A2A (протокол Agent-to-Agent) — это стандарт, который позволяет ИИ-агентам напрямую общаться друг с другом, обнаруживать возможности, обмениваться сообщениями и передавать работу без маршрутизации всего через человека или центральный API.

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

В полностью оркестрированной системе оба протокола работают вместе:

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

Как реализовать многоагентную оркестрацию в 5 этапов

Этап 1: Начните с одного высокоценного рабочего процесса

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

Выберите рабочий процесс, который соответствует трем критериям:

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

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

Этап 2: Создайте общий контекст

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

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

Признак успеха: каждый агент в рабочем процессе считывает данные из единого общего рабочего пространства и записывает их туда. Никто не копирует данные между системами.

Этап 3: Добавьте защищенную автоматизацию с одобрением человека

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

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

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

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

Этап 4: Масштабирование по отделам

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

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

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