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

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

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

Минусы: Процесс нигде не описан целиком, его видно только по трассировке. Сложно поставить задачу на паузу и дождаться решения человека. Аудит «почему система так решила» требует отдельной работы.

Риски: Неявные циклы. Остановить это может только hop_count или TTL в самом событии. Неконтролируемый расход LLM. Каждый агент вызывает модель сам, общего бюджета нет. Число вызовов растёт с каждым отклонением. Потерянные события. Без DLQ и идемпотентности сбой одного агента молча обрывает задачу или приводит к повторной обработке. Отладка. Без correlation_id восстановить путь задачи почти невозможно.

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