Orbit Change Guardian

An AI Duo agent that predicts a merge request's blast radius from the GitLab Orbit graph — and opens the work to fix it.

Comment

Inspiration

Every team has the same story: a merge request looks small, the diff is clean, two reviewers approve it, and three hours later a service nobody mentioned in the MR is on fire. The problem isn't the diff. A diff tells you what changed; it never tells you what depends on what changed. Reviewers approve with almost no view of downstream impact: which services, APIs, and pipelines rely on the touched code, who actually owns them, or whether a similar change caused an incident last quarter.

I realized GitLab already has the missing piece: Orbit, a knowledge graph of the codebase and its relationships. If the impact is hiding in a graph, then predicting a merge request's blast radius is a graph-traversal problem, and the GitLab Duo Agent Platform is the perfect place to run it, right where the review happens.

What it does

Orbit Change Guardian is a GitLab Duo Agent Platform flow that runs when its agent is mentioned or assigned on a merge request. In a single pass, with no back-and-forth chat, it:

  1. Pulls the MR's changed files.
  2. Queries the GitLab Orbit knowledge graph for every entity connected to those files: components, services, APIs, pipelines, owners, security findings, past MRs, and incidents.
  3. Traverses depends_on edges in reverse, the headline insight, to surface the downstream consumers the diff never touched.
  4. Scores risk 0 to 100 with an explainable 6-factor model: component criticality, dependency blast radius, security exposure, incident history, pipeline stability, and change size. Every point of the score traces back to a specific graph fact, and nothing is fabricated.
  5. Acts. It posts a full risk report as an MR comment and opens four mitigation work items: security review, integration testing, deployment approval, and post-deploy monitoring, with owners pulled from the Orbit ownership graph.

It's a workflow automation, not a chatbot: one mention, and the full impact analysis plus the follow-up work appear, before a single line is merged.

How I built it

The Agent Skill encodes the analysis procedure and the deterministic scoring model, so results are reproducible and explainable.

The custom Flow wires the trigger and the toolset (get_merge_request, create_merge_request_note, create_issue), and is published to the AI Catalog.

A reference TypeScript implementation (Express plus React with React Flow) mirrors the exact analysis for local runs without a Duo environment, with a built-in Orbit demo graph of 9 services, owners, findings, historical MRs, and incidents.

The scoring model is intentionally deterministic. The score is the sum of each factor's contribution, clamped to a range, and each contribution is itself capped at a factor-specific ceiling. This means the LLM layer can refine the narrative, but it can never inflate the number.

What I learned

Reverse graph traversal is where the value hides. Anyone can list what an MR touched. Surfacing what quietly depends on it, services that appear nowhere in the diff, is the insight reviewers actually lack.

Explainability beats cleverness. A single AI-generated risk number is easy to distrust. Making every point attributable to a graph fact, and refusing to fabricate factors when the graph is sparse, is what makes it usable in a real review.

Building on a platform changes the design. Shipping as a Duo flow and AI Catalog artifact, rather than a standalone app, forced me to think in terms of triggers, toolsets, and a reusable Skill, a genuinely different shape than a web app.

Challenges I faced

Trigger semantics. The flow fires on mention or assignment of its service account, not on a generic "MR ready" event, and the trigger context only passes the MR ID, not the project path. I had to design around mentioning the agent with the full MR URL so it has everything it needs in one shot.

Honest scoring on a sparse graph. When Orbit returns no pipeline, incident, or finding nodes for the touched files, those factors must score zero, not a guess. I added an explicit Orbit note and an evidence-based confidence band, so a score built on one signal is never presented with the same authority as one backed by four.

Keeping the model deterministic while still using an LLM for the human-readable narrative, without letting the narrative drift from the underlying graph evidence.

What's next

Confidence intervals on the risk score from richer incident history. Auto-requesting the recommended reviewers via the GitLab API. And a policy gate mode that blocks merge until blocking work items are resolved.

Links

AI Catalog flow: https://gitlab.com/chakrabortysriparna812-group/orbit-guardian/-/automate/flows/1011773/ Project (MIT): https://gitlab.com/chakrabortysriparna812-group/orbit-guardian

Built With

Share this project:

Updates