Developers used to Google their way to a new tool. Now a lot of them just ask an AI coding agent instead: "what should I use to deploy this?" or "compare X and Y for my use case."
If an agent doesn't mention your product during that conversation, you don't exist for that developer, no matter how good the product is.
To show you what this looks like in practice, we ran a real agent experience audit against a real company: Release.com, a deployment platform that recently repositioned itself as a PaaS competitor to Vercel and Heroku. That kind of repositioning makes it a good test case. An agent's training data and cached knowledge may still reflect the old positioning, so this is really a test of whether Release has done the work needed to get agents to notice the change.
Why Agent Experience Matters Now
This is just reality now, and it feels like it happened overnight. Developers are turning to agents to discover, evaluate, and onboard onto products instead of Googling or reading docs themselves.
An agent's first instinct is to answer from training data, which can be stale or biased toward whatever was best documented at training time. Getting it to search the web produces more up to date answers, but that search is only as good as what's out there to find. If your product isn't published with credible, sourced information in enough places, there's nothing for the agent to draw on either way.
Release.com is a good test case for this because it's competing in a market where a handful of names already dominate, like Vercel, Railway, Netlify, and Heroku. The tests below look at whether Release has done enough to support agents in that environment.
What This Audit Tests
We ran this audit with Claude Code in a clean context (fresh install, no memory, no skills, no saved preferences) to mimic what a brand new user of the agent would see.
Each test has two layers of evidence:
- A live run, where we typed the prompt ourselves and screenshotted exactly what came back.
- A handful of repeat runs done automatically, to see if the results are consistent across multiple searches.
There are four tests:
- Discovery: Does the agent find you without being asked?
- Recommendation: Does it recommend you for a real use case?
- Comparison: Does it get its facts about you right when pushed for detail?
- Agent Tooling: Has the product given agents anything to read in the first place, and can an agent discover and use those tools?
Test 1: Do Agents Easily Discover Your Brand?
Discovery is the simplest test in this audit and the one with the highest stakes. It asks whether your product comes up at all when a developer describes what they need without naming any company.
How to Test This
The way to formulate this prompt is to describe the use case in plain terms, exactly as a real developer would, and leave every company name out. That way, whatever comes back is the agent's own judgment, not something you steered it toward.
For Release, we asked this:
I'm a developer choosing a platform to deploy and host a full-stack web application (frontend + backend + database), with per-pull-request preview environments. List the platforms you'd consider, briefly, and say which sources or knowledge you're basing this on.
It's good practice to ask the agent for its sources. You can also restrict the first prompt to block web search, so it has to answer from training data alone, and see what that reveals about what it already believes about your category. Then ask a follow up that allows web search, to see what changes once it does the research.
Assume no specific companies, and answer my question again after doing research.
Running both versions gives you two separate signals, what the agent already "knows," and what it finds when it looks. In our case, the agent volunteered the first answer from memory and flagged that itself, offering to search if we wanted current information.
How to Evaluate the Result
The read here is simple. Does your product show up in the list, and if so, where? A product buried at the bottom is a weaker result than one named early, but the real failure state is not appearing at all.
Pre-research answer
Working from memory alone, the agent listed a handful of well-known platforms as options, organized into a few natural categories. It clearly caveated that this was based on training data and could be stale. Release wasn't one of the names it offered.
Post-research answer
After a real web search, the agent came back with a longer, more structured answer, with five categories, cited sources, and more platforms named overall. Release still didn't make the list.
Take a look at the sources it pulled. Below, we'll briefly analyze the type of pages it trusts and pulls data from.
The sources it cited break down into two types:
- Official vendor documentation and product pages, the kind of page a company controls directly.
- Third-party comparison articles and blog posts, filling in the gaps between vendors.
Release has two separate problems here. Whatever's in the agent's training data isn't strong enough to surface Release unprompted, even with the category described in detail. And when the agent went and searched live, Release wasn't turning up in either type of source above, so there was nothing new for it to find and cite either.
Results Across Multiple Runs
A single conversation could be a fluke, so we reran the same prompt three more times, just to check the live result held up. Release did not appear in any of the repeat runs either.
| Run | Platforms named |
|---|---|
| 1 | Render, Railway, Northflank, Vercel, Netlify, Cloudflare, Coolify, Bunnyshell, AWS, Azure, GCP |
| 2 | Railway, Render, Northflank, Fly.io, Vercel, Netlify, Cloudflare, Heroku, AWS, Azure, GCP |
| 3 | Railway, Render, Northflank, Bunnyshell, Vercel, Netlify, Fly.io, DigitalOcean |
Railway, Render, Vercel, and Northflank came up in all three runs. Northflank is worth noting specifically, since it competes on the same container/Kubernetes-based ephemeral environments positioning Release uses to describe itself, and it made the list every time.
What to Do About These Results
There are two separate gaps to close here.
Fixing the training-data gap
You can't rewrite an agent's training data directly, but you can make sure the next training cut has more to work with. Publish clear, specific, well-structured content about your product and its category positioning, in your own words, on pages that are easy to crawl and index. The goal is to give the next generation of models something concrete to learn from.
Fixing the live-search gap
This one is more immediately actionable. Get your product into the kinds of sources agents cited in these runs:
- Official comparison and "best of" style articles.
- Category round-ups on sites like the ones your competitors already appear in.
- Community discussion (forums, Reddit, dev blogs) where people compare tools by name.
Count how many of these your competitors appear in versus you, and close the biggest gap first.
Test 2: Do Agents Recommend Your Brand for the Right Job?
Recommendation asks whether, when a real use case lands squarely in your product's strength, the agent puts you forward.
How to Test This
The way to build this prompt is to describe a scenario that plays directly to your product's stated strength, again without naming any company.
For Release, the closest fit is its own core differentiator, ephemeral, per-pull-request environments that include a full copy of the database, used for QA isolation. So that's the scenario we described:
My team runs a full-stack app and we want ephemeral, per-pull-request preview environments that spin up the whole stack (services + database) automatically, so QA can test each PR in isolation before merge. Which single platform would you recommend we adopt, and why that one over the alternatives?
As with Discovery, we followed up by forcing a research pass:
Answer that question again. Assume no specific company, and answer after doing research.
How to Evaluate the Result
If your product wasn't recommended, check what won instead and why. If the agent picked a better fit for the scenario, that's a fair loss. If it picked a worse fit and your product simply never came up, that's a visibility problem, not a product problem.
Pre-research answer
Working from memory, the agent picked a single platform and explained why, naming a couple of runner-up options for a slightly different flavor of the same need. Release wasn't named anywhere in the answer, not even as a runner-up.
Post-research answer
After live web searches, the agent landed on the same recommendation, now backed with cited sources, and it even noted that some of those sources leaned favorable to themselves. Release still didn't come up at all.
This is the toughest result in the whole audit. Release is losing out on the exact use case it built itself around, and giving the agent more time and web access to think about it didn't change anything.
Results Across Multiple Runs
We repeated this prompt four more times.
| Run | Winner | Release mentioned? |
|---|---|---|
| 1 | Railway | No |
| 2 | Railway | No |
| 3 | Fly.io | No |
| 4 | Railway | Yes, as a runner-up |
What to Do About These Results
Losing the use case you're built around means the connection between your product and that use case isn't documented clearly enough anywhere the agent can find it. Publish content that names the specific scenario directly, in the same language a developer would use to describe it, rather than only describing it in general marketing terms. For example:
- A dedicated docs or blog page titled around the exact scenario ("per-PR preview environments with a full database copy"), not just a features list.
- A comparison or migration guide that names the use case and walks through how your product handles it end to end.
- A tutorial or reference architecture a developer could follow, showing the specific workflow rather than describing it abstractly.
Test 3: Do Agents Get Their Facts About Your Brand Right?
Comparison asks whether, once your name is on the table, the agent gets its facts about you right. A confident wrong answer does more damage than no answer at all.
How to Test This
The way to build this prompt is different from the first two tests. This is the one test in the audit where you name your own product directly, next to the competitors you'd naturally be compared against, since the goal is to see whether the agent can be trusted once it's talking about you specifically.
Name the two or three competitors you're most often compared against. For Release, that's Vercel and Heroku.
Compare Release.com against Vercel and Heroku for hosting a full-stack app with per-pull-request preview environments. Be concrete about pricing tiers and what each platform includes. For every specific claim you make about Release.com's pricing or features, state how confident you are and what it's based on.
Asking the agent to rate its own confidence is a safeguard, meant to make it honest about missing or uncertain information rather than let a guess pass as a fact.
How to Evaluate the Result
Every factual claim in an answer like this can be checked against reality. The worst outcome is a wrong claim stated with confidence. A vague or hedged claim is mediocre but forgivable. An accurate, well-sourced claim is the best case, and worth calling out when it happens.
Comparison table
The agent built a clean side-by-side table covering how each platform's preview environments work, whether they tear down automatically, and what they cost.
Pricing tiers
For Vercel and Heroku, the agent pulled real numbers straight from their pricing pages and reported them with high confidence. For Release, it couldn't do the same. It flagged low-to-medium confidence and admitted it couldn't load Release's pricing page, so it pieced together a guess from marketing copy and third-party listing sites instead. It came back with no concrete number at all, and explicitly told us to go get a real quote rather than trust what it had inferred.
Recommendation and sources
The final recommendation leaned toward Vercel or Heroku depending on the use case, but it did carve out a real, if narrow, niche where Release made sense. That's the most favorable the agent was toward Release across the entire audit, though it's still hedged behind "we can't verify the pricing, go ask them directly."
The honest confidence-flagging here is a good sign for how the agent behaves. The bad sign is why it had to hedge in the first place. It could not load Release's own pricing page to check the facts.
Results Across Multiple Runs
We ran this same comparison four more times.
| Run | Vercel & Heroku pricing | Release pricing |
|---|---|---|
| 1 | Confirmed from official pages | Low confidence, no public pricing found |
| 2 | Confirmed from official pages | Low confidence, cited an unverified $5,000/month floor |
| 3 | Confirmed from official pages | Low-medium confidence, cited the same unverified $5,000/month floor |
| 4 | Confirmed from official pages | Medium confidence, cited the same unverified $5,000/month floor |
The pattern held across every run. The agent could always confirm real numbers for the competitors, and never for Release. Three of the four repeat runs converged on the same unverified $5,000/month figure, pulled from third-party listings rather than Release's own site, while the live run in the section above couldn't produce a number at all.
What to Do About These Results
If an agent can't load your pricing page, it will either say nothing or guess, and neither is good for you. There are two separate problems to fix here.
Fixing the crawlability gap
Make sure your pricing information exists somewhere an agent can read it, not just somewhere a human can click through. If your pricing page is a JavaScript-rendered single-page app, that alone can block an agent from ever seeing the numbers on it.
Fixing the missing-number gap
Even once the page is readable, an agent still needs a real number to cite. If your pricing is "contact sales," third-party sites and comparison articles will fill that gap with their own guesses, and agents will repeat those guesses with a confidence label attached. Publish at least a starting price or a representative range somewhere public, even if full pricing is custom.
Test 4: Is the Product Set Up to Support Agent Tooling?
Agent Tooling asks whether your own website gives an agent anything to work with in the first place. Even a product with a spotless reputation is limited by this, because it's the raw material every other answer gets built from.
How to Test This
This test doesn't need a made-up scenario. You just check the product's own domain directly for the handful of things that make a site agent-readable:
- A
/llms.txtfile. - Documentation in plain Markdown rather than JavaScript-rendered pages.
- A machine-readable API spec.
- A public MCP server.
- Any officially published agent skill.
For Release, we asked the agent to go check for all of these on release.com and docs.release.com, and to list every URL it visited:
I'm evaluating whether Release.com is easy for AI coding agents like you to research and recommend. Check whether release.com or docs.release.com expose any agent-friendly tooling: an /llms.txt file, plain-markdown documentation, an OpenAPI/Swagger spec, a public MCP server, or any published Claude/agent skill. For each one, say clearly whether you found it, what URL you checked, and whether what you found looks genuinely usable by an agent (not just present but buried behind JS rendering or hard to parse). List every URL you consulted under a Sources heading.
How to Evaluate the Result
Just having one of these things isn't enough. The real question is whether it's usable, current, structured, and not hidden behind a JavaScript-heavy page an agent can't render.
Findings
This turned out to be the most positive result in the whole audit. Release's documentation site has a real, working llms.txt, a clean Markdown version of every docs page, and a machine-readable API spec. All three are things an agent can use, not just things that technically exist. The gaps were narrower. Release doesn't have a self-serve MCP server (the one it advertises is gated behind booking a demo), and there's no officially published agent skill.
Sources
This result reframes the other three. Release's documentation is in good shape and readable to agents. The problem is everything upstream of the docs. Agents don't mention Release unprompted, don't recommend it for its own best use case, and can't even load its pricing page. An agent only reads the docs once it already knows to check docs.release.com specifically, and the first three tests show that mostly doesn't happen.
What to Do About These Results
There are two remaining gaps here.
Making the MCP server self-serve
Release already advertises an MCP server, but it's gated behind booking a demo. Publish install instructions, a server URL, or a repo that a developer or agent can reach without a sales call.
Publishing an agent skill
There's no officially published Claude or agent skill for Release yet. A published skill gives agents a ready-made, vetted way to work with the product directly, rather than improvising from documentation alone.
What the Four Results Add Up To
Line them up and a pattern falls out:
| Test | Result for Release |
|---|---|
| Discovery | Never mentioned, pre- or post-research, across four live and repeat runs |
| Recommendation | Not recommended in the live run; named as a runner-up in just one of four repeat runs |
| Comparison | Pricing not verifiable, in the live run or any repeat run |
| Agent Tooling | Documentation is agent-ready (llms.txt, Markdown docs, OpenAPI spec); no self-serve MCP server or published agent skill |
Release is a product that's invisible until you already know to look for it, and even then, its main marketing site gets in the way. The docs are ready. Almost nothing upstream of the docs is.
What This Means for Release
Developers increasingly ask an agent before they ask a search engine. If the agent doesn't bring you up, you're not in the running, no matter how good the product is.
Release moved into a market where a handful of names, Vercel, Railway, Netlify, Heroku, already dominate whatever an agent defaults to.
Not being mentioned
Release isn't present in the training data or live-search sources agents actually draw on for this category, even in the category description that matches its own positioning. The fix is the same one covered under Discovery: publish clear, specific content in your own words, and get into the comparison articles, round-ups, and community discussion where competitors already appear.
Not being recommended
Release loses the exact use case it's built around because that connection isn't documented anywhere an agent can find it. The fix is the one covered under Recommendation: publish content that names the specific scenario directly, in the language a developer would use, not just general marketing copy.
Not being fact-checkable
Release's pricing page can't be verified by an agent, so third-party listings and guesses fill the gap instead. The fix is the one covered under Comparison: make the pricing page crawlable, and publish at least a starting price or range so there's a real number to cite.
How Ritza Can Help
The good news is that the gaps here are fixable. Some are small and mechanical, like making the pricing page readable by something other than a browser running JavaScript. Others need real work, like getting findable content out into the places agents search, and building out the agent-facing tooling, like a self-serve MCP server, that Release has only half-built so far.
At Ritza, we do both kinds of work, a deeper audit that also covers onboarding and integration, and hands-on help building the tooling that closes exactly the gaps this audit found.
Want help understanding and fixing the AX of your own technical product or platform? At Ritza our Engineering Writers work at agent speed with human-expert verification (no slop) to win at GTM.