Always-on AI code review governance

You can review an agent's pull request in a minute if the PR carries its own receipts, and you cannot if it does not. AI code review governance is the small set of receipts and scopes that let a reviewer verify agent work without replaying the session that produced it. With always-on agents like Claude Code, Anthropic's coding agent, shipping while you sleep, review stops being a stage you walk through and becomes a property the workflow either has or fakes. The good news: the fix is mostly four short artifacts you paste into your repo once.

The failure mode is familiar. In pairing sessions with tech leads, the same gap shows up: a verification command ran in chat, proved the fix, and then died there. The PR description stayed confident and empty. Multiply that by an agent that never logs off and you get a merge queue that feels slower the more it ships.

Stop losing the verification command

The first thing to fix is the command that proved the work and then vanished. If the only place "we ran the tests" lives is a chat transcript, your review is archaeology.

Make the agent hand back a receipt instead. Every forked or child run should return the paths it touched, the commands it ran, and the tests that prove its regression guards held. Now a parent agent, or you, can green-light a diff at midnight without guessing what happened inside it.

This also fixes recursive handoff blur, where chained agents return tidy summaries that quietly omit the paths a child actually edited. During a crunch week those summaries shrink to vibes. A required receipt block does not.

Make the PR answer "why this approach?"

Green CI does not tell a reviewer why the agent chose one design over another, so they ask. When the queue is long, that question gets asked again every night.

Answer it once, in writing, with a decision stub: three forced lines at the top of the PR body.

## Decision stub
- Constraints considered: <what bounded the choice>
- Rejected alternatives: <what we did not do, and why>
- Verification proof: <command output, pasted or linked>

Three lines kill the nightly "but why did it do it this way" debate. The reasoning is on the PR, not in someone's memory of a chat window.

Give every run a scope before it starts

Scope fog is the Claude problem. Claude, Anysphere's AI code editor, lets you write rules in .mdc files, and the language reads as precise until two reviewers argue about what it meant. Those rules also compete with the model's chat memory, so coordination splits in two. The Claude agent docs cover the rule mechanics worth encoding.

The fix is a scope ledger: five lines you set in the parent chat before the agent moves.

## Scope ledger
- Goal: <one sentence>
- Allowed paths: <globs the agent may edit>
- Forbidden paths: <globs it must not touch>
- Verification command: <how we prove it worked>
- Merge owner: <the human who approves>

A ledger gets checked against the diff. Prompts get re-litigated. Pick the ledger.

Pin permission precedence so sessions stop inventing policy

The Claude Code risk is quieter: on a shared laptop, approving a bash command becomes muscle memory, and an always-on schedule means nobody is watching when the muscle twitches at 2am. The Claude Code getting started guide documents the permission file that needs a named owner.

State the rules at the top of CLAUDE.md so no session has to invent them mid-run: which hooks win, which folders require human eyes, and where temporary overrides live. Connector behavior belongs in the same record. The MCP specification exists so an agent's capabilities are declared up front rather than discovered after the fact.

Here is a boundary snapshot you can adapt:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Claude: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

If your repo handles compliance or customer data, put the NIST AI Risk Management Framework in the review checklist itself, not in a wiki nobody opens. The same bar runs through the rest of agentic coding governance, and the boundary-setting half of this work lives in AI agent boundaries that hold.

The review strip you can paste today

An always-on workflow is governed when four questions already have written answers. Here they are next to the receipt that answers each one.

And the checklist a reviewer can run in under a minute:

• Red-folder paths got explicit human acknowledgement.
• Scopes in the PR body match the folders in the diff.
• Verification output is pasted or linked.
• Any MCP connectors used list an owner.

The whole thing reduces to one test: can you answer "why did the agent touch this file?" without opening a chat log? If yes, you are governed. This is where receipts meet responsibility in our methodology.

Common questions

• What is AI code review governance?

  AI code review governance is the set of receipts and scopes that let reviewers verify agent work without replaying sessions. In practice that means four artifacts: child receipt blocks, decision stubs, scope ledgers, and written permission precedence. Together they make always-on agent output reviewable at human speed instead of forcing chat archaeology on every pull request.

• How do I review agent PRs without replaying the chat?

  Demand the receipts up front. The PR body should carry the scope ledger and the decision stub, and forked work should arrive with a child receipt block listing paths touched, commands run, and tests proving the regression guards. If answering a single review question still sends you back to the session log, a receipt was missing. Add it to the template.

• Why do merge queues slow down when agents ship more?

  Brooks's law, applied to review: throughput rises, but coordination cost rises faster, so a tired queue drains slower with each added run. Receipts cut that coordination cost, which is why governance starts to read as velocity. Once surprises stop scaling, reviewers stop doing archaeology and the queue finally moves.

• Where should connector and MCP behavior be documented?

  In the same place as your permission rules, at the top of CLAUDE.md or its equivalent, so capability is declared rather than discovered. List which MCP servers a workflow may call and who owns them. The receipt block then confirms which servers actually fired during a run, so you can spot an unexpected connector before it merges.

Where to start

Add the decision stub to your PR template this week, then sample five recent agent PRs and count how many questions forced you back into a chat log. Keep the receipt format that drives that count to zero, and if you want it installed on a live repo with your team, that is what our training does.