Skip to content

review agent: reduce wall-clock time (currently 8-19 min) #836

Description

@rh-hemartin

Problem

Review agent runs take 8-19 minutes wall-clock. Analyzed 10 consecutive successful runs from 2026-08-17 to identify where time is spent.

Duration distribution (10 runs)

Run PR Duration Subagents Slowest subagent Verdict
32017487774 fullsend#6279 8m 32s 5 47s (opus) comment
32018017917 fullsend#6281 11m 06s 5 55s (sonnet) approve
32020629436 fullsend#6281 11m 48s 5 1m28s (opus) approve
32018932422 fullsend#6283 14m 24s 5 1m08s (opus) request-changes
32027365506 fullsend#6285 14m 47s 7 2m44s (opus) request-changes
32021432068 fullsend#6223 14m 58s 5 1m46s (opus) request-changes
32020606669 agents#646 15m 02s 7 2m04s (opus) comment
32019841106 fullsend#6223 15m 28s 5 1m24s (opus) comment
32017698174 fullsend#6223 16m 44s 6 2m49s (sonnet) comment
32017692283 agents#211 19m 00s 5 4m19s (opus, 133 msgs) request-changes

Where the time goes

Phase Typical time Nature
Orchestrator setup (env vars, AGENTS.md, prior review, PR metadata, diff fetch, file content fetch, sub-agent file reads, context composition) 5-8 min Sequential LLM inference
Dimension subagents (parallel, wall-clock = slowest) 0.5-4.3 min Parallel, model-dependent
Challenger subagent (sequential) 1-3 min Sequential, after dimensions
Output writing + validation 0.5-2 min Sequential, includes retry on missing dir

The orchestrator overhead is the single largest cost -- it exceeds even the slowest subagent in most runs. The LLM spends most of this time doing deterministic work that does not require reasoning.

Potential solutions

A. Pre-create output directory (trivial, saves 1-2 min on ~40% of runs)

4 of 10 runs failed writing to /sandbox/workspace/output/agent-result.json because the directory did not exist. The agent then debugged, created it, and retried.

Fix: mkdir -p "$FULLSEND_OUTPUT_DIR" in pre-review.sh. Already done in feat/2207-effort-gating branch.

B. Move orchestrator setup to pre-script (saves 3-5 min per run)

The orchestrator (LLM) spends most of its setup time doing deterministic work:

  • Fetching PR metadata via gh api (steps 1-2)
  • Fetching the diff via gh pr diff
  • Fetching file contents via gh api per file (step 2b) -- the worst offender; a loop of API calls through the LLM
  • Computing the changed-since-prior file set (step 2a)
  • Reading sub-agent definition files from disk (one Read per sub-agent)

All of this could run in pre-review.sh and be written to a structured file (e.g., /sandbox/workspace/review-context.json) that the LLM reads in a single pass. The LLM would only do the parts that need judgment: triage classification (steps 3b-3e) and context package composition.

This is the highest-impact change. A typical run would drop from 11-19 min to 7-12 min.

C. Apply scope constraints consistently (saves 1-3 min on subagent wall-clock)

The two fastest runs used explicit scope constraints (small: <=15 tool calls) on subagents. The slowest run had an unconstrained subagent that ran 133 messages over 4m19s reading 46 files. The skill defines scope constraints (step 3e) but the orchestrator applies them inconsistently. Making classification stickier -- e.g., always applying small to re-review dimensions without prior findings -- would cap tail latency.

D. Batch env var reads (saves ~30-60s)

Every run opens with 2-4 sequential Bash calls to read individual env vars. A single call that dumps all vars at once saves 2-3 LLM round-trips.

E. Skip challenger for clean re-reviews (saves 1-3 min on qualifying runs)

When dimension subagents produce zero or only low/info findings, the challenger has nothing to debunk. Three runs produced approve/comment-only outcomes with low-severity findings. Skipping the challenger for these would save 1-3 min. Tradeoff: the challenger occasionally catches false positives, so this is quality vs. speed.

F. Inline sub-agent definitions (saves ~1 min)

The orchestrator reads 5-7 sub-agent markdown files sequentially from disk during context assembly. These files are static and known at dispatch time. Including them in the skill template or a pre-computed bundle would eliminate 5-7 Read round-trips.

Recommendation

Start with A (done) and B (biggest impact). C and D are good follow-ups. E requires a judgment call on quality tradeoffs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions