How to get AI coding agents to recommend your product
July 28, 2026 · Selectorate team · 5 min read
When a developer asks Claude Code, Cursor, or Codex to add payments or search or auth, the agent retrieves candidates, decides, and acts in one loop, with no human in the middle. Being chosen inside that loop is a funnel step, and it is one you can engineer. We covered why the shift happened and why agents optimize for finishability. This post is the playbook. Seven surfaces, in the order they decide runs.
1. Make your quickstart executable
The quickstart is the agent’s first plan. It copies your steps and runs them verbatim in a clean environment. Every step that assumes context breaks the run. A dashboard click, an environment variable introduced three pages later, a “configure as needed” aside. The agent hits the gap, improvises, and its improvisation is where you lose to a competitor whose steps simply ran.
The fix. Rewrite the quickstart as a top-to-bottom sequence of commands and code blocks that succeeds from an empty directory. Put the credential step first and make it explicit. Then delete every sentence that is between the agent and the next command.
2. Name and type your SDK for a reader that guesses
The agent writes calls against your SDK from memory and from whatever type definitions it can read. A method named process() invites a wrong guess about arguments, ordering, and side effects. A method named createCheckoutSession() with typed parameters gets called correctly on the first attempt, and first attempts are what agents ship.
The fix. Name every public method after the user’s task, export complete types, and keep one obvious way to do each job. Every alias and legacy signature you keep alive is another branch the agent can guess down.
priceId,
successUrl,
})
3. Write docs for a five-step budget
The agent does not read your docs. It retrieves one chunk and acts on it. A page that opens with architecture philosophy spends the agent’s budget before the first line of usable code. If the retrieved chunk lacks imports or setup, the agent stitches fragments from multiple pages, and stitched code fails in ways that end runs.
The fix. Lead every docs page with a complete standalone example that shows the imports, the initialization, the call, and the expected output. Concepts go below the code, for the humans.
4. Publish llms.txt
Before reading anything, the agent decides which pages to load. An llms.txt file is that decision made for it, a curated index at your domain root that routes the agent to the right page in one hop instead of three speculative fetches through your marketing nav.
The fix. Publish /llms.txt with links organized by task, one line of annotation each, pointing at clean markdown versions of your docs. Keep it current with releases. A stale index routes agents to answers that no longer compile.
5. Ship an MCP server with task-shaped tool descriptions
An MCP server moves you from “product the agent writes code against” to “product the agent operates directly.” When one is present, the agent matches the user’s intent against your tool names and descriptions and calls the winner. When one is absent, you compete on docs alone against products the agent can drive natively.
The fix. Ship the server, and write every tool description as a when-to-use statement rather than a summary of what it wraps. The failure modes past that point have their own post.
6. Write error messages as instructions
To an agent, your error message is the next prompt. 400: invalid request prompts a blind retry or an exit. region is required; valid values are us-east, eu-west prompts a corrected call and a completed task. Your error strings are the only documentation guaranteed to be in context at the moment of failure.
The fix. Make every client error name the field, state the constraint, and show the corrected form. Audit your top ten errors first. They sit on your highest-traffic failure paths.
7. Verify by watching an agent
Every surface above has one test. Watch a real coding agent try to finish a real task on your product, and read what happened. The first place it hesitates, guesses, or silently switches to a competitor is the top of your fix list, ranked by position in the run, because the earliest failure erases everything after it.
The catch is that one casual run in your own terminal is not that test. Agents are nondeterministic, so a single run is an anecdote, and a rate you can trust takes repeated trials per scenario with a confidence interval around the result. The trials need isolated environments, one fresh container each, because an agent that finds your SDK cached or your API key sitting in its environment is not making the decision your customer’s agent makes. The scenarios have to read the way customers actually prompt, with no vendor named and your own MCP server deliberately withheld, because the moment you name yourself you are measuring compliance instead of selection. Each agent needs its own harness, because every one of them ships different defaults, different permission models, and different frozen preferences, and they do not fail the same way. Even then a finished run is not yet evidence. Evidence is the deployed result of what the agent built actually running, plus the instrumented transcript that shows which docs pages it fetched, which searches it ran, which errors it hit, and where a competitor first entered its reasoning. And selection and execution are two different numbers that move independently, so they have to be scored separately, against named competitors.
The fix. Treat verification as an instrumented benchmark, not a spot check. Re-run the same scenario battery on every docs and SDK release and every major model update, the way you run CI, and track both rates over time. Models update, competitors ship, and selection rates drift while your analytics record nothing. A regression in the transcript is a regression in your funnel.
Our free audit is this benchmark, already built and already running. You get both rates with confidence intervals, a diagnosis of every loss, whether you were never considered or considered and rejected, which are different problems with different fixes, and a fix list ranked by impact, with each finding cited to the transcript of the run that produced it.