When you assign a coding agent a task, it does far more than edit files. It installs packages, runs shell commands, and pulls in utilities to finish the job. A study covering roughly 17,000 agent runs asked a concrete question: when Claude, Codex, and Cursor are left to decide for themselves, which tools do they actually reach for? The answer is a data-backed picture of agent behavior instead of a vendor's description of it.
The headline for builders is that agents converge on a fairly predictable stack of standard command-line tooling — the Unix utilities, package managers, and search tools that experienced developers use by reflex. This matters because the tools an agent assumes exist directly determine how well it runs. If your sandbox or CI container lacks a utility the model expects, you get failed runs, wasted tokens, and retry loops.
The differences between agents are where it gets useful. Each product ships its own defaults and habits, so swapping one agent for another is not a neutral change — it can shift what your environment needs to support. If you standardize on a base image for agent execution, this kind of data tells you exactly what to preinstall so the agent spends its budget solving the problem rather than bootstrapping its own toolkit.
What to do with it: audit the commands your agents invoke in your own logs, then bake the common ones into your execution environment up front. Preinstalling frequently requested CLIs cuts latency and failure rates, and it doubles as a security control — you decide what's available instead of letting the agent install arbitrary packages mid-run.
The larger point is that agent performance is as much about environment design as prompt design. Measuring real behavior across thousands of runs beats guessing, and it's repeatable: instrument your sessions, tally what gets called, and provision accordingly. The full breakdown, including per-agent rankings, is worth reading if you operate agents at any meaningful scale.