Layered
Agentic
Retrieval
An agent can read what your site says.
It can't tell what's live, which protocol your checkout speaks, or who stands behind the endpoint.
lar.json declares what an agent can do here — read as a short stack, each layer conditioning the next.
A proposal, not a product. It names a convergence operators are reaching independently, and it is offered to the commons to be forked, renamed, reshaped, or absorbed into an adjacent standard. The goal is the convention existing, not anyone owning it.
{ "lar_version": "0.1", "publisher": { "name": "Francesco Marinoni Moretto", "domain": "lar.md" }, "identity": "/lar/about.md", "operations": { … } }
curl -sL https://lar.md/.well-known/lar.json
The line above fetches this site's live manifest; the card shows its shape. This page is a LAR surface.
Three walls, none about what the site knows
An agent acting on a principal's behalf reaches an institution's site and hits three operational walls. They are about what the agent can safely do.
Live or stale?
It reads a price or a stock level and can't tell whether it's live or a cached snapshot from last week.
The transaction is built on a number nobody guaranteed was current.
Which protocol?
It finds an action — checkout, reserve, donate — but can't tell which protocol it speaks.
Every site becomes a custom integration, which means most never get one.
Who is on the other side?
It's about to transact but can't verify the institution behind the endpoint.
A certificate proves the domain, not the institution or its authority to act.
A manifest read as a descent
Discovery is the precondition — a well-known URI, a robots.txt directive, a <link>. Once found, the manifest is read top to bottom: each layer conditions the agent's standing to rely on the next.
Identity grounds state grounds action
Who the institution is, what is true right now, and what an agent may do — with policies governing the operations.
Verify before acting
Validators an agent can cross-check independently, and Attestation over the manifest itself. Both are early; most publishers carry neither today.
Sector-specific leaves
catalog for commerce, context for knowledge-heavy publishers, impact for nonprofits. They must not redefine Core or Trust.
The same request, with and without the manifest
- ·It infers the price from the DOM and hopes it's current.
- ·It guesses the action's protocol from form fields and link text.
- ·It treats the TLS certificate as proof of who you are.
Three inferences, none guaranteed.
The safe move is to not act.
- →It reads
current_statefor a timestamped price the publisher stands behind. - →It reads
operationsfor the named protocol the checkout speaks. - →It reads
validatorsit can cross-check before transacting.
The inferences become reads.
The agent can act, or decline, for stated reasons.
Where the value is real today — and where it isn't yet
LAR is not equally useful everywhere. The Core layer carries weight now; the Trust layer that high-stakes actions depend on is still experimental.
| Use case | What the manifest carries | Maturity |
|---|---|---|
| Commerce checkout | operations names the protocol; catalog and current_state give a price the publisher stands behind. |
Real today |
| Citing a knowledge source | context and current_state let an agent cite what is true now, not a cached page. |
Real today |
| Reserving or booking | operations for the action, current_state for availability. |
Plausible |
| Donations and impact | The impact extension plus operations for donate. |
Plausible |
| Regulated, high-stakes actions | Needs validators and attestation to verify authority — the Trust layer. |
Not yet |
The mechanism is borrowed, not invented
LAR reuses conventions that already work in the field.
Well-Known URIs
/.well-known/ is the established place for machine-readable site metadata — the same mechanism behind security.txt and ACME. lar.json sits beside them, nothing new to register.
A resolvable identifier
A standard for a single identifier that resolves to structured information about a product. Precedent for a publisher-side, machine-resolvable description of what an entity is and offers.
The simplest thing you can do today
No working group required. Publish one file, then point to it.
Serve a Core manifest at the well-known path. Identity, current state, and operations is enough to be useful.
/.well-known/lar.json
Announce it in robots.txt and from your pages so agents discover it.
# What agents can do here: # /.well-known/lar.json
<link rel="lar" href="/.well-known/lar.json">