What is agent experience? How coding agents pick dev tools

A developer opens a terminal and types: "Which tool should I use for this, and set it up for me." Nobody visits your pricing page. Nobody watches your demo. A coding agent searches, reads a few docs, runs a command and reports back.

That is the situation behind agent experience: how well a coding agent finds, chooses and finishes a task with your product. It is a different thing from developer experience, and a different thing from AI search visibility, though it overlaps with both.

This post defines the term, then does something most posts on the topic skip: it shows our own results. On 3 November 2026 we ran four tasks with an OpenAI agent against Revnu itself. One recommended us first. Two did not mention us. One configured our MCP server and then stopped at a sign-in. We state the method, the stop and the limits plainly, because a scorecard without limits is marketing. It makes no ranking promises and no causal claims.

What agent experience means (and what it is not)

Agent experience is the full journey a coding agent takes with your product: finding it, deciding it fits, reading how to set it up, running the setup and finishing the task a human asked for. If any link breaks, the human never sees your product work.

It is not developer experience with a new label. A developer skims, guesses and tolerates a confusing docs page because they already want your product. An agent follows what is written, tries the URLs and commands it can find, and treats a wrong guess as a dead end or a detour. Docs that rely on a human's patience fail differently for an agent.

It is also not the same as AI visibility. Visibility asks whether you get named when someone asks a chatbot a question. Agent experience asks what happens when an agent is handed a task and has to act. You can be named and still fail at setup. You can have clean setup docs and never be named.

And it is not a ranking. Nobody can promise that an agent will pick you. What you control is whether a competent agent that does reach you can complete the job. That is testable, and it is the part worth working on.

We built this testing into Revnu because we wanted to know the answer for our own product. The feature page is at revnu.com/features/agent-experience, and the docs are at revnu.com/docs/agent-experience.

How a coding agent ends up choosing a dev tool

An agent has no preference history with you. It builds a short list from whatever it can reach in the moment, and what it can reach depends on its setup.

With web access, it searches and reads pages. Without it, it relies on what it absorbed in training and on files already in the project. That single difference changed our results, as the scorecard below shows. The same kind of task got a different answer depending on whether the agent could browse.

Then it filters. The agent looks for a clear statement of what the product does, a setup path it can execute from a terminal, and some sign the integration is real rather than a marketing claim. A product that explains itself in plain text, with a command to run, is easier to pick than one that requires a sales call or a screenshot walkthrough.

Finally it acts, and this is where choice becomes completion. An agent that picks your tool but cannot finish setup has handed the developer a worse outcome than not choosing you at all.

Founders and product leads should stop thinking only about the page a human lands on. Think about the three or four files and commands an agent will touch, and whether they agree with each other. Where they disagree, the agent follows the wrong one, and you will not see it happen.

Discovery surfaces: docs, llms.txt, MCP registry and what each can and cannot do

Four surfaces matter, and each has a ceiling.

Product docs. The most important surface, because they are what an agent reads to finish a task. They can carry exact commands and expected output. They cannot get an agent to your site in the first place.

llms.txt. A plain-text file at a predictable path that points agents to the pages worth reading. We publish revnu.com/llms.txt and a narrower revnu.com/mcp/llms.txt. Treat it as a discoverability convention, not a guarantee. We cannot say every agent reads it, and our own test showed an agent reading it and still taking detours.

The MCP registry. The official registry provides a place to discover MCP servers, listing entries with their name and package transport (Model Context Protocol). Revnu's server is listed there as com.revnu/revnu, with a Streamable HTTP endpoint at revnu.com/api/mcp and OAuth. A listing makes you findable by machines that check the registry. It does not guarantee discovery or selection.

A setup page. One canonical page that states the install command, the endpoint and the auth step. Ours is revnu.com/setup, with MCP specifics at revnu.com/docs/mcp.

None of these is a ranking lever. Together they reduce the number of ways an agent can get lost. That is the honest claim.

Our own test, 3 November 2026: four tasks, one OpenAI agent, what happened

Here is Revnu's own scorecard from 3 November 2026. Method first.

We gave four fresh tasks to an OpenAI agent. Each task had its own brief and its own conditions. Every step was recorded: the searches, the pages read, the commands run and the outputs. We mean observable actions, not the agent's private reasoning.

Task 1, setup, web enabled. The agent was asked to connect to Revnu's MCP server through the Claude CLI. It found the right docs after detours to wrong domains. It read llms.txt, setup.md, the MCP llms.txt, the MCP docs page and the Claude CLI help. It then ran claude mcp add --transport http --scope local revnu https://revnu.com/api/mcp, followed by claude mcp get revnu. The configuration succeeded. The actual output read Status: ! Needs authentication.

The agent stopped at the sign-in. OAuth and any authenticated use, including the review_list call, remain untested. We will not say it passed end to end, because it did not get there.

Task 2, broader growth discovery, web enabled. The agent recommended Revnu first.

Task 3, the same kind of discovery, no web. Revnu was not mentioned.

Task 4, outbound only, web enabled. Revnu was not mentioned.

These are four small tasks with different briefs. They are not a controlled A/B test, not a representative recommendation rate and not an endorsement from any agent.

What the setup task taught us: domain consistency and canonical setup docs

The setup task did not fail because documentation was missing. Canonical docs existed and the agent eventually found them. It lost time on the way, and the detours are the useful part.

The agent tried guessed .dev URLs that are not our domain. It also guessed a /docs/mcp/llms.txt path that does not exist. Both were reasonable guesses for an agent that was pattern-matching on how other products lay out their docs. Both were dead ends.

Two fixes follow, and neither is exotic.

Keep one domain. Every doc, install snippet, registry entry and README should point to the same host. If your brand has a second domain, a legacy docs site or a package page that links elsewhere, an agent will wander onto it. Humans forgive that. Agents burn steps on it, and a long enough detour ends the task.

Publish one canonical setup page and link to it from everywhere. An agent that lands on any of your surfaces should reach the install command in one hop. Ours exists at revnu.com/setup, and we are tightening how the other files point to it.

The third lesson is about the stop itself. Many tools hit an auth wall, and an agent cannot complete a browser sign-in for a person. Say so in your docs. State what the status will read after configuration, and what the human needs to do next. An agent that knows Needs authentication is the expected state can report it accurately instead of treating it as a failure. Our MCP docs are at revnu.com/docs/mcp.

Scheduled answer monitoring vs task-based agent tests, and what analytics can see

Two kinds of measurement get blurred together, and they answer different questions.

Scheduled answer monitoring asks a set of questions on a schedule and records which products the answers name. It tells you whether you appear when someone asks. On Revnu, daily coding-agent answers are part of Managed. It is a visibility measure.

Task-based agent tests hand an agent a job and record every step to completion or failure. They tell you whether the journey works. Revnu runs these on every plan, including Pro at $99/month, with each step recorded, a scorecard, suggested fixes and weekly re-checks. Managed is custom-priced and adds a dedicated growth engineer, but the tests themselves are not a Managed-only feature.

You need both because they fail independently. Our own scorecard shows it: one task recommended us and another did not, while the setup task found us and then stopped at sign-in.

What can your analytics see? More than people assume, and less than they hope. Analytics can record arrivals on your site, requests to files like llms.txt, and use of any endpoint you instrument. That is real signal. What it usually cannot do is explain why an agent chose or skipped you, or show a journey that failed before the agent ever reached your domain. A missing visit is not evidence of anything on its own.

So use analytics for what happened on your side, and tests for what happens on theirs.

A short checklist to test your own agent experience, and the limits of our tests

You can run a rough version of this today.

1. Write four tasks. One broad discovery task, one narrow one in your niche, one setup task and one that needs your product's core action.

2. Run each with and without web access. Our results differed on exactly this.

3. Record observable steps. Pages read, commands run, outputs, and the exact point of failure. Skip anything that depends on guessing the agent's reasoning.

4. Find every wrong-domain and wrong-path detour. Fix the domain or add a pointer.

5. Name your auth stop. Document the expected status and the human step.

6. Check that your canonical files agree. Setup page, llms.txt, README, registry entry.

7. Re-run weekly. Docs drift, and so do agents.

Now the limits of what we did. Our tests focus on specific agent environments. They do not run Codex or OpenCode CLIs, and they do not run personal agents. The 3 November setup task was an OpenAI agent operating the Claude CLI, so it is not a native Claude recommendation test. Documented support for installing a client does not mean that client's own recommendations or authenticated tasks were tested. Four tasks cannot tell you a recommendation percentage.

And we did not test past the sign-in. That part is still open.

Conclusion

Agent experience is testable, and most teams have never tested it. Run the checklist above against your own product this week, with and without web access, and write down exactly where the agent stops. You will find a wrong domain, a missing pointer or an auth step nobody documented.

Revnu runs these agent tests on every plan, including Pro at $99/month: every step recorded, a scorecard, fixes and weekly re-checks, with daily coding-agent answers on Managed. Start from revnu.com/features/agent-experience, read the method in the docs, and fix the first detour before you write another line of marketing copy. Our bet: the teams that find those detours early will be the ones agents can finish a job with.