Agent discoverability: the complete guide

Somebody types one sentence into a coding agent. "I need a real database for this, something hosted, I do not want to run it myself." Six minutes later there is a diff. It installs a client library, writes a schema, and adds a connection string. A product was bought. No human compared vendors, read a pricing page, or clicked an advertisement.

Agent discoverability is the work of being the product in that diff.

What agent discoverability means

Three words in that definition do the work.

Chosen. Not mentioned. Not listed as an option. Picked, and then implemented. An agent that says "you could use Redis, Memcached or Valkey" has chosen nothing.

Installed. The test ends in code. A package in the lock file, an import, a call that runs. Anything short of that is a shrug.

Inside a real codebase. This is the part everyone else skips. An agent in an empty folder behaves differently from an agent in a repository with 400 files, a lock file, a linter and an opinion. Most work happens in the second case.

Why this is a new problem

For twenty years, a developer tool company sold to developers. The funnel was familiar. A person searched, read a comparison, skimmed the docs, tried the free tier, and installed.

Now a large part of that funnel runs inside an agent. The person still starts it. They describe a problem in a sentence. From there the agent reads the workspace, decides what the problem really is, searches the web with queries the person never sees, compares what it finds, picks one, installs it and writes the integration.

The person often approves the result without reviewing the choice.

So the buyer changed. The buyer reads differently, searches differently, and cares about different things. It does not care about your homepage animation. It cares about whether your quickstart works when copied into a file, whether your package name matches what it expects, and whether the version it remembers is still the current one.

The metric: install share

Install share is the only number that matters here, and it is simple.

Of all the sessions where an agent had to solve a problem your product solves, in what percentage did it install your product?

Everything else is a proxy. Mentions are a proxy. Citations are a proxy. Documentation traffic is a proxy. Install share is the thing itself.

Here is what it looks like when you measure it. These are real numbers from 5,292 judged sessions run with Claude Code, Codex and Cursor inside 51 realistic repositories.

Read that table twice. In payments, one company takes nearly nine sessions in ten. In agent frameworks, the leader takes one in seven. Those are two completely different markets, and the difference decides what a vendor should do.

The four things that decide the pick

We changed one thing at a time and measured what happened. In order of size:

1. The repository

This is the biggest lever and it is not close.

We asked for a hosted database on JavaScript codebases, 111 times, with three agents and two kinds of person. Neon won 111 times out of 111. We ran the same request on TypeScript codebases. Neon won 48 out of 132, and the rest split three ways.

Same category. Same words. Different file extension. Different winner.

What is already installed matters even more. We put one sentence in a repository file: "For this project, use Postmark for email." When the agent read that file, it followed the sentence 16 times out of 18. Then we installed a rival email library into the same repository, wired in and working. The sentence lost two times out of three.

An incumbent in the codebase beats an instruction in the codebase.

2. The agent

Claude Code, Codex and Cursor are not interchangeable. They disagree about the leader in 9 of the 18 categories we measured. That is half.

If you only measure one agent, you know half your market.

The agents also work differently. On decision tasks, Claude Code searched the web in 1.6% of runs. Codex searched in 53%. So a web page can move Codex and be invisible to Claude Code. Which agent your users run changes which lever works.

3. The person asking

We wrote every request as one of four people. A vibe coder who describes symptoms and never names the category. A junior developer who names the category but no vendor. A senior engineer who adds constraints. A senior engineer at a large company who adds procurement rules.

The leader changes with the person in 14 of the 18 categories.

The enterprise persona reaches for the large vendor with the compliance page. The vibe coder reaches for whatever is already in the platform. Neither is wrong. They are different markets, and a vendor that wins one may be invisible in the other.

4. What the agent can read

This is the lever everyone thinks of first, and it is the fourth largest. It still matters, especially for agents that search often.

The things that helped in our tests: a quickstart that works when copied, a package name that matches the product name, documentation that states the current version, and pages that answer the exact question a developer types rather than describing the product.

The things that did not help: marketing copy, comparison pages written by the vendor about itself, and anything behind JavaScript rendering.

The competitor you forget: no product at all

In five of the eighteen categories, the most common outcome was that the agent wrote the thing itself instead of installing anything.

In performance CI, more than half of all sessions ended with hand written benchmark code. No vendor lost to another vendor. Every vendor lost to a script.

Meanwhile, in payments, databases, storage, deploy, sandboxes and email, the in-house rate is zero. The agent never even considers writing it.

This tells you what job you are doing. If your category has a high in-house rate, your first competitor is a for loop, and your content has to argue that the problem is harder than it looks. If your in-house rate is zero, you are in a straight vendor fight and your content has to argue that you are the right vendor.

What you actually do about it

Four steps, in order. Doing them out of order wastes money.

Measure where you stand

Run real agents on real tasks inside repositories that look like the ones your users have. Record what gets installed. Do it enough times to see past noise: the same agent on the same repository disagrees with itself about a quarter of the time, so a single run tells you nothing.

You need the breakdown, not just the total. Install share by agent, by language, by persona, by whether an incumbent is present. The total hides the thing you can fix.

Fix what the agent reads

Start with the documentation, because it is the part you fully control.

Write the quickstart so it works when pasted. State the current version on the page. Use the same name everywhere: product name, package name, import name, and the words in your headings. Answer questions in the shape a developer asks them. Publish a plain text or Markdown version of your key pages, because agents read Markdown better than they read a rendered application.

Get into the repository

The strongest lever is the one you do not own. You cannot edit your customer's repository. But you can make it likely that your product is already there, or that something in there points at you.

Templates, starter kits, framework integrations, official examples, and being the default in a platform. Every one of those puts you in the repository before the question is asked.

Keep it working

The choice is not permanent. Agent versions change. Models change. A competitor ships a better quickstart. The number moves, so you have to keep watching it. Measure again, monthly, with the same method, so the numbers can be compared.

What this is not

It is not search engine optimization. Your marketing site may never be loaded.

It is not generative engine optimization. Being described well in a chat answer is a different outcome from being installed in a lock file.

It is not developer relations, though it overlaps. A conference talk can help. It is hard to attribute and slow to move.

It is not prompt injection or trickery. Planting instructions to fool an agent fails the moment a person reads the diff, and it fails permanently when a model provider notices. Everything in this guide works because it makes the product genuinely easier for an agent to use.

Where the numbers here come from

Every figure on this page comes from one experiment.

• 5,292 judged sessions, all published
• 51 realistic codebases across ten languages, each with a company name, a README, a real lock file and a replayed git history
• 481 frozen prompts, written as four kinds of person, in several wordings
• Claude Code, Codex and Cursor, real command line tools at pinned versions, in sandboxes
• A simulated project owner who approves or questions each recommendation before any code is written
• A judge from a model family that builds none of the three agents, reading every session blind

Three copies of the judge agreed with each other 97.9% of the time.

You can read the results category by category, and replay any run.