Inspiration
Every team asks the same question at every merge request: is this change safe to ship? Most answer it with a green pipeline and a gut feeling. AI review comments help, but a comment never stops a risky change from merging, and a language model asked to "give a score" can quietly make up the arithmetic. We wanted a real control: one decision per merge request, backed by evidence, calculated by code that the team can read and audit. That became Gitons. Ship with evidence, not assumptions.
What it does
Gitons is a merge safety control plane for GitLab. On every merge request it posts a score from 0 to 100, explains the evidence in plain language, and applies the team action: advance, require approval, or stop.
Four focused agents gather the evidence:
- Change Agent reads the actual merge request diff and reports change risk.
- Security Agent reads the matching pipeline security reports and returns scoped severity counts for the changed files.
- Test Agent reads parsed test reports and measured coverage.
- Risk Signals Agent checks change size, linked issues and configured release windows.
A Decision Agent then validates all four reports and runs a deterministic evaluator to produce the final score. An action adapter records the result and manages a reversible Draft gate, so a merge request stays in Draft while the review is held. Maintainers can approve a held change with one comment that names the exact commit SHA and a reason, and every action leaves an audit note in the merge request.
How we built it
Gitons is a custom flow on the GitLab Duo Agent Platform, published in the GitLab AI Catalog. It chains seven components: a pre review draft hold, the four specialist agents, the decision agent and the action adapter. The specialists pass structured JSON directly through flow state, so no agent ever has to trust a user comment as evidence.
The score is not calculated by a model. It comes from gitons/scoring.py, a standard library Python evaluator, using a team policy stored as code in .gitons-policy.json. The Decision Agent fetches the policy and evaluator from the pinned target branch commit and runs them in a fresh temporary directory with structured JSON input, shell execution disabled and a 30 second limit. A second trusted planner, gitons/gate.py, decides Draft and approval operations. Teams configure thresholds, penalties, change size limits, linked issue rules, release windows and approval behavior, all reviewed through normal code review.
A GitLab CI pipeline runs the pytest suite with coverage and SAST on every change, and a configuration generator (python -m gitons.configure) produces the flow and policy for any other project.
Challenges we ran into
Models are good at reading evidence and unreliable at arithmetic, so we separated judgment from calculation: agents collect facts, and a deterministic evaluator computes the score.
Trust was the hardest design problem. Merge request text, code and comments are untrusted, so Gitons never follows instructions found in them, and it always loads policy and scoring code from the target branch, never from the branch being reviewed. Otherwise a merge request could rewrite its own rules.
Missing or stale evidence had to fail safely. If a pipeline, report or revision does not match the current head commit, or a report is duplicated or malformed, Gitons falls back to a score of 0 with require approval instead of guessing. It also re checks the head commit right before posting.
GitLab has no native required approval gate we could attach to, so we built a Draft gate with an ownership marker and an audit trail, and we state its limits honestly: authorized users can still mark a merge request ready, and GitLab records that action.
Accomplishments that we're proud of
We built a decision that lives where developers already work, inside the merge request, and that can be verified rather than trusted. We are proud of the fail closed behavior, the exact revision binding, the policy as code approach, the separation between AI evidence gathering and deterministic scoring, and a project that is fully open under the MIT license with a passing CI pipeline and a production path acceptance merge request as live evidence.
What we learned
We learned that AI works best as an evidence collector inside a system with strict boundaries, not as the final calculator. We learned that a score people can inspect, with every penalty and gap explained, earns far more trust than a confident number. We also learned how much of production readiness is decided at the merge request, long before deployment.
What's next for Gitons
Next we plan to verify and ship rerun triggers for new commits and new pipeline results, add score history and trends across releases, route high risk changes to the right approvers automatically, and build a VS Code companion that shows the same decision beside the diff while GitLab stays the system of record.
Log in or sign up for Devpost to join the conversation.