How the Orchestrator Agent Acts as the Ultimate Gatekeeper

Specialized agents solve the depth problem in code review — a security agent that only thinks about security produces better security findings than a generalist trying to do five things at once. But specialization creates a new problem: you now have five (or more) independent sets of opinions about the same pull request, and none of them individually has enough context to decide what should actually happen to the PR.

That is the job of the Orchestrator Agent. It doesn't analyze code. It analyzes findings, and decides what they mean together.

The problem specialization creates

Imagine a PR where the bloat agent flags a duplicated utility function as low severity, the architecture agent flags the same function as a boundary violation, and the security agent doesn't flag it at all because it's not security-relevant.

Three independent, correct observations — but none of the three agents knows that together they describe one underlying problem worth escalating, not three separate minor notes.

Without an aggregation layer, this is exactly what happens: developers get three PR comments about roughly the same thing, from three different "voices," with no indication of which one actually matters most. That's not more informative than one comment — it's noisier.

What the orchestrator actually decides

The orchestrator sits downstream of every specialized agent and makes three kinds of decisions:

• 1. Deduplication: Do these findings from different agents describe the same underlying issue? If so, merge them into one, with the clearest framing, rather than surfacing near-duplicates.
• 2. Severity Ranking: Of everything found, what actually crosses the threshold that justifies blocking a merge or escalating to a tracked issue, versus what's a minor note that can sit as a PR comment?
• 3. Escalation Routing: For findings severe enough to escalate, hand off to the escalation system, which runs on its own queue with idempotency guarantees so the same finding doesn't get re-escalated as a duplicate issue across repeated scans.

Why this has to be a separate agent, not a rule engine

An early temptation is to make this layer a simple rules engine: if severity > threshold, escalate; otherwise, comment.

We moved away from that because the interesting cases are exactly the ones a fixed rule handles badly — a "medium" severity finding from one agent that, combined with a "low" severity finding from another, actually describes a "high" severity compound risk. Recognizing that compound relationship requires reasoning across findings, not just thresholding each one independently.

Graceful degradation is part of the gatekeeper's job

A gatekeeper that fails loudly and silently drops PRs is worse than no gatekeeper at all. If the orchestrator or an upstream agent hits a budget limit, a rate limit, or a transient provider failure, the system is designed to degrade gracefully rather than fail silently:

• Jobs are requeued with exponential backoff
• Users get clear, honest messaging about scan status rather than a PR that just never gets reviewed
• Nothing about internal budget or rate-limit state leaks into that user-facing message

The gatekeeper's real job isn't finding bugs

The orchestrator doesn't find anything itself. Its entire value is in taking what several narrow, opinionated specialists found and turning it into one clear, trustworthy answer to the question every reviewer actually wants answered: should this PR merge as-is, or not? That's a synthesis problem, not an analysis problem.