---
"@type": Article
"@id": "https://helloloam.dev/principles/ai-compatibility"
"@source": "https://helloloam.dev/data/article/ai-compatibility.json"
"@stamp": "2026-10-22T21:53:55+00:00"
about:
  "@type": DefinedTerm
  "@id": "https://helloloam.dev/data/definedterm/ai-compatibility.json"
  name: AI compatibility at its core
  identifier: ai-compatibility
  inDefinedTermSet:
    "@type": DefinedTermSet
    "@id": "https://helloloam.dev/data/definedtermset/gives-any-site.json"
    name: Gives any site
    identifier: gives-any-site
author: {"@id":"https://helloloam.dev/#organization"}
datePublished: "2026-10-03"
description: Any agent can read and work on a loam site without a connector, a plugin or a special interface. Not a feature bolted on — the test every part has to pass.
headline: AI compatibility at its core
identifier: ai-compatibility
inLanguage: en
publisher: {"@id":"https://helloloam.dev/#organization"}
url: "https://helloloam.dev/principles/ai-compatibility"
---

# AI compatibility at its core

## A test, not a feature

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. “Can an agent read this without help?” sorted every design decision:

| To… | Needs help | Needs none |
| --- | --- | --- |
| **read the content** | a database, through a query layer | files |
| **understand the model** | a custom model, through its manual | Schema.org |
| **change the content** | an admin panel, a second path | the files directly |
| **learn how it works** | a manual somewhere else | the docs, through the same door |

Each time, the answer that needed no help was also the simpler one.

## One shape, many readers

The live data is [Schema.org JSON-LD](/principles/schema-as-data). 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. 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.

## How a machine reads a site

Breadth first, then depth, then the one file:

- **A map.** `/llms.txt` lists the site breadth-first: the organisation, your curated sections, every page with its description.
- **An index.** `/data.json` is every entity as a Schema.org catalogue; `/data.md` is the same index as a list a model reads in fewer tokens. Both take `?q=` for a ranked search.
- **The file.** `/data/<type>/<name>.json` is the entity itself, for code; `.md` beside it is its reading, for a mind.

An agent with a key goes one step further: [through the MCP](/principles/mcp-with-a-trust-model) it also reads the site's own rules and the documentation of the engine it is talking to.

## Only what a visitor can see

Every machine view reads the live site. Drafts, the form inbox, keys and history never appear in any of them: a machine sees exactly what a visitor can see, in a form it reads faster.

## Built to last

Interfaces age; files and a public vocabulary do not. A loam site made today will be readable by whatever assistant exists in ten years — and managed by it, because the agent works on the same files a developer would.

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