Agent readiness for software companies: pricing, sign-up and docs
Most agent readiness advice is written for online stores. But software buyers send AI agents to do research too: compare plans, check whether a tool integrates with what they already use, find the limits of a free tier, and start a trial. For a software company, the pricing page is the product page, the sign-up form is the checkout, and the docs are where the real evaluation happens.
How AgentScore sees a software site
AgentScore looks for the pages an agent acting for a customer would need, the way an agent would: links in your home page's HTML, then your sitemap, then common addresses such as /pricing. If it finds product pages or a cart, it treats the site as a store. If it finds a pricing page and no products or cart, it treats the site as software ("saas" in the scan's data). That changes what some checks look for.
| Check | On a software site, it looks at |
|---|---|
| AI agents can open your product, pricing and cart pages | Whether AI assistants can load your pricing page, not just a browser |
| Prices are in the page HTML | Whether plan prices are in the HTML your server sends, before JavaScript runs |
| Key pages are linked from the home page | Whether pricing is linked from the home page with an ordinary link |
| Agents can find and press your add-to-cart or sign-up button | Whether the pricing page has a real, visible button such as "Start free trial" or "Buy Pro" |
| Cart, checkout and agentic commerce checks | Nothing. They're marked "not tested", so they don't count against you |
Everything else, from robots.txt and bot protection to structured data, named buttons and labelled form fields, applies the same way as for any site. See what is agent readiness? for the full model.
Pricing pages agents can read
Pricing pages are often the most designed page on a software site, and that's where agents struggle. Common problems:
- Prices loaded by JavaScript. A monthly/annual toggle that fetches prices when clicked leaves the HTML with no prices at all. Put both sets of prices in the HTML and let the toggle show and hide them.
- Features shown only as icons. A comparison table of tick and cross images says nothing to an agent unless each icon has a text label, such as "Included" or "Not included". See image alt text.
- Units left implicit. Say "per user per month, billed annually" in text, not in a tooltip. Agents compare plans across vendors, and unclear units make you look more expensive or less clear than a competitor.
- "Contact sales" with no explanation. If a plan is priced on request, say so in plain text and say what affects the price. An agent can then tell its user how to get a quote instead of guessing.
A plain HTML table is still the clearest way to compare plans:
<table>
<caption>Northwind plans, billed annually</caption>
<tr><th></th><th>Starter</th><th>Pro</th></tr>
<tr><th>Price</th><td>$12 per user per month</td><td>$29 per user per month</td></tr>
<tr><th>Single sign-on</th><td>Not included</td><td>Included</td></tr>
</table>For more, see prices AI agents can read.
Sign-up and trials
An agent that has chosen your product for someone will try to start the trial. It needs a visible, real button with a clear label, then a form it can fill in: every field labelled, errors explained in text, and no surprises. See buttons, links and forms agents can use.
Some steps should stay with the person, and that's fine. Email verification, single sign-on, payment details for a card-required trial and accepting terms are all reasonable places for an agent to hand back to its user. The aim is for the agent to get as far as it should, then stop cleanly with a clear message, rather than fail at a CAPTCHA on the first screen. See sign-up, booking and lead forms AI agents can finish.
Ghost Agents can test this journey for real: from the home page to pricing to the sign-up form, using test data you supply, with a step-by-step replay showing where an agent got stuck.
Docs are your product page for agents
For many software products, the docs decide the sale. Coding assistants and research agents read them to answer "does it support X?" and "how hard is it to set up?". Treat docs with the same care as marketing pages:
- Serve docs as HTML that works without JavaScript. Some docs sites are single-page apps that send an empty shell. See JavaScript-only content.
- Keep public docs public. If setup guides sit behind a login, agents can't use them to recommend you. See login walls and gated content.
- Give each version a stable address and point old copies at the current one, so agents don't quote outdated instructions. See canonical URLs.
- Publish limits, supported integrations and security information as text, not only in PDFs or sales decks.
llms.txt for software companies
llms.txt is a proposed convention, not a standard, and AI providers don't all say whether they read it. It's cheap to publish, though, and it suits software companies well, because your most useful pages are easy to list. Some docs platforms can generate one for you.
# Northwind
> Northwind is scheduling software for field service teams.
## Product
- [Pricing](https://northwind.example/pricing): plans, limits and what each includes
- [Start a free trial](https://northwind.example/signup): 14 days, no card required
## Docs
- [Getting started](https://northwind.example/docs/start)
- [API reference](https://northwind.example/docs/api)
- [Integrations](https://northwind.example/integrations)
## Trust
- [Security](https://northwind.example/security)
- [Status](https://status.northwind.example/)AgentScore checks that an llms.txt file exists. It can't tell whether yours is up to date, so add it to your release checklist. See how to write an llms.txt file.
MCP: your product, not just your website
For a software company, the Model Context Protocol is about more than your website. An MCP server can let an assistant use your product itself on a customer's behalf: look up records, create tasks, run reports. That's product work, with sign-in and permissions to design carefully, and many software companies are already building one.
There's no single agreed way to advertise an MCP server on a website yet. AgentScore's "Agents can use your site through MCP or WebMCP" check looks for a server card at /.well-known/mcp.json, an MCP link in the page, a mention in llms.txt, or WebMCP tools in the page. If you have a server, mentioning it in llms.txt and your docs is the simplest start. See MCP and WebMCP for websites.
Where to start
- Run AgentScore on your home page. If "Key pages are linked from the home page" doesn't pass, agents may not be finding your pricing page.
- View the source of your pricing page and check every price and plan feature is there as text.
- Make "Start free trial" a real, clearly labelled button, and check the sign-up form's fields are labelled.
- Publish an llms.txt that links to pricing, sign-up, docs and your trust pages.
- Test the journey from home page to sign-up with a Ghost Agent.