Record the MCP-on-winner-only rule

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: barretodavid

AGENTS.md

@@ -325,6 +325,15 @@ uv run python -m bench.runner --models qwen/qwen3.6-27b@low,qwen/qwen3.6-27b@hig
   (the runner treats an error row as incomplete, so pointing it at the same `--out` retries
   exactly those), then count runs per task before merging. The fix is cheap; noticing is the
   hard part, since the batch reports a clean 100% solve rate on what survived.
+- **The MCP condition is benchmarked on ONE tier: the baseline winner.** Settle the
+  baseline bracket first (top-ups included), then run `mcp` for that tier alone. Sweeping
+  the documentation condition across the whole ladder multiplies the slowest, most
+  contention-sensitive batch by the ladder size for data the report does not need.
+  Stated 2026-08-25, after GLM 5.3's mcp sweep launched across all three tiers on the
+  strength of the multi-tier mcp rows already in main.jsonl; those rows predate the rule
+  and stay as recorded, so do not infer the protocol from the dataset's shape. That
+  sweep was 57 of 78 runs in when caught and was allowed to finish rather than strand
+  the spend.
 - **Lower it for MCP-condition batches**, 6 to 8: documentation lookups queue on a single
   local backend, and unlike retry backoff that wait **is** counted, because `load_runs()`
   applies the budget to `llm_time_s + assist_time_s`. A crowded backend manufactures both