Допустим, несколько AI-агентов одновременно работают с одной CRM. Один меняет статус клиента, второй обновляет данные, третий создаёт задачу для менеджера.

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

Но что произойдёт, если два агента одновременно изменят один и тот же объект?

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

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

Поэтому параллельность нельзя строить по принципу «запустим всё одновременно и потом разберёмся».

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

Но если два агента изменяют один объект или используют данные, которые могут измениться во время обработки, нужны дополнительные правила.

Это может быть: → проверка версии объекта перед изменением; → блокировка ресурса; → один ответственный за изменение; → контроль уникальности действия; → повторная обработка при обнаружении устаревших данных.

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

Поэтому параллельный workflow обычно строится по схеме: разделить → выполнить → синхронизировать → собрать результат.

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

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

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

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

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