db-access-review-subagent-needs-explicit-probe-budget

A review subagent with live-DB access needs an explicit probe budget

Problem

You dispatch a general-purpose subagent to review a PR or verify findings, and it has live database / cloud / Bash access. Unprompted, it does the thorough thing: re-derives every claim from scratch, running expensive exploratory queries (full-window joins, multi-date sweeps, dry-runs). Two failure modes follow:

1. It runs very long (20–40+ min of wall time on heavy probes), far past what the review needs.
2. It can socket-close mid-run. The Agent tool returns API Error: The socket connection was closed unexpectedly with a non-zero tool_uses count but no final assistant message — so the agent did real work (11, 20 tool calls) but its verdict was never delivered. The output is lost, and it is not resumable from the orchestrator unless a SendMessage/continue tool is available (often it is not). You've burned the tokens and the wall-clock for nothing.

The root cause is that an unbounded reviewer treats "review this change" as "independently re-establish the entire ground truth," which is exactly the slow, fragile thing — when the orchestrator has usually ALREADY established that ground truth and just needs a second pair of eyes on the diff.

Context / Trigger Conditions

• About to dispatch a code-review / verification / research agent with BigQuery / gcloud / psql / Bash.
• An Agent result shows API Error: The socket connection was closed unexpectedly plus tool_uses: N (>0), subagent_tokens: 0, and no Strengths/Issues/Assessment in the output.
• A dispatched reviewer has no return after ~20–30 min.
• You (orchestrator) already ran the expensive live probes and confirmed the numbers in the PR body.

Solution

Bound review/verify subagents explicitly in the dispatch prompt:

1. Hard budget: "Target under ~6 minutes, ≤8 tool calls." A reviewer with a budget self-limits to the high-value checks.
2. Forbid the expensive re-derivation: "Do NOT run BigQuery probes / multi-table joins over date ranges. I already verified — your job is the STATIC diff review + run only the fast unit test (pytest …)." Hand it the ground truth as given facts to sanity-check cheaply, not to reproduce.
3. Prefer several short bounded agents over one open-ended one — diversity of lens at low per-agent risk; if one socket-closes you still have the others.
4. On a socket-close: capture the returned agentId. If a SendMessage/continue tool exists, try resuming for just the verdict (no new probing). If not, re-dispatch a fresh bounded agent — do not assume the lost agent "basically finished."