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

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

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

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

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

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

Типичные провалы предсказуемы. Не реализовать отмену и остаться без способа остановить запуск. Считать поток событий источником истины и зависать при обрыве соединения. Игнорировать учёт расхода. Копить агентов, не архивируя и не удаляя. Выдавать своему исполнителю полный ключ вместо часового токена от имени пользователя. И ходить за списком репозиториев без кэша.