16,893 Sessions, Three Coding Agents, 42% Agreement: Your Procurement Is Whichever Agent Was Open

Armature ran 16,893 coding-agent sessions across 75 repositories, 1,163 prompt variations and three agents (Claude Code, Codex, Cursor), then kept 5,292 sessions on 51 codebases and 18 sectors as valid. The sectors ranged from payments and databases to deploy and observability. The question was which vendor each agent would reach for when the task needed one. All three agents picked the same tool in only 42% of the cells.

Take one cell. Asked to add voice, Claude Code went to Twilio, Codex to the OpenAI Realtime API, Cursor to Vapi. Same task, same class of repository, three vendor relationships. Whoever opened the terminal decided which one your company would be running.

We argued in February that agents have opinions, based on amplifying.ai’s 2,430 Claude-only responses. That study showed one agent has strong defaults. This one adds three agents instead of one, repositories with real lockfiles instead of bare prompts, and a measured disagreement rate between agents. The 42% is what turns “agents have opinions” into a procurement problem.

The pick is conditioned on your repository

Language decided the vendor for the same email ask. Per Armature: Resend won on TypeScript (55 of 89 runs), SendGrid on Python (22 of 24), Postmark on Go (20 of 24), Azure Communication Services on Java (22 of 23). One prompt, four winners, and the deciding variable was the repository’s language.

For anyone with a polyglot estate the consequence is direct. Go services and TypeScript services would likely land on different email providers unless something stops them. Nobody chose that. The agent read the repository and the vendor followed the language, whether from priors or from what a language-scoped search returned.

The pick is conditioned on the agent’s search habits

The three agents research differently, and the method shapes the answer. Codex used web search in 94% of sessions, and in nine queries out of ten it used operators like site:. Claude Code relied mostly on its priors and searched the web in about 30% of cases. Cursor based its decision on the web in two thirds of sessions.

Build-versus-buy split along the same lines. Claude Code built in-house almost twice as often as Codex and Cursor (19% against 10%). Across the leaderboard, in-house won about 13% of the time overall, and about 52% of runs for performance in CI.

An agent that searches is exposed to whatever the web says today. An agent that leans on priors is exposed to whatever the web said when the model was trained. Neither is exposed to your procurement policy, because that policy is neither on the web nor in the weights.

Mentioned 139 times, picked zero

The study separates mentions from selections, and the distance between the two is the most useful finding for anyone who sells developer tools or buys them.

PayPal was cited 139 times and never picked. Stripe won 124 of those 139 sessions. LangChain was the most cited framework, 194 mentions, and was picked 4 times. Netlify was mentioned 152 times and picked 6 times.

The agent surveys the market, then converges. On the leaderboard: Stripe 88.4% in payments, Neon 66.3% in databases, AWS 61.9% in cloud, E2B 42.5% in agent sandboxes, Vercel 41.5% in deploy with Render at 34.4%, Sentry 36.9% in observability, Langfuse 33.7% in LLM evals with in-house at 29.2%, WorkOS AuthKit 26.4% in auth. Payments is nearly settled. Auth and observability are still contested, and a contested category is where any conditioning, agent or repository, has the most room to move the pick.

The pricing page is an attack surface

Agents read pricing pages and act on the wording. Armature reports that Mailgun regularly lost to Postmark when agents read “1-day retention” on its free plan. Of the 5,292 sessions (Armature rounds to 5.3k), 388 mentioned platform management overhead and 195 mentioned costs.

Seen from the vendor side: in the study, a sentence on a free-tier page changed which vendor the agent selected, across many sessions, with no human in the loop. Armature states what this means for its own business: “Armature sells growth services to dev tools. This study is part of our broader work on how to influence coding agents choices and get products picked.” The company that ran the study sells the ability to move these numbers. That is a conflict of interest and it should shape how you read the report. The data still stands, and the disclosure confirms the thesis from a direction no reader can dismiss: an industry already sells influence over what your agent installs.

We described capability as commodity and orchestration as the moat. The vendor list is now part of the orchestration. If your scaffold does not name the approved vendors, the agent’s priors name them for you, and someone is paying to shape those priors.

What the study can and cannot support

The methodology deserves a plain statement. Repositories were synthetic: fake company names, fake git histories, fake API keys, real lockfiles, spread across ten languages. Sessions were judged by an LLM, Gemini 3.7 Flash. Prose and the leaderboard widget disagree by fractions of a point in places (S3 “45%” against 45.6%), so the widget values are the ones used here.

Synthetic repositories mean the agents saw plausible codebases, not your codebase with your existing vendor contracts already in the dependencies. An LLM judge means the selection labels carry that model’s error rate. The central finding survives both caveats: three agents, given the same task, diverge often. The precise percentages are a different matter, and no budget should be built on them.

The study does not say which agent chooses best. There is no ground truth for “best vendor” in it, and we are not adding one. Vercel’s own figure, cited by Armature, that over 30% of deployments were initiated by coding agents, up 1000% from six months earlier, comes from a vendor’s own blog. We note it as context and nothing more.

Do this now

Write the vendor allowlist and put it where the agent reads it. Concretely:

1. For each capability category your agents touch (email, payments, database, deploy, auth, observability, LLM evals), name the approved vendor or vendors. Where you already have a contract, that is the list. Where you do not, decide now, because the agent will decide otherwise.
2. Put the list in the repository-level instruction file every agent you run reads (CLAUDE.md, AGENTS.md, Cursor rules). Make the same list appear in every repository regardless of language. Language-conditioned drift is the specific failure the data shows.
3. Add a dependency gate in CI that fails on a new SDK or package from an unapproved vendor. The instruction file steers. The gate enforces.
4. Log which agent opened each pull request that added a dependency. Without that record, you cannot audit the 42% inside your own estate.
5. Treat a vendor’s pricing-page wording as untrusted input to your procurement, the same way you treat a supply-chain dependency. We made the supply-chain case earlier. The agent’s vendor choice now belongs on that list.

Three agents, one task, 42% agreement. The number will move as models and vendors adapt to each other. Whether it moves your procurement depends on whether you wrote the list first.

---

This analysis synthesizes Which Tools Do Claude Code, Codex, and Cursor Choose? (Armature, Inc., September 2026).

Victorino Group helps engineering teams turn vendor policy into agent-readable allowlists and CI gates before the agents decide for them. Let’s talk.