The PR queue is becoming a decision system

CodeRabbit calls Triage the "prioritization layer" of what it calls Agentic Change Management: its system for governing software change from both people and agents (CodeRabbit, September 2026). Triage replaces FIFO ordering with a deterministic P0-to-P3 score per pull request, and it shows the evidence behind each score. That is not marketing language stretched onto a review feature. It is a genuine move from probabilistic AI review toward deterministic, evidence-backed governance output, and it is the clearest signal yet that agentic development is pushing governance into the delivery pipeline itself.

A PR is not an architectural decision

Triage's own framing is honest about its object: it governs the change, not the architecture the change has to fit inside. CodeRabbit says explicitly that architectural judgment, including whether an abstraction makes sense for the application, remains human. That is the right boundary, and it is also the gap. A pull request is a transient artifact: opened, scored, merged, closed. An architectural decision is not. It survives the PR that prompted it, the next thousand PRs, a framework migration, a team rewrite, and every agent that touches the codebase afterward. A system that scores PRs needs a durable, separate answer to what decisions apply to this PR before it can meaningfully judge whether the PR is safe to advance.

Change evidence and decision authority are different things

Triage can explain why a PR is P0 instead of P3: it shows the evidence behind the score. That is change evidence. It is a different kind of evidence from decision authority: why an architectural decision governs this action, who approved it, what constraint follows from it, and whether it is still in force. Change evidence answers whether a change is good. Decision authority answers what the change is bound by. Conflating the two produces tools that can explain their own risk model but cannot say whether the code violates an architecture the organization already agreed on.

The agentic SDLC now has two control planes

Put together, the emerging stack for governed agentic delivery has two distinct planes, not one:

Human architectural judgment
        |
        v
   Decision Index
        |
        v
 Decision applicability
        |
        v
  Decision enforcement
        |
        v
     Code change
        |
        v
Review / risk / prioritization
        |
        v
       Merge

The decision plane sits before the change exists: what has been decided, what applies, what is enforced before generation. The change plane sits after: what changed, is it correct, what risk it carries, whether it is ready to merge. Neither plane can do the other's job. A prioritization engine that tries to encode architectural authority ends up re-deriving governance ad hoc, per repository, per rule. A decision layer that tries to score PR risk ends up duplicating review tooling it has no advantage building. See the full breakdown in Mneme's architecture overview.

MCP is the interoperability boundary between them

Until recently, connecting the two planes meant one of two bad options: a change-management system re-implements architectural governance itself, or a governance system builds bespoke adapters into every review and CI product it wants to reach. Mneme's Decision MCP server, shipped in 0.9.0, is built for the second boundary: a stable, six-tool protocol surface an agent, IDE, or other MCP host can call to retrieve the architectural decisions applicable to a proposed action, with provenance attached, without adopting Mneme's storage model or internals. It runs as a local stdio process in 0.9.0, so a hosted reviewer or change-management service is a pattern the protocol enables, not a connection available today.

To be precise about maturity: Mneme has no CodeRabbit integration today, and this is not a roadmap announcement. It is the shape of what MCP enables. A change-management system built the way CodeRabbit describes Triage could call decision.applicable_to to retrieve the decisions governing a change, while continuing to own its own review, impact analysis, and prioritization entirely. See how that boundary is designed to work and the full six-tool reference.

Where to start

Before a system can decide which change deserves attention, the organization needs a durable, enforceable answer to what it has already decided about the architecture. Most codebases do not have one: the decisions exist in someone's memory, an old ADR, or a chat thread, not in a form any system, human or agent, can query. The decision-plane-versus-change-plane distinction only pays off once decisions are actually represented in enforceable form. The Architecture Audit is the place to find out how much of your architecture already is, using the same four protection states that turn "we decided this once" into a queue you can act on.