Why a 50-Round PR Review Reveals AI Agent Core Architecture

The article opens with a concrete case: a Claude Code CLI pull request that cycled through more than 50 review–fix rounds without converging. git blame showed that roughly 59% of the repeated comments pointed to code that already existed in the first review. The reviewer kept re-scanning old code while the fixer kept patching the same issues, yet the system never stopped on its own.

One Control Loop: It Must Know When to Stop

The core loop is Observe → Judge → Act → Verify, with a feedback line from Verify back to the continue/stop decision. In code review:

Observe: read PR goal, current diff, related code, historical comments, CI results.

Judge: identify a potential defect or decide an opinion is resolved.

Act: post a comment, modify code, run tests, push a commit.

Verify: confirm the issue disappeared, no new regressions, merge conditions satisfied.

The article stresses that being able to call another tool does not mean the task should continue . Termination must be decided by external evidence on the current version — comments resolved, CI green, risk approvals bound to the latest commit SHA. Anthropic’s rule: human approval binds to a specific commit; a new untrusted commit invalidates that approval. This is a task-level stop condition, not a model-level one.

The author distinguishes three nested loops: the inner run loop (one observe–judge–act–verify cycle), the task loop (whether the PR can finish), and the evolution loop (incidents and rollbacks feeding back into eval sets). They must exchange data but never merge into a single infinite loop.

Two Data Flows: Context In, Evidence Out

What the Agent Sees (Context Flow)

The reviewer cannot ingest the whole repo, full chat history, and dozens of tool outputs. It needs a curated snapshot. The article lists the minimum required inputs:

PR goal — why this change exists (cannot prove correctness alone).

Current diff + related code — what changed and what it touches (stale unless re-read). CLAUDE.md / REVIEW.md — project conventions, directory risks, review boundaries, nit thresholds (cannot replace permission/merge rules).

Historical comments & round count — which issues were raised, which handled (cannot prove current commit passes).

CI, build, test results — which deterministic checks passed (cannot cover untested risks).

This is Context Engineering in practice: not longer context, but the right facts for the current judgment, with provenance and version awareness. The article separates model context (ephemeral), task state (round number, open items), and external facts (Git, CI, merge queue) — the latter two must survive context loss.

Long-term memory (recurring bug patterns) belongs in REVIEW.md, Skills, or lint rules — written back into the system — but the current PR must still be verified against the current diff. Security boundaries matter: private data, untrusted content, and outbound communication together enable prompt injection; isolation must be enforced in code, not just prompts.

How Opinions Become Evidence (Action & Evidence Flow)

A candidate issue (“possible race condition”) is not evidence. It must pass cross-validation, pin to file and line, become a PR comment, then a fix commit, then CI/re-review on that commit, then risk approval bound to that SHA, then merge-queue re-check on latest main. The chain:

Candidate issue
  │
  ▼
Cross-validation → file & line → PR comment
                      │
                      ▼
Fix commit → CI / re-review → risk approval
                      │
                      ▼
              Merge queue / release

Semantic judgments (drift from goal, root-cause fix, duplicate comment) stay with the model; deterministic checks (file exists, tests pass, comment resolved, approval binds to SHA, required checks green) stay in code. The article proposes a minimal run record:

task_id, run_id, input_sha, finding_id, output_sha, verified_sha

— enabling traceability of why an opinion appeared, whether the fix addressed it, and which later commit invalidated earlier conclusions.

Three-Layer System: Separate Judgment, Control, Execution

Decision Layer: Propose the Next Step

Composed of model, instructions, and per-round context. It excels at understanding PR intent, reading code relationships, spotting semantic mismatches, and adjusting next steps from new results. But its outputs are proposals — whether a comment was posted, code changed, or tests passed must be confirmed externally. Keeping the model inside this boundary plays to its strengths (fuzzy goals, semantic understanding, scene selection) while delegating versioning, permissions, and deterministic constraints to software.

Control Layer: Hold the Scene

Typically inside a Harness or Agent Runtime. It assembles context, calls the model, parses proposals, schedules tools, and persists round number, budget, timeouts, approvals, cancellation, and recovery state. For the 50-round PR, the control layer should track:

Starting commit of this round.

Which opinions were emitted, which resolved.

Whether we are scanning full repo or only new diff.

Round count and human-escalation trigger.

Current risk level and required approvals.

Which approvals still cover the current commit.

If this state lives only in conversation history, a restart loses it; worse, the model may treat last round’s conclusions as current facts. A state machine (running, awaiting checks, awaiting human, passed, needs redo, cancelled) gives each scene a home and allows an explicit “uncertain” state instead of forcing a false success/failure.

Execution Layer: Leave Verifiable Facts

Includes Git, CI, PR platform, merge queue, filesystem, terminal, browser. Its hallmark: results are re-readable. “I fixed it” means nothing without a commit; “tests pass” means nothing without CI logs; “approved” means nothing without branch protection, risk policy, and current approvals aligning. Anthropic’s merge queue re-runs checks on latest main — two PRs passing separately doesn’t guarantee they pass together. Features roll out via flags → latest → stable; flags and rollback contain blast radius.

An execution call must return at minimum: input version targeted, external object created, current status, and where to query next. For irreversible actions (refunds, coupons, deletions) the bar is higher: idempotency keys, audit trails, and an UNKNOWN state on timeout — never silently retry.

Mapping Buzzwords to the Pipeline

Tool : callable capability (read file, run test, post comment) with defined I/O and failure modes; callability ≠ authorization.

Skill : reusable method for a class of work (bug finding, diff simplification, e2e check); improves judgment quality but does not persist PR state.

Workflow : fixed, known steps (required CI, security comment blocks merge, high-risk paths need N approvals) — no need to re-decide each run.

Graph : expresses dependencies, parallelism, recovery nodes; but non-idempotent nodes, non-persistent state, or unclear stop conditions just make the runaway loop prettier.

Memory / State / Evidence : Memory = reusable experience for next time; State = where this PR stands; Evidence = why this commit can merge. They may share infrastructure but must not collapse into one ever-growing chat log.

Why Multi-Agent Works Here

Claude Code’s review suits multiple agents because:

Search tasks are truly parallelizable — different agents read for correctness, security, simplification, e2e behavior without contending for shared state.

Results are easily cross-validated — a finding lands on file, line, diff; another agent can confirm or reject; duplicates merge; no hard-to-undo side effects like payments.

When tasks become strongly sequential, shared-state, high-side-effect (order lookup → duplicate payment check → refund → notify), splitting agents adds handoff cost without automatic reliability. A single agent with well-bounded tools is often easier to debug. Split only when subtasks are genuinely parallel, context/permissions must be isolated, or one agent’s tool/instruction set grows too large.

Delegation must pass goal, scope, input version, allowed tools, budget, output format, acceptance criteria — not just a natural-language prompt. The parent verifies artifacts and receipts, not a child’s “done” claim.

Production Is Where the Hard Problems Live

A demo looks done when the model reads code and comments. Production shifts difficulty outside the model: knowing which input version each round used, persisting task/run state, constraining tool permissions, gating high-risk actions with approvals, handling timeouts/cancellations, and accepting results via external evidence. Anthropic feeds historical incidents and fixes into expert-verified eval sets; every prompt, tool, or model change re-runs them. They also watch how humans handle comments (fix, dismiss as false positive, accept as intended, mark nit) — otherwise the system learns only to “report more,” not “report better.”

This matches the Self-Harness principle: without input version, config version, execution trace, and result evidence, “self-improvement” reduces to subjective feeling.

Five questions every production agent must answer:

What did each round see? → context sources, selection method, input version.

Where is the task? → task/run state, round, checkpoints.

Why was this action allowed? → identity, permissions, policy, approvals.

Why is the result trustworthy? → external receipts, authoritative re-read, acceptance evidence.

How does the next version improve? → failure taxonomy, eval sets, regression results.

These are not “intelligent” problems, but they decide whether an agent graduates from a flashy demo to a system a team trusts long-term.

Reading Architecture Through a Real Task

Returning to the 50-round PR: the reviewer and fixer weren’t broken — they kept working. The missing piece was task-layer boundaries: what new information a round must bring, how to deduplicate old opinions, which findings belong to this change, when to escalate or pivot, and what external evidence declares completion. Once those exist, the control loop stops spinning, the two data flows connect, and the three layers each own a clear responsibility.

When evaluating an agent architecture diagram, the author no longer counts models, agents, or vector stores. Instead, they walk a real task end-to-end:

What did it get on round one? After acting, how did the scene change? Who confirmed the change? Where does it resume after a crash? If new actions keep appearing, what makes the system decide to stop?

Only when every question has a concrete answer do Model, Tool, Skill, Workflow, Graph, Memory fall into their proper places. Unassigned responsibilities will resurface at round 50, a timeout, or an expired approval.