Агент ходит в API GitLab — того инстанса, адрес которого указан при подключении: gitlab.com или корень вашей установки. Читает он проекты, issues, merge request с комментариями, коммиты и пайплайны CI/CD, а дальше считает: какие MR висят без ревью дольше всех и за кем очередь, на каком job сломался ночной пайплайн, чей коммит его запустил и повторялось ли это раньше.

Упавший пайплайн сам по себе мало что объясняет: агент спускается на уровень job и называет конкретный шаг и коммит, а не только красный статус целого прогона. Вторая особенность GitLab — нумерация: у merge request и issue есть номер внутри проекта и сквозной идентификатор, и это разные числа, поэтому агент всегда держит рядом проект, иначе «MR номер 5» существует в каждом репозитории по-своему.

Вебхук GitLab агент принимает только подписанным: без общего секрета или секретного токена в заголовке доставка отклоняется, а повторную доставку одного события он отсекает по его идентификатору. Так push, новый MR и упавший pipeline попадают в чат без опроса по расписанию. На запись со scope «api» агент технически способен, но комментарий, смену статуса или перезапуск job согласует с вами до выполнения.

Видит агент ровно то, что видит аккаунт, чьим токеном он подключён: обойти права проекта запросом он не может и вместо догадки отвечает, что раздел закрыт. Списки issues, merge request и пайплайнов API отдаёт страницами, поэтому крупный проект агент обходит порциями и сам выдерживает частоту запросов. Репозиторий целиком он не выкачивает — читает нужные файлы и диффы конкретных коммитов, а если данных за период нет, скажет об этом прямо, а не покажет пустую сводку.