AI Discovery
Keep the owner workflow simple: start with the Workspace-generated production snippet, let Rover publish the minimized seed/presence as the visible Rover cue, then add the well-known artifacts only if you want stronger machine-readable discovery beyond the runtime.
Use the Workspace-generated install path first
</body>.Publish the generated well-known discovery files
If you do more than the snippet, publish the generated rover-site.json and agent-card.json files from Workspace, plus the optional catalog and commerce-bridge surfaces. Publish them at:
/.well-known/rover-site.json
/.well-known/agent-card.json
/.well-known/ai-catalog.json
/.well-known/rover-catalog.json
/.well-known/ucp
/.well-known/acp.json
/AGENTS.md`rover-site.json` is the authoritative Rover-native capability profile. `agent-card.json` is the broad interop card that generic agents and `service-desc` pointers can consume. Both include POST A2W, chatbot GET, and `rover_exec` guidance generated from Workspace instead of asking site owners to invent schema by hand.
`ai-catalog.json` is the ARD (Agentic Resource Discovery, v0.9 preview) catalog of the site's agent-usable resources. `rover-catalog.json` is the Rover-native capability feed. `/.well-known/ucp` and `/.well-known/acp.json` are the UCP- and ACP-path commerce bridge previews. `AGENTS.md` is the generated coding-agent brief — rtrvr.ai serves its own at /agents.md, and Rover also hosts a per-merchant copy at /s/{siteId}/AGENTS.md alongside the other backend-rendered surfaces, so agents can fetch them even before you publish on your own origin.
The A2W wire contract is published as OpenAPI at https://rtrvr.ai/openapi/a2w.yaml. Link to that spec from agent-facing docs when your site has developer documentation.
Add generated discovery pointers only if you control head tags or headers
Workspace also generates pointer surfaces that tell generic agents where the interop card, read-only docs, and A2W run endpoint live. Use one of these if you control HTML head output or server/CDN headers:
HTTP `Link` header
Link: </.well-known/agent-card.json>; rel="service-desc"; type="application/json",
</llms.txt>; rel="service-doc"; type="text/markdown",
<https://agent.rtrvr.ai/v1/a2w/runs>; rel="agent-run"; type="text/markdown"; method="GET POST"This belongs in app server, CDN, or reverse-proxy header config. It is a discovery header, not an executable task link.
HTML head tags
<link rel="service-desc" href="/.well-known/agent-card.json" type="application/json" />
<link rel="service-doc" href="/llms.txt" type="text/markdown" />
<link rel="agent-run" href="https://agent.rtrvr.ai/v1/a2w/runs" type="text/markdown" data-rover-methods="GET POST" />These belong in <head>, not in handwritten task anchors.
Use robots.txt and llms.txt as supplements
Workspace can generate an llms.txt addendum with POST, GET, and rover_exec instructions, plus an AGENTS.md coding-agent brief, but Rover should already be discoverable from the production snippet plus the well-known card/site files.
robots.txt is useful for crawler policy, sitemap location, and comments that point to /llms.txt, agent-card.json, rover-site.json, and OpenAPI. It is not a task protocol.
Rely On / Do Not Rely On
- A2W POST for coding agents and autonomous clients.
- A2W GET and
rover_execfor chatbot URL-fetch tools. - Well-known JSON files and
service-descas the strongest generic discovery path. /.well-known/ai-catalog.json(ARD v0.9 preview),/.well-known/rover-catalog.json,/.well-known/ucp, and/.well-known/acp.jsonfor catalog and commerce-protocol discovery.
- POST-only discovery; many chatbots cannot POST.
- JavaScript-only runtime injection; many crawlers fetch source without running a browser.
llms.txt,AGENTS.mdbriefs, robots comments, visual badges, or deep links as the only action surface.