[ documentation ]

AI Discovery

Keep the owner workflow simple: start with the Workspace-generated production snippet, let Dayside publish the minimized seed/presence as the visible cue, then add the well-known artifacts only if you want stronger machine-readable discovery beyond the runtime. The artifact names — rover-site.json and agent-card.json — are wire names kept for protocol compatibility.

Required

Use the Workspace-generated install path first

Direct installs: open Install, copy the production snippet, and paste it before </body>.
Webflow-managed installs: Dayside already deploys the required managed runtime bundle for you, and that runtime injects the marker, inline discovery manifests, service-desc/service-doc links, and A2W GET guidance from the same saved config. Re-open managed setup from Workspace when you need to reconnect or republish. Static well-known files and HTTP headers still require an origin you control.
Baseline discovery: when AI launch is enabled, the generated snippet emits the marker, inline card/site manifests, hidden semantic landmark, cloud GET guidance, and the visible seed/presence cue. The larger debug-only action list stays out of production.

Recommended

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. Publish them at:

Well-known paths
/.well-known/rover-site.json
/.well-known/agent-card.json

rover-site.json is the authoritative 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.

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.

Optional

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

HTTP 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

HTML
<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.

Optional support only

Use robots.txt and llms.txt as supplements

Workspace can generate an llms.txt addendum with POST, GET, and rover_exec instructions, but Dayside 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

Rely on

  • A2W POST for coding agents and autonomous clients.
  • A2W GET and rover_exec for chatbot URL-fetch tools.
  • Well-known JSON files and service-desc as the strongest generic discovery path.

Do not rely on alone

  • POST-only discovery; many chatbots cannot POST.
  • JavaScript-only runtime injection; many crawlers fetch source without running a browser.
  • llms.txt, robots comments, visual badges, or deep links as the only action surface.

Webflow-managed sites

Required install: Dayside handles the managed runtime deploy for you.
Advanced artifacts: only publish the generated rover-site.json, agent-card.json, full A2W Link header, or llms.txt if you also control the live origin, CDN, or another route to publish those files or headers.
Workspace split: use Launch for first-time direct installs, Settings for ongoing edits, and Install for the generated outputs and portable test config.

Related guides

Quick Start for the required production install path.
Install to copy the generated snippet, test config JSON, and discovery artifacts.
Try on Other Sites for Helper, Console, Bookmarklet, and Live Test flows.