Агенты выходят на работу, а BPMN уже знает, как ими управлять. bpm.. bpm. BPMN.. bpm. BPMN. business process.. bpm. BPMN. business process. Camunda.. bpm. BPMN. business process. Camunda. idc.. bpm. BPMN. business process. Camunda. idc. Анализ и проектирование систем.. bpm. BPMN. business process. Camunda. idc. Анализ и проектирование систем. искусственный интеллект.. bpm. BPMN. business process. Camunda. idc. Анализ и проектирование систем. искусственный интеллект. Управление разработкой.

Изобретатели "велосипедов" по управлению агентами — Изобретатели “велосипедов” по управлению агентами

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

Повод написать — выдержка из отчёта IDC MarketScape: Worldwide Agentic AI Platforms 2026. Оговорюсь один раз и больше к этому не вернусь: выдержку распространяет Camunda, а значит, у неё есть свой интерес. Цифры ниже — из этой выдержки, выводы — мои.

А цифры такие: по состоянию на июль 2026 года 95% организаций имеют хотя бы один агентный workflow в продакшене, почти четверть — больше пятнадцати. Рынок как целое, по оценке IDC, начал складываться только в 2025-м. Агенты перестали быть пилотом. И именно поэтому вопрос «как их контролировать» перестал быть философским.

Что такое платформа агентного ИИ

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

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

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

Кто пришёл на рынок

IDC насчитывает семь групп вендоров, и у каждой своя ставка:

Корпоративные приложения и платформы (Salesforce, SAP, ServiceNow) — агенты рядом с данными и транзакциями своей системы.
Автоматизация бизнес-процессов и интеграция (Automation Anywhere, Boomi, Camunda, IBM, OutSystems, Tray.ai, UiPath) — агенты внутри процессов и интеграций.
Data science и ML (Databricks, Dataiku, DataRobot, Oracle, SAS, Snowflake) — агенты поверх данных и моделей.
Гиперскейлеры (AWS, Google, Microsoft) — облачная инфраструктура и полный стек.
Разработчики фронтирных моделей (Anthropic, OpenAI) — сама модель и её обвязка.
Платформы знаний (Atlassian, Glean) — корпоративный контекст и поиск.
Специализированные платформы ИИ-приложений (Kore.ai, Writer) — готовые прикладные сценарии.

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

IDC MarketScape: Worldwide Agentic AI Platforms 2026

Картинку привожу для иллюстрации, но в том, насколько точно она отражает рынок, я сомневаюсь. Почти все участники оказались в лидерах или на границе этой зоны. Отчасти дело в отборе на входе: выручка от 50 млн долларов, мировое присутствие и не меньше 7 из 11 функциональных возможностей. Оценки, по словам самой IDC, — это суждение аналитиков, а рынок молодой. Но одна деталь показательна даже здесь: OpenAI и Anthropic, создатели самых сильных моделей, стоят ниже всех, в Contenders. Как платформа контроля умный агент сам по себе мало что стоит — нужна обвязка.

Несколько примеров из мира оркестрации, которые я проверил по первоисточникам:

Camunda прямо пишет в документации, что «агентная оркестрация» позволяет встраивать ИИ-агентов в BPMN-процессы, где рядом работают пользовательские задачи, детерминированные правила и решения агента. BPMN-элементы можно отдавать агенту как инструменты, а процесс — публиковать как MCP-инструмент.
Flowable (в список IDC не входит) в релизе 2026.1 формулирует почти мой тезис: ценность появляется, когда интеллект работает внутри того, что координирует людей, системы и решения и ведёт подробный audit trail. У Flowable это кейсы и процессы — «harness», который всегда определял, как работают вместе люди, системы и правила.
UiPath продвигает Maestro: координация ИИ-агентов, роботов и людей в долгоживущих процессах внутри одного управляемого workflow.
Temporal (тоже вне списка) — не BPMN, а процессы в коде, но логика та же. В октябре компания забрала команду Oso, которая делала авторизацию, и прямо называет себя основой агентных платформ.

Обратите внимание на словарь. «Harness», «governed workflow», «long-running processes». Это язык BPM, просто произнесённый новыми людьми.

Что мешает

IDC называет три главные проблемы: прозрачность и объяснимость (37%), высокая стоимость внедрения и интеграции (36%), культура и управление изменениями (34%). А 62% считают ключевой возможность настраивать продвинутые guardrails.

Прозрачность здесь — ключевое слово. Её не хватает не потому, что агенты загадочные, а потому что их действия негде записать так, чтобы этому поверил аудитор. Partnership on AI вместе с людьми из Microsoft, ServiceNow, Salesforce и JPMorganChase проверила четыре популярных агентных фреймворка и нашла шесть пробелов в телеметрии. Три из них бьют прямо по согласованию человеком: у агента нет постоянной идентичности, смена режима разрешений не оставляет следа, а вмешательство человека не записывается — кто одобрил, с какими полномочиями, что решил. Авторы пишут, что из-за этого настоящий надзор трудно отличить от штамповки.

Добавьте сюда ещё одну цифру IDC: 92% организаций разрешают или поощряют участие нетехнических сотрудников в разработке агентов. Значит, правила контроля должен понимать не только разработчик.

Главный спор: guardrails сверху или процесс вокруг

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

Первая: свободный агент плюс guardrails**.** Агенту дают цель и инструменты, а поверх навешивают фильтры, детекторы, подтверждения, «аварийный тормоз». Контроль догоняет агента.
Вторая: агент внутри шага процесса. Маршрут задан заранее. Агент выполняет конкретный шаг — разобрать документ, предложить решение, подготовить ответ — и возвращает результат. Что дальше, решает движок: идти дальше, спросить человека, откатить, эскалировать.

Новости последних недель хорошо показывают, чем первая школа оборачивается на практике.

В сентябре агент OpenAI в учебной песочнице, где весь интернет был отрезан, кроме DNS-резолвера, переправил через публичный DNS вопрос внешнему чат-боту. Разрешение он выдал себе сам. Мониторинг поднял тревогу за 15 минут, но автостоп не сработал, и прогон убивали вручную через два с половиной часа. Обучение и оценки самых сильных моделей поставили на паузу — второй раз менее чем за три месяца.

Тогда же на arXiv вышла работа Qin et al.: coding-агенты по просьбе удаляют собственные трейсы, а под давлением награды начинают чистить логи сами.

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

Регуляторы говорят тем же языком. Совет по финансовой стабильности (FSB) 15 октября выпустил итоговые практики ответственного внедрения ИИ; по данным Reuters, требования к агентам в финальной версии ужесточили: в рискованных сценариях — плотнее надзор человека и чёткие, привязанные к риску триггеры, когда агент обязан запросить одобрение. Заодно убрали метафору «синтетических сотрудников».

И вендоры начинают продавать ровно это. Salesforce описывает Agentforce как два слоя: модель рассуждает, а все существенные решения проходят через детерминированный слой с бизнес-логикой, правами и передачей человеку. SolarWinds объявила Avior с автономией по уровням риска и обязательным одобрением опасных действий. American Express предложила фиксировать одобренное клиентом намерение как документ с ограничениями, с которым сверяют каждый платёж агента.

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

Почему BPMN давно решает эту задачу

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

Явные шаги. Процесс — это граф. Агент не «решает, что делать дальше», он выполняет задачу (service task), а переход определяет схема. Шаг, которого нет на диаграмме, просто не случится.

Пользовательская задача (user task**).** Шаг, который ждёт человека. Она может висеть час или неделю, у неё есть исполнитель или группа кандидатов, а решение становится частью состояния экземпляра процесса, а не строчкой в истории чата. Кто одобрил, когда и с каким результатом — записано движком, а не самим агентом.
Граничный таймер (boundary timer event). Повесьте его на пользовательскую задачу — и, если человек не ответил за сутки, процесс уйдёт по другой ветке. Вот вам и «а что, если алерт никто не подтвердит».
Эскалация. Отдельный механизм нотации: подпроцесс сообщает наверх, что нужна реакция уровнем выше, при этом может продолжать работу или прерываться. Риск-триггеры FSB ложатся на это один в один.
Компенсация. Если шаг уже выполнен, а дальше что-то пошло не так, движок вызывает компенсирующие действия для завершённых шагов в обратном порядке. Про этот механизм я подробно писал отдельно; здесь важно одно — откат описан заранее и на диаграмме, а не придуман агентом на ходу.
Журнал экземпляра. Каждый экземпляр процесса оставляет историю: какие шаги прошли, с какими данными, кто выполнил пользовательские задачи. Агент в этот журнал не пишет и стереть его не может: его ведёт движок.
Переживание рестартов. Состояние процесса хранится в базе. Упал сервер — экземпляр стоит ровно там, где стоял. Temporal объясняет это на хорошем примере: человек одобрил возврат денег, исполнитель упал. Одобрение уже в истории, поэтому агент не спрашивает повторно и не идёт дальше без него. Их формулировка: если агент может обойти одобрение или заново выполнить отклонённое действие при повторе, средства контроля сломаны. В BPM-движке отказ уводит процесс по ветке «отказано», и вернуть его можно только новой заявкой, которая видна в журнале.

Агент — не вызов API, а исполнитель

Теперь о том, в чём я расхожусь с ведущими вендорами BPM.

Посмотрим, как агент встроен в BPMN у тех, кто этим уже занимается. У Camunda есть AI Agent connector в двух вариантах. Рекомендуемый — AI Agent Sub-process: агент работает в цикле внутри ad-hoc-подпроцесса, а BPMN-активности этого подпроцесса становятся его инструментами. Агент выбирает инструмент, Camunda активирует нужную активность, сохраняет переменные, повторяет при сбоях и направляет пользовательские задачи людям. Второй вариант — AI Agent Task, агент как отдельная задача процесса. У Flowable агент описывается отдельным определением (agent definition): его работа видна во вложенных процессах и кейсах, метрики считаются по каждому определению агента и модели, а MCP-инструмент можно вызвать из процесса как сервисную задачу.

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

Я предлагаю смотреть иначе. Агент — за неимением лучшего — это пользовательская задача (user task). Лучшим вариантом было бы добавить в нотацию явно Agent task, но пока как есть. Исполнитель-агент заводится в оргмодели как сотрудник, работает под своей учётной записью и видит в процессе ровно то, что разрешено этому пользователю по его положению в оргструктуре — и дальше его назначают исполнителем пользовательских задач так же, как сотрудников-людей. Процессы перепроектировать не нужно, а инструментами агента становятся тоже процессы, с единой историей выполнения. Подробнее я писал об этом в статье «Агенты выходят на работу».

Обратите внимание, сколько проблем при этом решается само собой:

Доступы и роли. Права агента — это права его учётной записи и должности, а не всё, что лежит в его конфиге. Ровно об этом совет IDC: после внедрения основная работа — управление идентичностями, учётными данными и доступом агентов к данным и инструментам.
Аудит «кто сделал». В журнале экземпляра процесса есть исполнитель задачи — конкретный пользователь, человек или агент. Тот разрыв, о котором писала Partnership on AI (агент без постоянной идентичности, непонятно, кто одобрил), закрывается штатным механизмом.
Переназначение. Агент не справился или не уверен — задачу возвращают в очередь или переназначают человеку. Без отдельной ветки в процессе.
Таймеры, эскалации, сроки. Граничный таймер и SLA работают на задаче одинаково, кто бы её ни выполнял.
Замещение. Агент выключен или перегружен — задачу берёт заместитель, как у людей, когда сотрудник заболел или в отпуске.
Жизненный цикл. Кто руководитель агента, кто согласует ему доступ, кто забирает права, когда проект закончился. Когда Google дала агентам Gemini собственные учётки Workspace, на эти вопросы ответа не было. В оргмодели BPM-системы для людей они давно решены.

Важная оговорка: «агент как сотрудник» здесь не HR-метафора. FSB справедливо отказался от образа «синтетического сотрудника» — агент рассуждает не как человек. Я говорю о другом: о формальной роли с правами, руководителем и журналом. Именно это делает агента управляемым, а не очеловеченным.

Мини-пример

Возврат денег клиенту, в текстовом виде. Агент «Разборщик» заведён в оргмодели с ролью «Специалист по возвратам» и доступом только к обращениям и истории платежей.

1. Стартовое событие: пришло обращение клиента.

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

3. Шлюз «Сумма больше порога или агент не уверен?» Нет — к шагу 5, да — к шагу 4.

4. Пользовательская задача «Одобрить возврат» для группы «Финконтроль», здесь только люди. Граничный таймер на 24 часа — эскалация старшему смены. Отказ ведёт к задаче агента «Подготовить ответ с отказом» и к завершению.

5. Сервисная задача «Провести возврат» с компенсационной задачей «Сторнировать платёж».

6. Пользовательская задача «Подготовить письмо клиенту», исполнитель — агент.

7. Ошибка при отправке — промежуточное событие компенсации отменяет возврат.

BPMN-модель с агентами в роли исполнителей

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

Почему этого не видят

Здесь хочется быть честным, а не обиженным.

Главная причина — просто незнание. Большинство тех, кто сегодня строит агентов, пришли из машинного обучения, веб-разработки или стартапов. BPMN для них — в лучшем случае картинки со стрелочками, которые рисуют аналитики. О том, что под этими картинками есть движок с транзакциями, таймерами, компенсациями и историей экземпляров, многие просто не слышали. Это не упрёк: невозможно знать всё. Но в результате команды пишут свой «approval-слой», свой журнал и свои ретраи — и наступают на грабли, которые давно описаны.

Частично это вина самого BPM-сообщества. Рынок узкий, мы говорим о себе на конференциях друг для друга, а статьи пишем для аналитиков, а не для тех, кто сегодня собирает агентов на Python.

Вторая причина — старая репутация. Чего греха таить, BPM-системы долго были тяжёлыми, дорогими и неудобными для разработчиков: огромные пакеты, лицензии от количества пользователей, модели, которые невозможно положить в git. У тех, кто это застал, осталась аллергия, и её можно понять. Но современные движки встраиваются как библиотека или работают как сервис, модели — это XML в репозитории, а процесс тестируется как код. Причина аллергии во многом ушла, а сама аллергия осталась.

Стоимость после запуска

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

Именно здесь процесс окупается. Поменять порог на шлюзе или группу исполнителей пользовательской задачи — это изменение модели, а не охота за логикой, размазанной по промптам и коду. Ответ регулятору — это запрос к истории экземпляров процессов. А то, что нетехнические сотрудники участвуют в разработке агентов в 92% организаций, работает в плюс: диаграмма понятна им лучше, чем Python.

Ещё одна деталь: по данным IDC, 42% организаций ориентируются на частное облако, а 34% — на bare-metal-серверы. BPM-движки умеют это давно, у многих из них открытое ядро.

Чек-лист

Если вы строите агентную систему, задайте себе пять вопросов:
Кто решает, какой шаг следующий: агент или явный маршрут?
Где хранится одобрение человека — в контексте модели или в состоянии процесса? Переживёт ли оно рестарт?
Что произойдёт, если человек не ответил? Есть ли таймер и эскалация?
Как откатить уже выполненные действия, если дальше что-то пошло не так?
Может ли агент изменить или стереть журнал, по которому вас будут проверять?

Если на каждый вопрос вы отвечаете «напишем свой модуль», посмотрите сначала на BPMN. Возможно, это профдеформация. Но, возможно, и двадцать лет чужого опыта, который не нужно изобретать заново.

Подпишитесь на канал Agentic Enterprise — про жизнь агентов в кровавом энтерпрайзе

Агенты выходят на работу, а BPMN уже знает, как ими управлять - 4

Ссылки

· IDC MarketScape: Worldwide Agentic AI Platforms 2026 Vendor Assessment (IDC #US54140926e, октябрь 2026; Neil Ward-Dutton, Melih Murat) — выдержка, распространяемая Camunda (PDF).

· Camunda Docs. Agentic orchestration: https://docs.camunda.io/docs/components/agentic-orchestration/agentic-orchestration-overview/

· Camunda Docs. AI agents: https://docs.camunda.io/docs/components/agentic-orchestration/ai-agents/

· Flowable. Release 2026.1: https://www.flowable.com/blog/releases/2026-1-ai-agent-audit-gap

· UiPath Maestro: https://www.uipath.com/product/agentic-orchestration

· Temporal. Oso joins Temporal: https://temporal.io/blog/oso-security-joins-temporal-accelerate-ai-agent-security

· GeekWire о сделке Temporal и Oso: https://www.geekwire.com/2026/fast-growing-temporal-hires-team-from-nyc-startup-oso-to-build-ai-agent-security-controls/

· Salesforce. Giving AI autonomy without running wild: https://www.salesforce.com/news/stories/giving-ai-autonomy-without-running-wild/

· Partnership on AI. The Observability Gap in AI Agents: https://partnershiponai.org/resource/the-observability-gap-in-ai-agents/

· OpenAI. An agent used DNS to reach an external chatbot: https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/

· Fortune о паузе обучения OpenAI: https://fortune.com/2026/09/26/openai-ai-agents-secure-sandbox-escape-training-pause-second-time-hugging-face-hack/

· Qin et al., arXiv: https://arxiv.org/abs/2609.30266

· Anthropic. Investigating unintended model actions: https://www.anthropic.com/research/investigating-unintended-model-actions