Developers increasingly ask an AI coding agent to pick a tool before they ask a search engine. An agent builds its answer from training data plus whatever it finds across the web, comparison articles, forums, third-party listings, not just a company's own site. If your product isn't showing up in enough of those places, you're not in the running, no matter how good the product is.
We ran a four-test agent experience audit against Release.com, a deployment platform that recently repositioned itself as a PaaS competitor to Vercel and Heroku. We tested Claude Code on discovery, recommendation, comparison, and agent tooling. For each test, we show you the result, then repeated the test several more times to check the result held up.
Scores at a glance
Agents don't mention Release unprompted, don't recommend it for its own core use case, and can't verify its pricing. The one strong result is agent tooling on the documentation site, but an agent only gets there once it already knows to look for Release by name, which the first three tests show mostly doesn't happen.
See our AX audit rubric for how we score each test.
Do agents easily discover your brand?
To test discovery, you describe what a developer needs without naming any company, and check whether a product comes up unprompted, first from the agent's own memory and then again after a live web search.
For Release, that means checking whether it surfaces as an option for the exact category it competes in. If it doesn't appear, the product isn't favored in the training data, or isn't easily discoverable through sources on the web.
Here is the prompt we used to test 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.
Assume no specific companies, and answer my question again after doing research.
Tap any screenshot to zoom in and read it, tap again to close.
Working from memory, the agent listed a handful of well-known platforms and caveated that the answer could be stale. After a live web search, it came back with a longer, more structured list, five categories, more platforms named overall, citing both official vendor docs and third-party comparison articles. Release did not appear in either answer. The specific problems:
- Not present in the agent's training data, even with the well-known platforms it did name from memory.
- Not surfaced by a live web search, despite a more thorough, better-sourced answer overall.
- Not cited in any of the sources the agent pulled from, official vendor docs or third-party comparison articles.
Repeating the discovery test to check the result held up
We reran the post-research prompt three more times to check the result held up. Release did not appear in any of the four tests. Railway, Render, Vercel, and Northflank came up in all three repeat tests. Northflank is worth noting specifically since it competes on the same container/Kubernetes-based ephemeral environments positioning Release uses to describe itself.
| 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 |
What to do if agents don't mention you
An agent doesn't just read your own site. It draws on training data plus whatever it finds across the web, so closing this gap means fixing what the agent already knows and getting your product into the range of sources it actually pulls from when it searches.
Publish content so future model training includes you
You can't rewrite an agent's training data directly, but you can publish clear, specific content about your product and category positioning, in your own words, so the next training cut has something concrete to draw on.
Get listed in comparison articles, round-ups, and community discussion
This is the more immediately actionable fix. Get into the comparison and "best of" articles, category round-ups, and community discussion (forums, Reddit, dev blogs) where competitors already appear. Count how many of these your competitors show up in versus you, and close the biggest gap first.
Do agents recommend your brand for the right job?
To test recommendation, you describe a real use case that plays to a product's strengths, again without naming any company, and check whether the agent puts it forward, first from memory and then again after a live web search.
For Release, that means describing the scenario it's built around: ephemeral, per-pull-request environments with a full database copy for QA isolation. If Release doesn't win here, agents can't identify the core value Release offers, or don't see it as a competing player in that category.
Here is the prompt we used to test this:
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?
Answer that question again. Assume no specific company, and answer after doing research.
Tap any screenshot to zoom in and read it, tap again to close.
Working from memory, the agent picked a single platform and named a couple of runner-ups for a slightly different flavor of the same need. After a live web search, backed with cited sources, it landed on that same recommendation. Release did not come up in either answer, not even as a runner-up. The specific problems:
- Not the top recommendation from memory, despite the scenario matching Release's own core differentiator.
- Not the top recommendation after a live web search either, even with cited sources backing the answer.
- Not named as a runner-up in the live test, only appearing as one in a single repeat test out of four.
Repeating the recommendation test to check the result held up
We repeated the prompt four more times. Railway or Fly.io won every test. Release was named just once, as a runner-up in the fourth test, and never as the top recommendation.
| Run | Winner | Release mentioned? |
|---|---|---|
| 1 | Railway | No |
| 2 | Railway | No |
| 3 | Fly.io | No |
| 4 | Railway | Yes, as a runner-up |
What to do if agents don't recommend you
Losing the use case you're built around means that connection isn't documented anywhere the agent can find it. Publish content that names the specific scenario directly, in the language a developer would use, not just general marketing copy.
Publish a page built around the exact use case agents are asked about
A docs or blog page titled around the exact scenario, for example "per-PR preview environments with a full database copy," rather than a general features list.
Show the product solving the problem end to end
A comparison or migration guide that walks through how your product handles the scenario from start to finish.
Give developers a concrete workflow to follow
A reference architecture a developer could follow directly, showing the specific workflow rather than describing it abstractly.
Do agents get their facts about your brand right?
To test comparison, you name the product directly alongside the competitors it's most often compared against, rather than describing a scenario and leaving it to surface on its own, and check whether the agent gets its facts right once it's on the table.
For Release, that means naming it next to Vercel and Heroku. If the agent can't verify its claims about Release, its pricing and features aren't published anywhere an agent can confirm them, so it guesses instead.
Here is the prompt we used to test this:
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.
Tap any screenshot to zoom in and read it, tap again to close.
The agent built a clean comparison table naming Release alongside Vercel and Heroku, an improvement on the first two tests. It opened by correctly separating Release from the other two: Vercel and Heroku are managed platforms you deploy to, while Release is an orchestration layer that sits on top of your own Kubernetes cluster or cloud account. On that basis it scoped Release to a specific niche, teams already running containerized, multi-service stacks who want a full per-PR clone including data, rather than recommending it as a general-purpose alternative to Vercel or Heroku. That's an accurate read of the product, and the most favorable framing Release got anywhere in this audit.
The pricing comparison undercut it. For Vercel and Heroku the agent pulled real numbers straight from their pages with high confidence. For Release it admitted it couldn't load the pricing page, and pieced together a low-to-medium confidence guess from marketing copy and third-party listings instead. The specific problems:
- Couldn't load Release's pricing page, the one page in the comparison it couldn't verify directly.
- No concrete pricing figure, only a guess assembled from third-party sources, with a note telling us to go get a real quote instead.
- Recommendation qualified by exactly that gap. Even Release's best result in the audit came with a "we can't verify the pricing" caveat attached.
Repeating the comparison test to check the result held up
We ran this comparison four more times. The agent always confirmed real numbers for the competitors and never for Release. Three of the four repeat tests converged on the same unverified $5,000/month figure, pulled from third-party listings rather than Release's own site.
| 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 |
What to do if agents can't verify your facts
If an agent can't load your pricing page, it will either say nothing or guess, and neither is good for you.
Make sure your pricing page is readable by both humans and agents
Make sure your pricing information exists somewhere an agent can read it, not just somewhere a human can click through. A JavaScript-rendered single-page pricing app alone can block an agent from ever seeing the numbers on it.
Publish accurate information so agents don't have to guess
Publish at least a starting price or a representative range publicly, even if full pricing is custom. Otherwise third-party sites will fill that gap with their own guesses, and agents will repeat those guesses with a confidence label attached.
Is the product set up to support agent tooling?
To test agent tooling, you check a product's own site directly for the handful of things that make it agent-readable: a /llms.txt file, plain-Markdown documentation, a machine-readable API spec, a public MCP server, and any officially published agent skill.
For Release, that means checking release.com and docs.release.com. If these are missing, an agent that finds Release has no structured content, API spec, or tooling to use in research and building tasks.
Here is the prompt we used to test this:
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.
Tap any screenshot to zoom in and read it, tap again to close.
This was the most positive result in the 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 usable by an agent, not just technically present. Two gaps remain.
- No self-serve MCP server. The one Release advertises is gated behind booking a demo.
- No officially published agent skill.
This result reframes the other three. Release's documentation is in good shape and readable to agents, but 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.
How to give agents tools to access your service
The remaining gaps are both about closing the loop on tooling Release has already half-built.
Make your MCP server available without a sales call
Publish install instructions, a server URL, or a repo for the MCP server that a developer or agent can reach without a sales call.
Publish an official agent skill to give agents a vetted way to work with your product
Publish an officially supported Claude or agent skill, giving agents a ready-made, vetted way to work with the product directly instead of improvising from documentation alone.
What this means for Release
Release moved into a market where a handful of established competitors dominate whatever an agent defaults to.
It's a problem when agents don't mention you
Release isn't present in the training data or live-search sources agents draw on for this category, even in the exact category description that matches its own positioning. Publish content agents can learn from, and get into the comparison articles and community discussion agents search when researching this category.
It's a problem when agents don't recommend you
Release loses the use case it's built around because that connection isn't documented anywhere an agent can find it. Publish content that names the specific scenario directly, in the language a developer would use, rather than general marketing copy.
It's a problem when agents can't verify your facts
Release's pricing page can't be verified by an agent, so third-party listings and guesses fill the gap instead. Make the pricing page readable by both humans and agents, and publish real numbers instead of leaving the gap for others to fill.
How Ritza can help
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 are about getting findable content out into the places agents search, and publishing more agent-facing tooling, like a self-serve MCP server and an officially supported agent skill.
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.