Два ИИ-агента в New Street Studios превратили идею коллекционной карточной игры в файл, готовый к печати. Однако главным событием стало то, как система обнаружила ошибку до того, как она прошла по цепочке производства. Когда производственный бот заметил скрытый ключевой элемент на арте, он отправил файл обратно боту-дизайнеру, предотвратив ошибку без вмешательства человека.

Почему важна передача задач

Тест был направлен на измерение предотвращения ошибок, а не скорости. Обычно дизайнер создает черновик карты, инструмент производства корректирует макет, а человек-рецензент дает одобрение. Если на этапе производства обнаруживается проблема, вмешивается человек, интерпретирует проблему и переназначает задачу. В этом эксперименте производственный бот — INKA-01 — заметил позу персонажа, которая скрывала важный игровой элемент. Вместо того чтобы просто обрезать изображение, он сформировал сообщение об отказе, в котором указал на конкретную ошибку, объяснил, почему текущие инструменты не могут её исправить, и вернул артефакт боту-дизайнеру — LUDO-01. Цикл замкнулся без участия человека.

Как устроена команда

Студия использует публичный канал в Slack, где работают ИИ-сотрудники. У каждого бота есть одна четко определенная обязанность:

  • LUDO-01 создает игровые концепции и арт для карт.
  • INKA-01 готовит файлы к печати.
  • VENDA-01 обновляет онлайн-магазин.
  • CORA-01 модерирует канал.

Человек-оператор — упоминаемый лишь как «Я» — проверяет всё, что покидает канал. Такая структура превращает набор промптов в настоящую мультиагентную систему, где каждый агент может принять или отклонить результат работы другого.

Механика явного отклонения

Полезная проверка — это не просто фраза «что-то выглядит не так». Она должна:

  1. Назвать ошибку — точно указать на проблему (например, «скрыт ключевой предмет»).
  2. Объяснить, почему текущий инструмент не может её исправить — прояснить ограничение (например, «обрезка приведет к потере важных деталей»).
  3. Вернуть артефакт соответствующему вышестоящему агенту — направить работу обратно дизайнеру для переработки.

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

Создание подобной системы

Эксперимент позволил сформулировать пять практических правил для тех, кто хочет воспроизвести такую схему:

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

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

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