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

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

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

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

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