What it means
Most systems became “AI-ready” by adding an integration to an existing shape: an API for the assistant, a plugin into the database. Loam asked what a site looks like when being understood by a machine is a constraint from the start. The answer: plain files, a public vocabulary, nothing between the content and whoever works on it, and machine views generated from the same source as the pages.
“Can an agent read this without help?” sorted every design decision — and each time, the answer that needed no help was also the simpler one.
How loam does it
- One shape, many readers. The live data is Schema.org JSON-LD. The data a browser renders, a search engine indexes and a language model reads is the same data, in the same shape. There is no separate API format to keep in sync.
- A map for assistants.
/llms.txtlists the site breadth-first: the organisation, your curated sections, every page with its description. - An index for depth.
/data.jsonis every entity as a Schema.org catalogue;/data.mdis the same index as a list a model reads in fewer tokens. Both take?q=for a ranked search. - Every entity is an address.
/data/<type>/<name>.jsonis the file itself;.mdbeside it is its reading. - Only what a visitor can see. Drafts, the inbox, keys and history never appear in any machine view.
Because the vocabulary is the one these systems already work in, your content needs no custom parser. A model knows a Place has a geo — it has seen millions of them.
What it costs
Structure. Content is a typed entity with fields, not free text with a title — your agent carries most of that weight. And a loam site openly declares its content may be used for search, for AI answers and for training. That stance is not configurable today: content that must be withheld from AI training does not belong on a loam site, and it is better to know that up front.