Find merge requests without review and dig into pipelines

The agent calls the GitLab API — of whichever instance was entered at connection: gitlab.com or the root of your own install. It reads projects, issues, merge requests with their comments, commits and CI/CD pipelines, and then works things out: which MRs have hung without review the longest and whose turn it is, which job the overnight pipeline broke on, whose commit triggered it and whether it has happened before.

A failed pipeline on its own explains little: the agent goes down to the job level and names the specific step and commit rather than just the red status of the whole run. The second GitLab peculiarity is numbering: a merge request and an issue each have a number within the project and a global identifier, and these are different numbers, so the agent always keeps the project alongside — otherwise MR number 5 exists differently in every repository.

The agent accepts a GitLab webhook only when it is signed: without a shared secret or a secret token in the header the delivery is rejected, and a repeat delivery of the same event is dropped by its identifier. That is how a push, a new MR and a failed pipeline reach the chat without polling on a schedule. With the api scope writing is technically within reach, but a comment, a status change or a job re-run is agreed with you before it happens.

The agent sees exactly what the account whose token is connected sees: no request gets it around a project's permissions, and instead of guessing it answers that the section is closed. Lists of issues, merge requests and pipelines come back in pages, so a large project is walked in portions with the agent holding its own request rate. It never downloads a whole repository — it reads the files it needs and the diffs of specific commits, and if there is no data for the period it says so directly instead of showing an empty digest.