A lot of teams ship one machine-readable file and then quietly hope the agent will figure out the rest.
Sometimes it does. A lot of the time it does not. The agent lands on one page, sees a pile of HTML, and has to guess where the clean map lives, whether a bigger context file exists, and what the product can actually do.
That is usually a packaging failure, not a content failure.
Compatibility beats elegance on the first fetch
The first move I would steal is well-known llms aliases for agent compatibility. A lot of teams are happy once publish llms.txt for agent retrieval is done, but discovery is still fragile if the file only lives in one place.
If one client checks the root and another checks a well-known path, the practical answer is to stop making them choose.
Normal pages should point to the map
I like llms discovery headers on every page because it fixes a boring but expensive gap. If an agent opens a normal page first, the response itself should advertise where the clean corpus lives.
That fits naturally beside sitemap.md semantic discovery map and content-negotiated markdown on canonical URLs. One tactic gives the crawler a route. The other makes the route easier to notice.
Some agents do better with one big file
The simplest upgrade in this batch is llms-full single-file context export. Not every tool wants to walk a tree of links. Some do better when the useful context is already gathered.
That does not replace page-level structure. It gives the retrieval layer a second, lower-friction door.
Discovery and capability are different jobs
That is why root skill.md for product capability discovery matters. `llms.txt` tells the agent where to read. `skill.md` tells it what the product can actually help with.
I think this is the missing bridge between llms.txt plus MCP content corpus for AI discovery and the actual workflows a buyer wants to run. Reading the docs is one problem. Using the product correctly is another.
Complex products should not hide every workflow in one blob
The most operator-friendly move here is agent-skills index for multi-workflow products. If a product has billing, analytics, docs, and admin paths, a single giant capability file becomes its own small maze.
Separate skills plus a discovery index keep the machine-readable layer organized the same way a good product keeps its UI organized. Each job gets a clean doorway.
Where this cluster is most useful
This cluster is strongest for SaaS, AI products, developer tools, and creator platforms that want assistants to quote the product accurately or guide a user through a real workflow. It matters most when the site already has useful content but still makes the retrieval layer work too hard to find it.
If your machine-readable layer still expects the agent to guess the next file, I would assume the site is leaving easy trust on the table.