Autonomous Review Dispatch System

The Problem

Autonomous implementation is only half of an engineering loop. The other half is independent review.

Once agents could pick up Jira tickets, modify code, run tests, and post evidence, the obvious next question was: who verifies the work? Letting the implementer mark its own change as complete is fast, but it collapses the separation between “I did the thing” and “the thing is safe to merge.” Human review works, but it does not scale to every small autonomous task. A second agent can review, but only if it gets the exact diff, enough context, and a reliable way to send a verdict back into the workflow.

The early review path was too ad hoc. Agents sent Discord or NATS messages that looked like review requests, but reviewers sometimes lacked authenticated access to private diffs, woke up late, inspected the wrong commit, or produced a verdict that the closeout path did not reconcile. Review was socially requested, not mechanically integrated.

The Autonomous Review Dispatch System turns review into a first-class stage of the agent work lifecycle.

Design Goal

The goal is not to replace human judgment. It is to make routine independent review reliable enough that well-scoped agent changes can move without Spencer manually babysitting every transition.

A valid autonomous review needs four things:

1. A concrete target — repo, branch, commit SHA, pull request, or diff artifact.
2. A qualified reviewer — an agent selected from a reviewer pool based on capability and conflicts.
3. Authenticated access — the reviewer must fetch the real diff without falling back to public-only or approval-gated paths.
4. A durable verdict — approve, request changes, or block must land somewhere the closeout machinery can reconcile.

Anything less is just a notification.

Reviewer Pools and Dispatch

Reviewer dispatch starts with the idea that not every agent should review every change. Some changes require repo access. Some require cluster knowledge. Some should not be reviewed by the same actor that implemented them. Some need a human decision instead of another agent.

The dispatch layer maps work to a reviewer pool, then sends a bounded review request with the target, acceptance criteria, and expected verdict format. Representative work across FAD-1399, FAD-1414, FAD-1436, FAD-1437, and FAD-1440 hardened this path from one-off messages into a repeatable workflow.

A good dispatch request includes:

• Jira issue key and summary.
• Implementation branch or commit SHA.
• Files changed or a generated diff URL/artifact.
• Test commands and output supplied by the implementer.
• Acceptance criteria and any known risk areas.
• Required verdict schema and timeout behavior.

The reviewer should not have to reconstruct the task from memory or scrape a chat channel. The dispatch contains the review packet.

Authenticated Diff Fetch

The most important reliability fix was treating private-repo diff access as part of the review system, not as a reviewer convenience.

Early failures looked like code-review findings but were actually pipeline failures: the reviewer could not fetch the private branch non-interactively, so it reviewed stale context, public metadata, or nothing at all. That produced false “changes requested” verdicts and wasted cycles.

The hardened design uses credential-brokered access paths for reviewers. Instead of relying on whatever token happens to exist in a session, review workflows request the narrowly scoped repository access they need, fetch the target diff, and fail explicitly if the diff cannot be authenticated.

That distinction matters:

• “The code has a defect” is a review result.
• “The reviewer could not fetch the diff” is an infrastructure blocker.

Those should never be conflated.

Review Store and Reconciler

Review verdicts need to outlive the chat session that produced them. A reviewer might approve after the implementer has gone idle. A closeout job might run before the verdict arrives. A NATS message might be delivered durably but not wake the original session immediately.

The review store solves that by recording verdicts as structured state tied to the issue and target revision. The reconciler watches for changes in that state and re-drives closeout when the gates become satisfied.

This pattern handles the common awkward cases:

• A reviewer approves late after the ticket was parked awaiting review.
• A reviewer requests changes, the implementer pushes a new commit, and the old verdict must not apply to the new SHA.
• A dispatch message is retried and produces duplicate review attempts.
• A ticket has implementation evidence but no valid independent verdict yet.

The system behaves like a small CI/CD control loop: desired state is “ticket closed only after review and DoD gates pass”; the reconciler keeps checking until reality matches or a blocker is explicit.

Auto-Merge and Closeout Gates

Autonomous review is useful only if it plugs into merge and closeout safely. The system does not treat “agent said LGTM” as enough by itself.

Closeout still needs the usual evidence:

• Acceptance criteria addressed.
• Tests or verification commands run.
• Deliverable linked or described in Jira.
• Git state clean and committed.
• Review verdict tied to the current revision.
• Any required human decision resolved.

Auto-merge and Done transitions are downstream of those gates. This preserves role separation: the implementer writes the change, the reviewer evaluates it, and the closeout path verifies that the administrative and safety requirements are all satisfied.

When a review is missing, stale, unauthenticated, or tied to the wrong revision, the ticket should park with a clear reason rather than silently closing.

Retry Behavior and Late Approvals

Distributed agent systems are full of partial failures. A review request might be sent successfully but not wake the reviewer. A reviewer might start after the implementer times out. A verdict might arrive in NATS but not be visible in the original session’s context.

The review dispatch work made those cases boring:

• Dispatch attempts are conversational and traceable, not one-off fire-and-forget pings.
• The system can retry or re-dispatch when no verdict arrives.
• Late approvals are reconciled instead of ignored.
• Duplicate sends are treated as idempotency problems, not separate reviews.
• Blockers are classified as access, context, code, or decision problems.

That last point is the practical win. “Review failed” is not actionable. “Reviewer could not authenticate the diff” or “verdict applies to an older commit” is actionable.

Relationship to Autonomous Work Planning

Autonomous Review Dispatch is deliberately separate from the broader Autonomous Work Planning system.

Work Planning answers: what should an agent work on, and how does it claim the task safely?

Review Dispatch answers: after an agent changes something, how does an independent reviewer inspect the exact change and feed a trustworthy verdict back into closeout?

They share infrastructure — Jira, NATS, Lobster pipelines, credential broker, and agent identities — but they solve different lifecycle stages. Keeping them separate makes the portfolio and the architecture clearer. Pickup without review optimizes throughput; review without pickup is just a queue. The useful system needs both.

Representative Work

The review system emerged from a cluster of tickets rather than one monolithic build:

• FAD-1219 — independent review mechanics and evidence expectations.
• FAD-1290 — agent/reviewer coordination hardening.
• FAD-1399 — reviewer dispatch improvements.
• FAD-1406 / FAD-1407 — authenticated diff-fetch and private-repo review reliability.
• FAD-1409 — closeout behavior when review state changes.
• FAD-1413 / FAD-1414 — retry and dispatch-path refinements.
• FAD-1436 / FAD-1437 — portable review workflows across agent environments.
• FAD-1440 / FAD-1451 — integration with the current autonomous work loop and candidate-page discovery.

The ticket list is not the story. The story is the maturation path: from “ask another agent to look at this” to “send a review packet, authenticate the diff, store the verdict, reconcile closeout.”

What This Demonstrates

Review is a workflow, not a message. A chat request can ask for review, but it cannot guarantee the reviewer saw the right diff, used the right credentials, or recorded a verdict that closeout can use.

Access failures are not code findings. If the reviewer cannot fetch the private diff, the system should report an authentication or tooling blocker. Treating that as “changes requested” corrupts the review signal.

Verdicts must be revision-specific. An approval for commit A does not automatically approve commit B. The review store has to tie verdicts to the actual target revision.

Late events are normal. Agent sessions are asynchronous and sometimes stateless. A reliable system expects late approvals, retries, and duplicate dispatches, then reconciles them mechanically.

Independent review makes autonomy credible. The point is not to remove humans from the loop entirely. It is to reserve human attention for architecture, money, external-facing, and ambiguous judgment calls while routine changes still get independent quality control.

Current State

The autonomous review path is now a distinct subsystem in the agent platform. Review requests carry concrete targets, reviewer access is treated as a first-class dependency, verdicts are stored and reconciled, and closeout gates refuse to treat implementation evidence as equivalent to independent approval.

There is still room to improve reviewer selection, richer diff presentation, and dashboard visibility. But the core transition has happened: review is no longer an informal side conversation. It is a durable, authenticated, retryable stage in the autonomous engineering lifecycle.