Agent tooling: read latency rarely matters, concurrency does

When turning data-access benchmarks into agent iteration speed, model a session as steps of (LLM think time + tool call latency). Per-step model time is seconds, so a tool that is 4x faster at millisecond reads changes one agent's session time by about 1%. What moves wall time is how many agents a machine can run at once: wall ≈ ceil(total agents / per-machine capacity) × session time, so a capacity gap turns directly into extra batches or extra machines. Report capacity under a realistic mix of files and requests as the headline. Single-agent latency matters only for requests that are slow in absolute terms (e.g. full scans taking seconds).