Capability Exposure: From llms.txt to Agent-Ready Products

If a capability can only be discovered in a sales demo, AI systems cannot recommend it. Capability exposure is the work of making what your product does legible to machines, and in 2026 the machines that matter most are no longer just crawlers. They are agents.

This chapter starts by retiring an idea that dominated 2025, then lays out what exposure actually means now.

The honest state of llms.txt

llms.txt is a Markdown file at the root of a site that summarizes and links its most important content for language models. It was proposed in 2024 and quickly became a staple of GEO checklists, including some of mine.

The 2026 evidence is clear enough to state plainly:

• Adoption is rising. Originality.ai, monitoring more than 3 million websites, counted about 36,000 llms.txt files in May 2026, up about 8.8x from June 2025 (PPC Land on Originality.ai).
• Use is not. Ahrefs found that 97% of about 38,000 valid llms.txt files received zero requests of any kind in May 2026: no bots and no humans (Ahrefs).
• Google says it is unnecessary. Its May 2026 guide says you do not need new machine-readable files, AI text files, markup or Markdown to appear in Google Search (Google Search Central).

There is one real use. Some coding tools and agents fetch documentation on demand and can use a clean index or full-text Markdown of your docs. For developer-facing products, that makes llms.txt a cheap developer-experience feature.

My position: publish one if it costs you an hour, as I do for my own site, and expect nothing from it for citations. If a vendor sells llms.txt as a GEO lever, ask them for the request logs.

The broader lesson matters more than the file. The idea behind llms.txt was right: make your important information easy for machines to consume. The mechanism was wrong, because it asked machines to adopt a new convention instead of meeting them where they already read. The approaches that work in 2026 do the opposite.

Three kinds of machine reader

Capability exposure has to serve three readers, each with different needs.

Reader	What it does	What it needs from you
Answer engines	Retrieve and synthesize answers for human buyers	Public, crawlable, specific pages about capabilities, standards and limits
Coding agents	Read docs and specs to write integration code for developers	Accurate docs, current API specs, runnable examples, stable URLs
Acting agents	Research, compare, trial or buy on someone's behalf	Structured facts they can query, clear pricing, a way to try the product, safe ways to act

The first reader is the one most GEO work targets. The second already accounts for a large share of docs traffic (Chapter 6). The third is the newest, and it changes the question from "can an engine describe us?" to "can an agent work with us?"

Acting agents are already arriving

The infrastructure for agents that act is being built quickly. MCP, released in November 2024, gives agents a standard way to call tools and read data. OpenAI and Stripe's Agentic Commerce Protocol arrived in September 2025, and Google's Universal Commerce Protocol in January 2026 (Elogic). Google also added a user-triggered fetcher, Google-Agent, to its official crawler documentation in March 2026; because user-triggered fetchers act for a person, Google says they generally ignore robots.txt rules (Google).

The transaction layer is still immature. In March 2026 OpenAI stepped back from Instant Checkout, moving merchants to their own checkout flows and focusing ChatGPT on product discovery (OpenAI). For B2B software, that is the right frame: agents completing purchases is early, but agents doing research, comparison and shortlisting is already happening, because that is just the buyer's chatbot with more autonomy.

So the near-term investment for B2B is not checkout. It is making your product easy for agents to understand, compare and try.

The exposure ladder

I find it useful to think of capability exposure as a ladder. Each rung makes more of the product legible to more machine readers.

Rung	State	What a machine can do
0. Hidden	Capabilities appear only in demos, decks or behind login	Nothing; the capability does not exist to machines
1. Described	Public pages describe capabilities in plain, specific language	Answer engines can mention it
2. Specified	Docs state limits, standards and versions; API references come from a current spec	Engines can cite facts; coding agents can integrate
3. Queryable	Structured facts are available on request: capability and integration catalogs, pricing data, status, a sandbox or trial	Agents can compare and verify without a human
4. Operable	Agents can act through authenticated, scoped interfaces such as an MCP server	Agents can trial, configure or request access on a user's behalf

Most B2B products sit at rung 1 for their headline features and rung 0 for everything else. The audit in Chapter 4 moves the important capabilities to rung 2. Rungs 3 and 4 are where agent-ready products are heading.

What to expose first

You do not need an MCP server to make progress. Start with the facts agents and engines ask about most:

1. A capability catalog. A public, structured page listing every capability with its brand name, functional term, tier and docs link, generated from the fact model in Chapter 7.
2. An integration catalog. Every integration, its depth (native, API, partner) and its docs.
3. Standards and compliance. Supported protocols and versions, certifications and audit dates, data residency regions.
4. Pricing structure. Enough public detail for an engine to state your pricing model correctly, even if enterprise prices stay negotiated.
5. A way to try. A free tier, sandbox or self-serve trial an agent can point a human to, or start for them.
6. Current API specs. Published OpenAPI or equivalent specs, versioned, matching production.

Every item on that list is ordinary product work. That is the point. Capability exposure is not a GEO trick bolted onto the product. It is the product describing itself in machine-usable forms.

If you build an MCP server, build it like a security product

This is where my identity background makes me cautious. An MCP server or any agent-facing interface is a new door into your product. Treat it like one.

• Start read-only and public. The first useful agent interface for most B2B products exposes public facts: capabilities, integrations, docs search, pricing structure. No customer data.
• Authenticate agents properly when you go further. Use standard OAuth flows with narrowly scoped, short-lived tokens. Know which user an agent acts for, and log what it did.
• Assume prompt injection. Content your interface returns can be read as instructions by the agent consuming it. Return data, not prose that could be mistaken for commands, and never let one customer's content reach another's agent.
• Rate-limit and monitor. Agents can call far faster than people click.

My prediction: agent-facing interfaces without identity and authorization discipline will be where a new class of breaches starts. A product that is easy for agents to use and hard for agents to abuse will be trusted by both the agents and the security teams that approve them.

Decide your crawler policy deliberately

Exposure also means not blocking the readers you want. Many companies block AI crawlers by default, often through a bot-protection setting nobody reviewed.

Separate three kinds of bots and decide on each: training crawlers that collect data for future models, search crawlers that fetch pages to cite in answers, and user-triggered agents that fetch on behalf of a person. Blocking has costs. One 2026 study of news publishers found that blocking AI crawlers was followed by about 7% fewer weekly visits within six weeks (Zhao and Berman, SSRN). Publishers are not B2B software companies, but the direction is a warning: if you want to be cited, let the citing systems read you.

How to measure exposure

• Log requests by user agent and track which AI systems read which capability and docs pages
• Track description accuracy for capabilities at each rung of the ladder
• If you run an agent interface, track calls by tool and which questions agents ask most
• Watch for capabilities engines describe wrongly, which usually means they sit at rung 0 or 1

Who owns it

Capability exposure sits with product and engineering, with security as a required partner once you pass rung 2. Product marketing defines which capabilities matter most to buyers. Engineering builds the catalogs, specs and interfaces. Security decides what is safe to expose and how agents authenticate.

Key takeaways

• llms.txt adoption is rising but almost no AI bots request it. It is a cheap developer-experience feature, not a citation lever.
• Capability exposure serves three readers: answer engines, coding agents and acting agents.
• Climb the exposure ladder: hidden, described, specified, queryable, operable.
• Build any agent interface like a security product: read-only first, scoped OAuth, logging, rate limits and prompt-injection defenses.
• Set crawler policy deliberately for training, search and user-triggered bots.