Platform
Half our readers aren't people
Every page on this site has a Markdown twin at the same address, the API surfaces are described in a machine-readable catalog, and authentication is published as a document an agent can follow — all generated at build time, so none of it can fall behind.
An AI assistant reading this page doesn't want the navigation, the gradient, or the button that says "Start free". It wants the sentences.
So it can have them. Ask for this page as Markdown and you get the page as Markdown, from the same address.
What's actually published
A Markdown twin of every page. Not a summary, not an RSS blurb — the page, as text, with its tables and code blocks intact. Content negotiation on Accept, or just append .md if you'd rather be explicit.
/llms.txt. The whole site in one file: every page with a one-line description, grouped, so a model that has never seen this domain can find out what's here in a single request instead of crawling.
/.well-known/api-catalog. The programmable surfaces — the Workspace API and the MCP server — in the linkset format from RFC 9727, each with its documentation, its authentication guide and a health endpoint. For the Workspace API it points at the OpenAPI description that every workspace has been publishing all along.
/.well-known/auth.md. How to authenticate, written as a procedure rather than as prose about our commitment to security: which credential types exist, which endpoints they reach, the OAuth 2.0 endpoints, the registration endpoint, and what each scope actually grants. An agent can execute it.
Content-Signal in robots.txt. An explicit statement of what we permit — search=yes, ai-input=yes, ai-train=yes — rather than leaving a crawler to infer our position from silence.
Link headers on every page, so a client that fetched the HTML learns where the Markdown twin, the site index and the API catalog are without being told.
The part that makes it last
Publishing this once is a weekend. Having it still be true in six months is the actual problem, and it's solved with build failures rather than discipline.
A new page has to register in three places — the router, the prerender route list, and the sitemap. Miss one and the build fails with the mismatch named. That guard exists because the failure it prevents is invisible: a page that works perfectly for humans and is absent from every machine-readable index.
A twin must clear a content floor. A page whose Markdown extraction produces almost nothing has usually had its structure changed in a way the extractor didn't follow. That used to fail silently and produce a twin that was technically present and useless.
A blog post cannot publish without its verification stamp. Every post here carries verified and verifiedHow, and the build refuses a post that has neither. That's why the line at the bottom of this page names the artifacts I fetched rather than saying "tested".
Each of those was proven the same way: remove the guard, watch the build pass when it shouldn't, put it back.
Why bother
Partly because agents are how a growing share of people will reach this product, and a marketing site that only a browser can read is a site an agent will summarise from someone else's description of it.
Mostly, though, because it's cheap and it's honest. A Markdown twin can't have different content from the page — it's generated from it. A catalog that's generated from the build output can't advertise an endpoint that doesn't exist. Machine-readable and accurate turn out to be the same engineering problem.
What it doesn't do (yet)
- The twins are extracted from rendered HTML, not authored. Extraction is good at prose, headings, tables and code, and it will never be perfect on an unusual layout. When it degrades it now degrades loudly, which is the improvement — it isn't immune.
llms.txtis one flat file with nollms-full.txtcompanion, so a client wanting full text still fetches each twin.- No schema.org / JSON-LD structured data. The machine-readable story here is text and linksets, not RDF.
- The API catalog describes two surfaces, and the OpenAPI document it points at doesn't describe filtering — so a generated client is still missing part of the API.
- Content-Signal states a permission; it does not enforce one. It's a declaration, and a crawler that ignores it is not stopped by it.
- The docs site and the marketing site generate their twins differently — docs are Markdown already, so nothing is extracted there. Two mechanisms, one promise.
- None of this is versioned. There's no way to ask for the twin of a page as it read last month.
If you're building something that reads this site, /llms.txt is the front door. If it reads the product instead, the connector is one URL.
Verified 22 Aug 2026: every artifact fetched live from production while writing this — llms.txt, the RFC 9727 API catalog, auth.md, the Content-Signal directives and the Link headers; the build guards were each proven by removing them and watching the build fail.