How AI agents discover and choose software

An agent cannot browse a pricing page or email sales. It finds tools through retrieval and picks from what it can read, so the tools that get chosen are the ones a machine can evaluate without a human.

An AI agent does not shop for software the way a person does. It cannot skim a pricing page, sit through a demo, or email a sales rep and wait two days. It issues a query, reads whatever text comes back, and picks from the candidates it can actually evaluate. Everything about which tool gets chosen follows from that.

This matters more each month, because the agent is increasingly the one deciding. A developer asks Claude Code or Cursor to add error tracking, and the model names a product before the developer has opened a single tab. That name came from retrieval, not from brand memory.

#Selection happens in three moments

An agent has to clear three separate bars before your product is even a candidate. Failing any one of them removes you, and the bars are independent.

Find it. The agent runs a search through an API and gets back page text. If your product does not surface for the phrasing the agent used, nothing else about it matters. Note that the agent's query is usually a full sentence describing a task, not a keyword, so pages written to match a keyword often miss.

Understand it. The agent now has to work out what your API does and how it behaves, from documentation, without running anything. It needs request and response shapes, error semantics, and limits. Prose that reads well to a human but has no examples gives a parser nothing to work with.

Adopt it. The agent has to get a key and make a first successful call. A signup that requires a human, a sales call, or a manual approval ends the evaluation there. The agent moves to the next candidate, and it does not come back.

#Why agents keep naming the same handful of tools

Because the candidate set is small, and it is small for mechanical reasons rather than reputational ones.

We scored 404 developer tools on the signals that decide these three moments. As of September 2026, only 13% let an agent get credentials programmatically. Only 30% let you start without a sales call. Those two alone remove most of the market before quality is considered at all.

So the tools an agent recommends are not necessarily the best tools. They are the tools that survived being evaluated by a machine. That is a real distortion, and it is also an opening, because the bar to enter the surviving set is lower than the bar to win on product.

#What separates the survivors

Once a tool is adoptable, the differences that matter are the ones an agent hits at runtime rather than at signup.

The pattern in the data is stark. The visible work is done and the runtime work is not. 96% of scored tools publish an llms.txt file. 80% ship an MCP server. Both take days. Then: 5% document idempotency, 9% document retry behavior, 9% return rate-limit headers.

An agent that retries a failed request without idempotency can double-charge a customer. An agent that cannot read a rate-limit header backs off blindly or hammers you. These are the failures that end an integration after adoption, and almost nobody has addressed them. Which means they are also where a vendor separates itself fastest.

#What this means if you are choosing tools

Ask whether the agent doing the choosing could actually evaluate the option you are considering. If a tool cannot be signed up for or read without a human, an agent will not pick it, no matter how good it is. You may still want it. Just know you are making that call yourself, outside anything an agent can help with.

The inverse is also worth knowing. A tool an agent names confidently is not necessarily the best one. It is the one that was legible. Treat the recommendation as a shortlist filter, not a verdict.

#What this means if you sell a tool

Being chosen is a readability problem before it is a marketing problem. The order of work is: be retrievable for the task phrasing people actually use, be parseable in your documentation, be adoptable without a human, and then be safe to operate.

You can check where you stand on all 41 signals with the free audit, and the full scored dataset for 404 tools is public at The State of Agent-Readiness, including the endpoint behind it. We sell none of the tools in it.

Frequently asked

How do AI agents find software to use?

Through retrieval, not browsing. An agent issues a query to a search or registry API, reads the returned text, and ranks candidates from that text. It never sees a rendered page, so a tool that explains itself only in marketing layout or a sales call is invisible at the moment of selection.

Why do agents recommend the same few tools?

Because most tools cannot be evaluated by a machine. Across 404 scored developer tools in September 2026, only 13% let an agent obtain credentials programmatically and only 30% allow a start without a sales call. The candidate set shrinks to whatever an agent can read and try.

What makes a tool get picked by an agent?

Being readable at three moments: findable in retrieval, understandable from documentation a parser can use, and adoptable without a human in the loop. A tool that fails any one of the three drops out even when it is the better product.

Can I make my API more likely to be chosen by an agent?

Yes, and the leverage is in the rare signals. Documented idempotency (5% of tools), rate-limit headers (9%) and documented retries (9%) are where most tools fail, so they separate you more than another SDK does.