LAYERED AGENTIC RETRIEVAL: A PUBLISHING ARCHITECTURE FOR AGENT-NATIVE WEB
SURFACES
==============================================================================

Author: Francesco Marinoni Moretto

ORCID: 0009-0004-0096-4712 (https://orcid.org/0009-0004-0096-4712)

Contact: francesco.marinoni.moretto@gmail.com

Status: Working paper

Date: May 2026

------------------------------------------------------------------------------

ABSTRACT

As AI agents transition from read-only assistants to autonomous actors, the
human-readable web is failing them. Current retrofitting approaches, such as
schema.org-enhanced HTML or Retrieval-Augmented Generation (RAG), force agents
to parse unstructured or weakly-structured corpora or expend finite token
budgets on human-centric rendering pipelines. In response, a parallel
publishing layer is taking shape: major AI operators - including OpenAI,
Anthropic, Stripe, and Google - are increasingly exposing machine-legible
surfaces optimized for autonomous traversal, deterministic retrieval, and
reduced token consumption. This paper identifies and analyzes this emerging
publishing pattern as Layered Agentic Retrieval (LAR).

LAR is a publisher-side architectural commitment to surface deterministic,
machine-legible data designed explicitly for agent traversal. We articulate
LAR's three core commitments - plain-text substrates, progressive disclosure,
and workflow-organized hierarchies - and situate it within the lineages of
RESTful hypermedia and the Semantic Web. By delineating the limits of current
retrofitting approaches, this paper establishes LAR as a dedicated
institutional layer through which publishers can expose machine-legible
retrieval, policy, and operational surfaces to autonomous agents - the
structural artifact onto which cryptographic attestation attaches and on which
emerging legal provenance frameworks can operate.

Keywords: agentic commerce, agent-mediated retrieval, web architecture,
knowledge graph, semantic web, RESTful hypermedia

ABBREVIATIONS

ACP Agentic Commerce Protocol (OpenAI/Stripe).

ADK Agent Development Kit (Google).

A2A Agent2Agent (Linux Foundation, originally Google).

HATEOAS Hypermedia as the Engine of Application State (Fielding, 2000).

HAL Hypertext Application Language.

JSON-LD JSON for Linked Data (W3C).

LAR Layered Agentic Retrieval (this paper).

MCP Model Context Protocol (Anthropic, server-side).

RAG Retrieval-Augmented Generation.

RDF Resource Description Framework (W3C).

SPT Shared Payment Tokens (Stripe, used by ACP).

UCP Universal Commerce Protocol (Google + retail coalition).

WebMCP Browser-native tool exposure standard (W3C Web ML CG, distinct from
MCP).

1. INTRODUCTION

A small set of operators - OpenAI, Anthropic, Stripe, Apideck, Google's Agent
Development Kit team, WordLift, Microsoft's NLWeb group - are publishing
knowledge to AI agents in a shape that does not look like a website. The
pieces of this shape have local working names; the whole does not. This paper
proposes a name - Layered Agentic Retrieval (LAR) - and articulates the
architectural commitments that distinguish what these operators ship from
conventional web publishing or crawler-friendly retrofit.

Each of these operators publishes a separate agent-facing layer, in order to
expose content optimized for agent traversal rather than human rendering.
While this pattern is already emerging in production, the vocabulary that lets
merchants, researchers, and policy actors discuss it as a single architectural
object is missing. The paper's contribution is naming and framing, not formal
specification or benchmarking. It situates LAR in its theoretical lineage,
distinguishes it from adjacent approaches (notably Retrieval-Augmented
Generation and schema.org-enhanced HTML), and identifies the empirical and
legal questions that remain open.

2. THE PATTERN EMERGING IN PRODUCTION

OpenAI's developer documentation site exposes /codex/llms-full.txt: a single
markdown file containing the complete documentation, regenerated on every doc
update.<sup>1</sup> (#note1) Google's Agent Development Kit ships an
equivalent.<sup>2 (#note2)</sup> Apideck publishes a three-tier disclosure
pattern: /llms.txt as a summary index, /llms-full.txt as an enumerated index
of every doc page, individual .md files at each leaf, and a programmatic
md/index.json for machine traversal.<sup>3</sup> (#note3) Other developer-tool
vendors - Meteor, FastMCP, assistant-ui, Chkk, Mintlify - ship the same
shape.<sup>4</sup> (#note4) Anthropic's published skills are organised
similarly: each skill exposes its name and description in YAML frontmatter
(the manifest), with SKILL.md as the entry point and additional resources -
markdown documentation, executable scripts, and bundled assets - in
subdirectories the agent loads only when its task requires them.<sup>5</sup>
(#note5)

The surfaces<sup>6</sup> (#note6) examined here share observable structural
properties: the markdown and JSON files appear to be regenerated alongside doc
updates rather than scraped from rendered HTML. This pattern is consistent
with shared upstream source material with the human-facing artifacts, though
it does not prove it.

These concrete forms differ in their surface organisation, but three
properties recur across all of them:

Root declaration. A root surface (whether a single file or a manifest)
declares what is published and links to deeper material.

Format separation. Narrative content is held in markdown while structured
content requiring deterministic parsing is held in JSON, with the two kinds
separated rather than interleaved.

Explicit machine-resolvable links. Links between files are explicit and
machine-resolvable, allowing an agent to fetch the root, decide which subtree
its task requires, and walk down only as far as it needs - without rendering,
scraping, or inferring structure from HTML.

The protocol layer is taking shape in parallel. Microsoft's NLWeb defines how
a website exposes structured data to agents through a knowledge-graph-backed
natural language query interface.<sup>7</sup> (#note7) Google's Universal
Commerce Protocol (UCP), launched at NRF 2026, standardises commerce
capabilities across AI surfaces.<sup>8</sup> (#note8) OpenAI and Stripe's
Agentic Commerce Protocol (ACP), open-sourced in September 2025, addresses the
same transactional layer through agent-mediated execution within
conversational surfaces.<sup>9</sup> (#note9) WebMCP, a W3C Community Group
Report (latest draft 10 February 2026), exposed in early 2026 Chrome 146
preview builds behind the "Experimental Web Platform Features" flag, lets a
website declare itself as a tool surface for in-browser agents.<sup>10</sup>
(#note10)

These initiatives address different layers - site-level discovery, commerce
capability negotiation, agent-mediated transaction, browser-native tool
exposure - but share an underlying assumption: agents need surfaces designed
for them, and those surfaces will be declared, not inferred.

External infrastructure providers are operationalising this layer distinction.
Google's Search Central guidance, published 15 May 2026, explicitly states
that publishers "don't need to create new machine readable files, AI text
files, markup, or Markdown to appear in generative AI search," while a
parallel section recognising autonomous agents notes that "protocols like
Universal Commerce Protocol (UCP) are emerging that will allow Search agents
to do more."<sup>11</sup> (#note11) Cloudflare's Agent Readiness Score,
launched 17 April 2026, operationalises assessment of publisher-side agent
infrastructure across four dimensions (discoverability, content, bot access
control, capabilities) plus commerce protocols, with adoption tracked across
108,595 successfully scanned domains as of May 2026.<sup>12</sup> (#note12)
The asymmetry is informative: Google scopes its guidance to Search
optimisation while signalling that agentic experiences require different
infrastructure; Cloudflare operationalises that infrastructure with empirical
adoption data. The publisher/agent distinction LAR articulates is becoming
externally recognised in the ecosystem the paper describes.

3. THREE ARCHITECTURAL COMMITMENTS

The operators building these surfaces deliberately, rather than as accidental
byproducts of documentation tooling, share three commitments that distinguish
their output from retrofit.

Plain text instead of pages. Markdown for narrative, JSON for facts, YAML for
configuration. No DOM, no JavaScript, no rendering pipeline. An agent parses
these formats deterministically in milliseconds, with no model call required
for extraction. The llms.txt specification states the rationale directly:
context windows are too small to handle most websites in their entirety, and
converting complex HTML pages (with navigation, ads, and JavaScript) into
LLM-friendly plain text is difficult and imprecise.<sup>4</sup> (#note4)

Progressive disclosure instead of flat exposure. A manifest at the root, topic
indexes one layer down, detail files at the leaves. The agent walks the tree
to the depth its task requires and stops. Token budget is controlled by the
agent, not by the publisher's page boundaries. This is the structural inverse
of a sitemap. Anthropic's Claude Skill Design has codified this pattern as
progressive knowledge disclosure for tool packaging, where agents see only
skill names and short descriptions initially and load detailed files only when
needed.<sup>5</sup> (#note5) MajesticLabs's hierarchical-agents pattern
applies the same principle to codebase documentation.<sup>13</sup> (#note13)

Organised by workflow instead of by topic. A merchant's human site is
organised by what the merchant wants to say: about us, our story, our
products, contact. A LAR surface is organised by what the agent was tasked to
do, and the discretion the principal delegated for doing it: availability,
inventory, policies, pricing, the endpoint that commits the transaction. The
structure mirrors the agent's mandate, not the merchant's marketing.

Each commitment is explicitly stated in the documentation of the operators
cited above; what is proposed here is the framing that holds the three
together as a single architectural pattern.

The theoretical justification is the economics of the LLM context window: an
agent operating under finite token budget pays a cost proportional to every
byte loaded, and topic-organised structures force the agent to traverse
material organised around the publisher's narrative concerns before reaching
the data its task actually requires.

Workflow organisation collapses this asymmetry by aligning the structure of
the surface with the structure of agent decisions, allowing token usage to
scale with task complexity rather than with publisher verbosity.<sup>14</sup>
(#note14)

The discipline of building a good LAR surface is therefore not to design the
path the agent will follow, but to remove obstacles from every path the agent
might take. The work is to expose relevant data efficiently, without forcing
the agent through structure that reflects the publisher's mental model rather
than the agent's task.

These three commitments are what make the architecture layered rather than
retrofit, agentic rather than crawler-friendly, retrieval-shaped rather than
render-shaped.

LAR is not Retrieval-Augmented Generation. RAG is a consumer-side pattern that
retrieves probabilistically over unstructured or weakly-structured corpora to
augment generation; LAR is a publisher-side commitment to structure the source
so that retrieval can be deterministic when the consuming agent respects the
layered structure.<sup>15</sup> (#note15)

Two terms are used in this paper with deliberate distinction, doing different
work even when they describe the same artifact.

Machine-readable describes formats a machine can deterministically parse - the
standard sense established by RDF, HATEOAS, and the broader Semantic Web
tradition.

Machine-legible describes content a machine can meaningfully act upon. JSON
exposing five generic product attributes is machine-readable; JSON exposing
twenty content-rich attributes that capture provenance, occasion-fit, and
operational constraints is machine-legible.

The conceptual distinction between format and meaning has surfaced in adjacent
literature on digital product labels and Agent Experience design; the two-term
vocabulary proposed here is intended to make the distinction usable in
operator and policy discourse.

LAR commits to both: machine-readable formats (plain text, JSON) carrying
machine-legible content (workflow-organised, identity-bound,
attestation-ready).

4. THEORETICAL LINEAGE AND RECENT CONVERGENCE

Although the vocabulary proposed here is new, the pattern it names is not.
Manifest-driven traversal of linked, machine-readable resources has scholarly
lineage.

The hypermedia-driven REST architectures articulated by Fielding (2000) -
commonly known as HATEOAS - describe this shape: a client fetches a root
resource, discovers links at runtime, and traverses progressively to fulfil
its task.<sup>16</sup> (#note16) The early Semantic Web vision of Berners-Lee,
Hendler and Lassila (2001) extended the pattern to machine-readable linked
data, anticipating agents that would compose actions across distributed
semantic resources.<sup>17</sup> (#note17)

LAR is best understood as an instantiation of this lineage adapted to the
LLM-agent consumer: plain text and JSON calibrated for context-window
absorption rather than HAL or RDF, organisation by task-workflow rather than
resource-entity, consumer that performs semantic parsing on prose rather than
following typed links. The architectural innovation, where one exists, lies in
the calibration to the consumer rather than in the traversal pattern itself.

Recent practitioner thinking has converged on a parallel architectural pattern
from the consumer side. Andrej Karpathy (OpenAI founding member, former Tesla
AI Director) published his LLM Wiki sketch (2026) via a post on X and a gist
on GitHub - the genre by which influential AI thinking now first reaches the
field - describing an LLM agent ingesting a user's raw sources, compiling them
into a persistent markdown knowledge base, and maintaining it across
queries.<sup>18</sup> (#note18)

The sketch arrives at architectural decisions that overlap with LAR's
publisher-side commitments: markdown substrate, three-layer separation,
rejection of RAG as default. Karpathy's wiki is what an agent maintains for
one user's consumption; LAR is what a publisher exposes for any agent's
traversal. The convergent design choices on opposite ends of agent-mediated
information flow are the more interesting observation than the architectural
overlap itself.

A strict architectural critique might observe that the systems discussed above
operate at different layers of the software stack: llms.txt addresses
documentation discovery, MCP standardizes tool invocation, and ACP governs
transactional execution. LAR does not claim these protocols are equivalent,
nor that they require a shared implementation layer.

The claim is narrower and structural: finite-context autonomous agents create
common economic pressures across discovery, retrieval, and execution. In
response, operators are increasingly exposing machine-legible institutional
surfaces designed to reduce ambiguity, traversal cost, and rendering overhead
for autonomous systems. LAR is proposed as a publisher-side conceptual
vocabulary for understanding this convergence.

5. THE LIMITS OF RETROFIT

The dominant publisher-side approach to making content readable by agents is
structured data embedded in HTML using schema.org vocabulary, typically
expressed as JSON-LD inside <script> tags. This is the consensus enterprise
approach today: a website remains organised for human consumption, with
machine-readable annotations layered on top. Search engines, retrieval
systems, and most LLM-mediated agents can extract the structured data without
the merchant restructuring anything.

Any proposal for a distinct publisher-side architecture has to engage with one
question: why is schema.org-via-JSON-LD not enough?

A controlled experiment by Volpini and colleagues (2026) measured retrieval
accuracy across four domains - editorial, legal, travel, and e-commerce -
comparing the same structured data embedded as JSON-LD inside HTML script tags
against materialisation as agent-navigable entity pages. The materialised
version improved retrieval accuracy by 29.6% under the experimental conditions
disclosed.<sup>19</sup> (#note19) On the specific question of embedded
structured data versus materialised entity pages for agent retrieval, this is
the only direct empirical measurement we are aware of.

Adjacent evidence from tool-mediated retrieval benchmarks likewise reports
substantial performance gains for structured access over open web retrieval,
including a 71 percentage point gap in financial data retrieval tasks for a
frontier LLM agent (Kim & Huang, 2026).<sup>20</sup> (#note20) The WordLift
team frames this from the agent's perspective as Agent-Orchestrated Retrieval:
how agents traverse linked data and aggregate context across entity
boundaries.

LAR and enhanced entity pages are best understood as projections of the same
publisher-side resource: a canonical knowledge graph describing what an
institution offers, identifies, and authorises.<sup>21</sup> (#note21)

Entity pages project this graph by entity, optimising for
retrieval-by-identification - they answer the question what is this entity in
machine-readable form? LAR projects the same graph by workflow, optimising for
retrieval-by-execution - it answers what must an agent do, and in what order,
to complete a task?

The two projections share infrastructure (vocabulary, identifier schemes,
attestation primitives) and address different consumer behaviours. They are
complementary, not competitive: a publisher with a robust canonical graph can
produce both, and a sophisticated agent may consume both within the same task.

The crucial implication is that LAR is not a substitute for canonical
structuring. A merchant who builds a LAR surface without an underlying
canonical graph publishes leaf files that may be plain text and well-organised
but reference inconsistent entities, expose workflows that misalign with how
products are catalogued, and produce contradictions between the LAR surface
and the rest of the institution's data.

6. A LAR SURFACE IN CONCRETE FORM

To make the architecture concrete, consider Pelletteria Vanelli, a composite
reference architecture designed to illustrate a mid-market Florentine leather
goods merchant - third-generation, ~80 SKUs, premium artisanal positioning,
established e-commerce site, in-house digital team.<sup>22</sup> (#note22) The
human-facing site is organised the way most merchant sites are organised: a
homepage with brand storytelling, a product catalog browsable by category, an
about page, a blog. An agent visiting this site has to render JavaScript,
parse HTML, infer structure from CSS classes, and reconstruct the catalog from
page-level templates - a sequence on which agent performance against published
benchmarks remains low.<sup>23</sup> (#note23)

A LAR surface for the same business exposes a different shape. The merchant
publishes a structured manifest at /.well-known/lar.json, declares its
presence in robots.txt alongside the existing Sitemap: directive, and
references it from the HTML head of rendered pages. The manifest itself is
short and declarative; deeper material is held in linked files within the
publisher's own namespace.

A schematic example, with the discovery surface that points agents to the
manifest:

    # /robots.txt
    User-agent: *
    Allow: /
    Sitemap: https://example.com/sitemap.xml
    LAR: https://example.com/.well-known/lar.json
    
The manifest referenced by that directive resolves to the following tree (full
JSON schema in Appendix A.1):

    /.well-known/lar.json   (root manifest, JSON)
      → /lar/about.md               (brand context, narrative)
      → /lar/catalog/index.md       (product catalog)
      → /lar/availability.json      (real-time stock)
      → /lar/policies/index.md      (returns, shipping, warranty)
      → /lar/pricing.json           (current pricing by SKU)
      → /lar/checkout/spec.json     (transaction endpoint)
    
The root manifest is JSON because it carries content requiring deterministic
parsing - entity identification, operations declarations with protocol
bindings, attestation primitives, schema version. Narrative content
(institutional identity, brand context, occasion-fit prose) lives in linked
markdown files where prose is the natural format and LLM consumption is
direct. Volatile state (availability, pricing) lives in JSON or behind API
endpoints. The format-follows-purpose discipline articulated in §3 applies to
the manifest itself: each layer of the surface uses the format best suited to
its consumer. (The Identity template for the about.md layer is provided in
Appendix A.2.)

The manifest is the first thing an agent reads. It is short, declarative, and
explicit. What the agent does next depends on the task. A research task
descends into /catalog/. A purchase task descends into /availability, then
/pricing, then /checkout. A complaint task descends into /policies/. The
surface does not prescribe these paths; it enables them. Each leaf is a
structured unit that links explicitly to related leaves the agent may need.
The narrative ("artisanal Florentine craftsmanship since 1962") is preserved
in /lar/about.md for agents whose tasks require brand context. It is not in
the way of agents whose tasks do not.

The location at /.well-known/lar.json follows RFC 8615 well-known URI
conventions; the filename is offered as a working proposal anchored to the
framework name. Refinement of the canonical filename is open to community
discussion through the project repository and discussion channel referenced at
the conclusion of this paper. Adopters and reviewers are invited to
participate in convention finalization. Should community consensus converge on
an alternative within the well-known namespace, the architectural pattern
documented here applies unchanged: only the canonical filename would be
revised in subsequent versions.

LAR is not a stripping exercise. The architecture does not require removing
storytelling, brand voice, or intangibles. A surface hollowed out to its
measurable attributes would serve only the narrowest class of tasks. For every
other task - selection, comparison, contextual evaluation - the intangibles
are part of what the agent must reason about. The discipline is structuring
richness so that the agent can choose how much of it to load, not subtracting
it.

7. ARCHITECTURE AT SCALE

The reference architecture above is the smallest case: ~80 SKUs, weekly
catalog refresh, policies stable for a year. A retailer with fifty thousand
SKUs and pricing that changes every fifteen minutes cannot publish static
markdown for everything. An editorial publisher with a paywall that moves
article-by-article cannot freeze its current state into files. The
architecture has to scale across these cases without becoming three different
architectures.

It does so through a separation of concerns into three layers:

Identity is what the institution is and what it stands for: legal entity,
mission, certifications, taxonomies, and the policies (return, shipping,
privacy, citation, access) that govern operations. This layer is stable and
lives well in markdown and structured static files.

Current state is what the institution offers right now: inventory,
availability, pricing, schedule, paywall status, capacity. Its medium follows
its volatility - static JSON when data refreshes daily or weekly, API
endpoints when it refreshes by the hour or minute.

Operations is what an agent can do via the surface: purchase, subscribe, cite,
reserve, donate, apply, access. This layer declares the operations the
institution authorises and binds each operation to an endpoint capable of
executing it under a stated protocol - UCP, ACP, MCP, or proprietary. The
protocol binding is broader than conventional APIs alone. Depending on the
agent ecosystem a LAR surface is designed to serve, declared operations may
reference protocol-bound transaction surfaces (ACP, UCP), MCP-compatible tool
resources, browser-native tool declarations (WebMCP), skill bundles, or other
ecosystem-specific machine-actionable descriptors exposed under publisher
control.

The three layers are not three files. They are three concerns. A merchant in
the simplest case publishes them as three branches of a single static tree. A
merchant at scale publishes Identity as static markdown, Current State as a
small set of named API endpoints, and Operations as a declarative section in
lar.json enumerating endpoints with their protocol bindings. The same root
surface, two operationally different shapes.

Progressive disclosure applies to endpoints just as it applies to files: the
surface does not enumerate every individual product or price point at the
root. It declares the layer, declares a small set of canonical access paths,
and lets the agent unfold downward only as far as its task requires. A
retailer's current-state does not list fifty thousand SKUs in lar.json; it
declares an availability endpoint and a pricing endpoint, each serving agent
queries for specific SKUs at specific moments, with declared freshness windows
and declared governing policies. The fan-out happens at the endpoint, not in
the manifest.

This dynamic capability invites a critical architectural question: if LAR
relies on API endpoints for volatile state, how does it differ from a standard
REST API documented via OpenAPI?

The distinction lies in the institutional envelope. An OpenAPI specification
defines a technical contract: how does this endpoint work, and what is its
schema? It is optimized for human developers integrating systems ahead of
time.

A LAR surface, conversely, defines an institutional declaration. An endpoint
declared within a LAR manifest (lar.json) can be cryptographically bound to
the institution's identity and policies when the manifest includes attestation
primitives (Appendix A.1). When an agent queries a dynamic LAR endpoint for
pricing, it does not just receive a JSON response; it receives a response
governed by the policies/index.md file linked at the root, signed under the
same institutional attestation where the manifest declares one. OpenAPI tells
the agent how to execute a transaction; LAR tells the agent who is legally
authorizing the transaction and under what terms. Without this declarative
upper layer, agents are forced to rely on bespoke integrations or
probabilistically scrape human-facing interfaces - approaches that fail to
scale across the long tail of internet merchants.

For merchants already publishing OpenAPI specifications, LAR sits above them
as the institutional layer: existing API contracts continue to govern
technical execution, while the manifest declares institutional authorisation
and policy binding.

8. OPEN QUESTIONS

LAR is an emerging pattern, not a settled standard. Several questions are
unresolved.

Empirical questions.

Empirical task-success benchmarks. Volpini and colleagues measured retrieval
accuracy on entity pages.<sup>19</sup> (#note19) Existing agent web-navigation
benchmarks - WebArena (Zhou et al., 2023) and Mind2Web (Deng et al., 2023) -
provide methodological precedent for the agent task harness; what they do not
provide is the publishing-side comparison: retrofit HTML, schema.org/JSON-LD
entity pages, and workflow-organised LAR evaluated across shared agent
tasks.<sup>23</sup> (#note23) While this paper provides the foundational
architectural framing, empirical validation against retrofit baselines remains
open. A planned field study (Marinoni Moretto & Antichi, forthcoming 2026),
conducted in partnership with digital strategy firm Advertaria, will measure
token-efficiency and agent task-success on a cohort of mid-market Italian
e-commerce merchants.<sup>24</sup> (#note24) Benchmark results will be
published in subsequent revisions of this working paper.

Falsifiability. The claim that LAR represents an emerging architectural
pattern is testable. It would be disconfirmed by operator divergence on basic
shape (manifest plus linked files plus workflow-organisation), retraction
rather than expansion of publishing surfaces over time, or empirical evidence
that retrofit retrieval consistently outperforms structured publication for
agent task completion.

Coordination questions.

Manifest standardisation. Several discovery formats are circulating in
parallel: llms.txt as a documentation-style index, MCP server manifests for
backend tool exposure, A2A agent cards (now under Linux Foundation
governance), NLWeb's site-level conversational interface, WebMCP's
browser-native tool declaration, ACP's agent-mediated commerce flow, UCP's
commerce-specific manifest, and .well-known/agent.json as a generic root
pointer. The unresolved operational question is whether merchants will need a
single manifest serving all agent types, two or three complementary manifests,
or a separate manifest for each ecosystem they need to be visible in. Movement
at the W3C and GS1 levels suggests some convergence around commerce-specific
structured data is underway, but adoption pressure will set the pace as much
as formal specification work.

Discovery mechanism. The location at /.well-known/lar.json does not, by
itself, render the manifest discoverable: agents must know the filename in
advance. For the convention to reach agents without prior framework knowledge,
the manifest can be referenced from surfaces agents already scan. Three
complementary mechanisms are available: a LAR: directive in robots.txt
(analogous to the existing Sitemap: convention), a <link rel="lar"> in the
HTML head of rendered pages (aligned with adjacent proposals such as Vercel's
<script type="text/llms.txt"> and Marro et al.'s <link
rel="agent-permissions">), and a cross-reference from /llms.txt where present.
Each mechanism reaches a different class of agent (crawler-class,
HTML-rendering, llms.txt-aware); empirical observation will inform which gains
traction. Discovery mechanism is open for community refinement.

Layered architecture vocabulary. The terminology of "layered architecture" for
agent systems has accumulated several distinct uses. Huang's seven-layer
reference architecture (Springer 2025) decomposes the internal agent stack
from foundation models to ecosystem deployment.<sup>25</sup> (#note25) Fleming
et al. (2025) propose Agent Communication (L8) and Agent Semantic (L9) layers
as protocol extensions above OSI transport.<sup>26</sup> (#note26) Liang's
seven-layer compute model (2025) frames AI computation across
hardware-to-application strata.<sup>27</sup> (#note27) LAR addresses a
different scope: publisher-side institutional declarations for agents arriving
without prior context, organised by workflow layer rather than by
infrastructure stratum or protocol hierarchy. The shared vocabulary reflects a
broader recognition that agentic systems require multiple coordinated layers;
the layers in question differ in nature.

Trust questions.

Liability and provenance. A versioned, signed, timestamped LAR surface is a
legal artifact in a way that scraped HTML is not. The EU AI Act's Article 50
imposes transparency obligations on providers and deployers of certain AI
systems - including any agent-style system that interacts directly with users
or generates synthetic content - and becomes applicable on 2 August 2026.
Italy's Legge 34/2026 (Articles 18-23, in force 7 April 2026) establishes
lawfulness criteria, traceability requirements, and a removal regime for
online reviews of restaurants, hotels, and tourist attractions, enforced by
AGCM and AGCOM; while its scope is restaurant- and tourism-specific, it is an
early instance of statutory obligations attaching to the publishing layer of
consumer-facing platforms. The U.S. FTC's Operation AI Comply, launched 25
September 2024, has applied Section 5 authority to AI-mediated commercial
claims. None of these regimes mandates LAR specifically; what they raise is
the question of what evidence a merchant can produce of what they actually
authorised an agent to act upon. The legal distinction between declaring a
surface and contractually attesting to a transaction at an endpoint is not yet
tested in case law. The technical infrastructure for signing and versioning
LAR surfaces exists (Web Bot Auth, HTTP Message Signatures);<sup>28</sup>
(#note28) the legal frameworks operating on top are early.

Revocation under loss of control. A merchant who signs a surface and later
loses control of the domain, signing key, or publishing infrastructure cannot
revoke the surface by publishing a new one - the channel for revocation has
been compromised along with the channel that needed revoking. The established
remedies (CRLs, OCSP, key revocation registries, Certificate Transparency
append-only logs) all rely on a channel separate from the one whose validity
is being revoked. Where the out-of-band channel for LAR lives, who maintains
it, and how an agent verifying a surface knows to consult it are questions the
architecture does not currently answer.

Verification at the leaf. A manifest can be deterministic without the content
at its leaves being trustworthy. An agent that walks a LAR surface to a leaf
containing fabricated, outdated, or unverified claims still ends with a bad
decision. Anthropic's Project Deal (April 2026), which observed Claude agents
negotiating on behalf of human principals, documented agents confabulating
personal details about their principals during extended exchanges; the authors
note explicitly that such confabulations "illustrate the potential risks of
implementing a system like this in a non-experimental setting without
additional safeguards."<sup>29</sup> (#note29) The architectural question of
how to sign and version what a LAR surface publishes is therefore inseparable
from the editorial question of what the agent reading it is permitted to add,
omit, or invent on its principal's behalf.

Runtime questions.

State management at the endpoint. LAR is a publishing pattern; it does not
specify the runtime semantics of the endpoints it declares. High-velocity
commerce introduces concerns the publishing layer does not address - quote
generation with finite validity, inventory locks during agent deliberation,
idempotency tokens for retried transactions, session continuity across
multi-step workflows. An agent that reads pricing.json at one moment and
submits a transaction fifteen minutes later may face flash-sale expiry, stock
depletion, or policy revision in the interval. These are protocol-level
concerns (UCP, ACP, MCP, or proprietary commerce protocols handle quote and
lock semantics) but their integration with LAR-declared endpoints - how a
surface declares which endpoints provide quote semantics, what freshness
windows agents can rely on, when re-reading the surface is required - is not
formalised. This is among the most consequential unresolved areas for
production e-commerce adoption. Agent-side behavioural questions follow from
this: how an agent detects a stale or incomplete surface, when it falls back
to direct endpoint queries or to alternative sources, and how it signals
reduced confidence to its principal - are equally unresolved. The reference
examples adopt a working as_of + freshness_window_minutes convention on every
volatile file; whether this becomes the canonical declaration mechanism
remains open for community refinement.

9. CONCLUSION

The web is entering a transitional phase in which human-facing interfaces
increasingly coexist with parallel machine-legible surfaces designed for
autonomous systems. The forms of these surfaces remain unsettled, fragmented,
and vendor-specific. Yet across heterogeneous ecosystems, similar structural
responses are emerging: manifest-driven discovery, progressive disclosure,
workflow-oriented organization, and deterministic machine-readable retrieval.

This paper proposes Layered Agentic Retrieval (LAR) as a conceptual vocabulary
for describing that transition. The pattern's architectural commitments -
plain text, progressive disclosure, workflow-organised hierarchy - distinguish
it from both retrofit and from probabilistic retrieval; its lineage in RESTful
hypermedia and the Semantic Web situates it within decades of prior work on
agent-readable resources.

Whether it converges on a single canonical shape, several adjacent shapes, or
fragments further is an empirical question whose answer will be set by
adoption and by the empirical research the open questions above invite. The
terminology proposed here is offered to operators who need shared vocabulary
now, regardless of whether formal specification follows.

The convention proposed in this paper is intentionally minimal in its v1
articulation. The canonical filename (/.well-known/lar.json), the JSON Schema
for the manifest, the discovery mechanism, and several other operational
details are deliberately left open for community input. The project repository
at github.com/lar-spec/lar (https://github.com/lar-spec/lar) hosts ongoing
discussion; refinement consensus reached during the open review period will be
integrated into subsequent versions of this paper. Empirical validation of
these commitments is planned in partnership with Italian mid-market merchants
(Marinoni Moretto & Antichi, forthcoming 2026).

AUTHOR'S NOTE & DISCLOSURES

This paper develops material that appears, in different form, in an appendix
to the forthcoming book Selling to Agents: The Merchant Playbook for Agentic
Commerce by the same author. The standalone version published here is released
under CC BY-SA 4.0; the book version is under standard commercial copyright.
The two are not identical: this paper is structured for academic and
practitioner discussion, with adapted introduction, abstract, and citation
form.

NOTES

<span id="note1" class="anchor"></span>1. OpenAI Platform Documentation,
/codex/llms-full.txt (https://developers.openai.com/codex/llms-full.txt),
accessed April 2026.

<span id="note2" class="anchor"></span>2. Google Agent Development Kit
Documentation (https://google.github.io/adk-docs/llms-full.txt), llms-full
export, accessed April 2026.

<span id="note3" class="anchor"></span>3. Apideck Developer Documentation
(https://developers.apideck.com/llms.txt), llms.txt + llms-full.txt +
md/index.json structure, accessed April 2026.

<span id="note4" class="anchor"></span>4. Howard, J. (2024) "The /llms.txt
file" (https://llmstxt.org/) specification proposal. Production
implementations surveyed include Meteor, FastMCP, assistant-ui, Chkk,
Mintlify.

<span id="note5" class="anchor"></span>5. Anthropic Claude Skills
documentation (https://www.anthropic.com/news/skills), accessed April 2026.
The "progressive knowledge disclosure" framing is documented in Claude Skill
Design materials and the broader MCP ecosystem.

<span id="note6" class="anchor"></span>6. Throughout this paper, surface
refers to the publication artefact an institution exposes for agent
consumption - the structured, machine-readable representation of what is
offered, under which terms, with which capabilities for interaction, rendered
machine-legible by workflow-organised content that an agent can act upon. The
concept is independent of the canonical filename: the architecture of the
surface (root manifest with linked deeper material, format-follows-purpose,
workflow-organised hierarchy) is invariant whether the canonical file is named
lar.json, agent-surface.json, or another community-determined alternative
within the well-known namespace. This usage of "surface" is also distinct from
adjacent senses of the term established in agent-payment protocols, where it
denotes a UI role (e.g., AP2's "Trusted Surface" as the interface trusted to
obtain user consent for transaction mandates, or "agent surface" as in
OpenAI/Google parlance for consumer-facing AI assistants). The two usages are
complementary rather than competing: a publication surface (LAR) is what an
institution exposes; a transaction surface (AP2/UCP/ACP terminology) is where
an agent acting on a principal's behalf interacts with the user. Both senses
share the underlying intuition of "surface" as a thin layer of declared
interaction, but at different levels of the agent-mediated commerce stack. A
separate practitioner project at agentsurface.dev (Howells, 2026) uses "Agent
Surface" as a scoring framework for codebase agent-readability; its scope
(audit of existing codebases) is distinct from the publisher-side
institutional declaration scope of LAR.

<span id="note7" class="anchor"></span>7. Microsoft NLWeb initiative
(https://blogs.microsoft.com/blog/2025/05/19/introducing-nlweb-bringing-conversational-interfaces-directly-to-the-web/),
accessed April 2026.

<span id="note8" class="anchor"></span>8. Universal Commerce Protocol (UCP),
Google + retail coalition, announced 11 January 2026 at NRF
(https://blog.google/products/shopping/universal-commerce-protocol-google/).
Co-developed with Shopify, Etsy, Wayfair, Target, Walmart; endorsed by 20+
additional partners. Specification at ucp.dev (https://ucp.dev). Compatible
with Agent Payments Protocol (AP2), Agent2Agent (A2A), and Model Context
Protocol (MCP).

<span id="note9" class="anchor"></span>9. Agentic Commerce Protocol (ACP),
OpenAI + Stripe, announced 29 September 2025
(https://stripe.com/newsroom/news/stripe-and-openai-introduce-agentic-commerce-protocol).
Apache 2.0 license; specification at agenticcommerce.dev
(https://www.agenticcommerce.dev/). Uses Shared Payment Tokens for
credential-free agent-mediated transactions. Acronym disambiguation: this
paper uses "ACP" exclusively for the OpenAI/Stripe commerce protocol; an
unrelated protocol with the same acronym (IBM BeeAI's Agent Communication
Protocol) has been formally merged into Google's Agent2Agent (A2A) under the
Linux Foundation umbrella.

<span id="note10" class="anchor"></span>10. WebMCP, W3C Web ML Community Group
Draft Community Group Report (https://webmachinelearning.github.io/webmcp/)
(latest draft 10 February 2026). Early 2026 Chrome 146 preview builds exposed
WebMCP behind the "Experimental Web Platform Features" flag, with subsequent
Edge experimentation reported in ecosystem documentation. Defines
navigator.modelContext as a browser-native API where the page itself acts as a
tool surface for in-browser agents - distinct from Anthropic's server-side
MCP. As a Community Group Report, WebMCP is not on the W3C Recommendation
track.

<span id="note11" class="anchor"></span>11. Google, "Optimizing your website
for generative AI features on Google Search." Search Central documentation,
last updated 15 May 2026. Available at:
<https://developers.google.com/search/docs/fundamentals/ai-optimization-guide>.
Quoted passages from "Mythbusting" section (subsection "LLMS.txt files and
other 'special' markup") and "Explore agentic experiences" section.

<span id="note12" class="anchor"></span>12. Jesus, A. & Morrison, V. (2026).
"Measure your website's agent readiness, score from 0 to 100, and improve it."
Cloudflare Blog, 17 April 2026. Available at:
<https://blog.cloudflare.com/agent-readiness/>. The Agent Readiness scoring
framework and its four-dimension methodology are documented in the blog post;
the live measurement dashboard at <https://radar.cloudflare.com/ai-insights>
publishes weekly-updated adoption data; underlying definitions and methodology
are in the Cloudflare Radar Glossary,
<https://developers.cloudflare.com/radar/glossary/>. The 108,595 domains
figure cited in the body text is a dashboard snapshot reading from May 2026
and is time-sensitive; subsequent values are accessible at the live dashboard.

<span id="note13" class="anchor"></span>13. MajesticLabs, hierarchical-agents
skill (https://lobehub.com/skills/majesticlabs-hierarchical-agents), 2026
(LobeHub Skills Marketplace). Generates root and sub-folder AGENTS.md files
with nearest-wins resolution and just-in-time indexing.

<span id="note14" class="anchor"></span>14. Empirical validation of the
context-window economics motivating workflow-organised structure has
accumulated since this paper was drafted. Pinecone reports in its
KRAFTBench/Nexus launch materials (Zhu & Ragavan, "Better Models Won't Save
Your Agent," Pinecone Blog, 4 May 2026,
<https://www.pinecone.io/blog/introducing-nexus-knowledge-engine/>), comparing
three retrieval strategies on 150 questions over 493 S&P 500 10-K filings,
that compiled-knowledge artifacts reduced average token use from 49,103
(agentic RAG) and 528,301 (coding-agent baseline) to 6,733 - a 7× and 80×
multiplier respectively - alongside latency and task-completion gains. These
are vendor benchmark results, not independent replication. The benchmark
targets consumer-side enterprise compilation (Pinecone Nexus knowledge
engine), not publisher-side declaration, but the underlying economic argument
- that pre-compiled, workflow-shaped knowledge structures collapse token cost
by orders of magnitude relative to retrieval-time assembly - applies
symmetrically across both sides of the agent's information boundary. Microsoft
(Fabric IQ, FabCon March 2026), Google (Knowledge Catalog, April 2026), and
Pinecone (Nexus, May 2026) shipped enterprise consumer-side knowledge
compilation infrastructure during this paper's final preparation, confirming
the broader category while operating on a different architectural layer than
LAR's publisher-side scope.

<span id="note15" class="anchor"></span>15. The distinction: RAG performs
probabilistic retrieval over an unstructured or weakly-structured corpus to
provide context for generation. LAR is the publishing pattern that creates the
conditions for deterministic retrieval by structuring the source. The two are
complementary at the system level - an agent might use RAG over a
weakly-structured corpus and direct LAR retrieval over a well-structured one
in the same workflow - but they are categorically distinct as architectural
commitments of the publisher.

<span id="note16" class="anchor"></span>16. Fielding, R. T. (2000).
Architectural Styles and the Design of Network-based Software Architectures.
Doctoral dissertation, University of California, Irvine. Available at:
<https://ics.uci.edu/~fielding/pubs/dissertation/top.htm>.

<span id="note17" class="anchor"></span>17. Berners-Lee, T., Hendler, J., &
Lassila, O. (2001). "The Semantic Web." Scientific American, 284(5), 34-43.
DOI: 10.1038/scientificamerican0501-34
(https://doi.org/10.1038/scientificamerican0501-34). Available at:
<https://www.scientificamerican.com/article/the-semantic-web/>.

<span id="note18" class="anchor"></span>18. Karpathy, A. (2026) "LLM Knowledge
Bases," tweet of 3 April 2026, followed by GitHub Gist llm-wiki.md
(https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) (archived
at
<https://web.archive.org/web/2026*/https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f>).
Three-layer architecture: raw/ (immutable user sources) + wiki/
(LLM-maintained markdown pages) + CLAUDE.md or AGENTS.md (schema). The pattern
lineage cited by Karpathy is Vannevar Bush's Memex (1945).

<span id="note19" class="anchor"></span>19. Volpini, A., Raad, E., Gamba, B.,
& Riccitelli, D. (2026) "Structured Linked Data as a Memory Layer for
Agent-Orchestrated Retrieval." arXiv preprint 2603.10700v1, March 2026.
Available at: <https://arxiv.org/abs/2603.10700>. The +29.6% retrieval
accuracy improvement is measured across editorial, legal, travel, and
e-commerce domains using Vertex AI Vector Search 2.0 for retrieval and the
Google Agent Development Kit (ADK) for agentic reasoning. Ground-truth answers
are derived from the same knowledge graph used for enhancement, a
methodological caveat the authors disclose.

<span id="note20" class="anchor"></span>20. Kim, E. Y. & Huang, J. (2026).
"FinRetrieval: A Benchmark for Financial Data Retrieval by AI Agents." arXiv
preprint 2603.04403, January 2026. Available at:
<https://arxiv.org/abs/2603.04403>. Reports a 71 percentage point gap (90.8%
versus 19.8%) for Claude Opus 4.5 accessing structured financial data via
Model Context Protocol versus web search alone, across 500 financial retrieval
questions and 14 agent configurations spanning Anthropic, OpenAI, and Google
frontier models. Authors are employed by Daloopa (disclosed in Section 7.3 of
the cited paper). The paper decomposes the headline gap into approximately
equal behavioural and infrastructure components (Section 5.3, Finding A). The
scope differs from Volpini et al. (note 19) - measuring tool-mediated
structured access rather than publishing format - but the directional finding
(structured retrieval substantially outperforming unstructured retrieval for
agents) is supported across both layers.

<span id="note21" class="anchor"></span>21. Interpretive framing from
pre-publication review: Andrea Volpini (WordLift) articulated the relationship
between enhanced entity pages and LAR as peer projections of a single
canonical knowledge graph - by entity and by workflow respectively. This is
interpretive input from a technical reviewer with adjacent published work, not
external published evidence. Disclosure: Volpini and his team at WordLift
authored the controlled experiment cited at note 19; no commercial
relationship between this author and WordLift; integration of Volpini's
framing into this work was at the author's editorial discretion.

<span id="note22" class="anchor"></span>22. Pelletteria Vanelli, the composite
Florentine leather goods merchant referenced throughout §6, is constructed for
illustrative purposes, drawing on observable patterns across artisanal Italian
e-commerce (third-generation family operations, sub-100 SKU catalogs, premium
artisanal positioning, in-house digital teams) without representing any single
existing business. Composition rather than direct case study allows
architectural illustration without exposing a specific merchant's operational
data or commercial relationships.

<span id="note23" class="anchor"></span>23. Zhou, S. et al. (2023). "WebArena:
A Realistic Web Environment for Building Autonomous Agents." arXiv:2307.13854.
Available at: <https://arxiv.org/abs/2307.13854>. Reports a 14.41% end-to-end
task success rate for the best GPT-4-based agent against 78.24% human
performance on 812 long-horizon tasks. Deng, X. et al. (2023). "Mind2Web:
Towards a Generalist Agent for the Web." NeurIPS 2023 Datasets and Benchmarks
Track. Available at: <https://arxiv.org/abs/2306.06070>. Comprises 2,000+
open-ended tasks across 137 websites in 31 domains. Both benchmarks evaluate
agent performance over agent-naïve human-facing surfaces; neither evaluates
against agent-native publishing alternatives.

<span id="note24" class="anchor"></span>24. Marinoni Moretto, F., & Antichi,
F. (Forthcoming 2026). Empirical Benchmarking of Layered Agentic Retrieval
(LAR) Surfaces in Mid-Market E-commerce Environments.

<span id="note25" class="anchor"></span>25. Huang, K. & Huang, J. (2025). "AI
Agent Tools and Frameworks." In Huang, K. (Ed.), Agentic AI. Springer
(Progress in IS series), pp. 23-50. DOI: 10.1007/978-3-031-90026-6_2
(https://doi.org/10.1007/978-3-031-90026-6_2). Available at:
<https://link.springer.com/chapter/10.1007/978-3-031-90026-6_2>. The
seven-layer reference architecture decomposes the agent stack from Foundation
Models (Layer 1) through Data Operations, Agent Frameworks, Deployment
Infrastructure, Evaluation, Security, to Agent Ecosystem (Layer 7). Adopted by
the Cloud Security Alliance as the basis of the MAESTRO threat-modeling
framework.

<span id="note26" class="anchor"></span>26. Fleming, C., Pandey, V., Kompella,
R., & Muscariello, L. (2025). "A Layered Protocol Architecture for the
Internet of Agents." arXiv preprint 2511.19699. Available at:
<https://arxiv.org/abs/2511.19699>. Proposes Agent Communication Layer (L8)
and Agent Semantic Layer (L9) as additional layers above the OSI/TCP-IP
application transport. L8 standardises message envelopes, speech-act
performatives, and interaction patterns; L9 establishes shared semantic
context discovery, negotiation, and grounding before task execution.

<span id="note27" class="anchor"></span>27. Liang, B.-S. (2025). "AI Compute
Architecture and Evolution Trends." arXiv preprint 2508.21394. Available at:
<https://arxiv.org/abs/2508.21394>. Proposes a seven-layer model spanning
Physical Layer, Link Layer, Neural Network Layer, Context Layer, Agent Layer,
Orchestrator Layer, and Application Layer for AI compute infrastructure.

<span id="note28" class="anchor"></span>28. Web Bot Auth (IETF Internet-Draft,
available at:
<https://datatracker.ietf.org/doc/draft-meunier-web-bot-auth-architecture/>)
and HTTP Message Signatures (RFC 9421, available at:
<https://www.rfc-editor.org/rfc/rfc9421>) provide the cryptographic
primitives. Their integration with publisher liability frameworks is an open
research question across the broader literature on AI commerce regulation.

<span id="note29" class="anchor"></span>29. Troy, K., Shields, D., Bradwell,
K., & McCrory, P. (2026). "Project Deal: Our Claude-run Marketplace
Experiment." Anthropic, posted April 24, 2026. Available at:
<https://www.anthropic.com/features/project-deal>. The quoted sentence is
drawn from footnote 14 of the published study. As a publishing artifact, the
page is also illustrative of the retrieval and verification friction this
paper addresses: citation metadata and links to underlying materials are
nested within a long-form human-readable page, while the linked PDFs are
served from a CDN whose robots.txt disallows PDF crawling (Disallow: /\.pdf;
Disallow: /\.PDF). For compliant agents, this increases the traversal cost of
primary-source verification and citation relative to a dedicated
machine-legible publication surface.

APPENDIX A: INITIAL SCHEMA PROPOSAL (V0.1 DRAFT)

A.1 JSON SCHEMA FOR CANONICAL MANIFEST

The following schema defines the structural requirements for the
/.well-known/lar.json discovery document.

    {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "title": "Layered Agentic Retrieval (LAR) Manifest",
      "description": "Root discovery document declaring agent-navigable surfaces, capabilities, and institutional attestations.",
      "type": "object",
      "required": ["lar_version", "publisher", "identity", "current_state", "operations"],
      "properties": {
        "lar_version": {
          "type": "string",
          "description": "Version of the LAR specification (e.g., '0.1')."
        },
        "publisher": {
          "type": "object",
          "required": ["name", "domain"],
          "properties": {
            "name": { "type": "string" },
            "domain": { "type": "string", "format": "hostname" },
            "legal_entity_id": { "type": "string", "description": "Optional LEI or local tax identifier for compliance." }
          }
        },
        "identity": {
          "type": "string",
          "format": "uri-reference",
          "description": "URI to the root Markdown document containing institutional identity, brand context, and narrative."
        },
        "catalog": {
          "type": "string",
          "format": "uri-reference",
          "description": "URI to the static product/service catalog tree."
        },
        "current_state": {
          "type": "object",
          "description": "Pointers to volatile state endpoints or files.",
          "properties": {
            "availability": { "type": "string", "format": "uri-reference" },
            "pricing": { "type": "string", "format": "uri-reference" }
          }
        },
        "operations": {
          "type": "object",
          "description": "Declared transactional endpoints authorized by the publisher.",
          "patternProperties": {
            "^[a-zA-Z0-9_-]+$": {
              "type": "object",
              "required": ["endpoint", "protocol"],
              "properties": {
                "endpoint": { "type": "string", "format": "uri-reference" },
                "protocol": {
                  "type": "string",
                  "enum": ["ACP", "UCP", "MCP", "WebMCP", "A2A", "OpenAPI", "Proprietary", "Other"],
                  "description": "The execution protocol the endpoint expects."
                },
                "spec": {
                  "type": "string",
                  "format": "uri-reference",
                  "description": "Optional URI to OpenAPI/Swagger spec detailing the endpoint payload."
                }
              }
            }
          }
        },
        "policies": {
          "type": "object",
          "description": "URIs to governing policies under which operations are authorized.",
          "properties": {
            "terms": { "type": "string", "format": "uri-reference" },
            "returns": { "type": "string", "format": "uri-reference" },
            "privacy": { "type": "string", "format": "uri-reference" }
          }
        },
        "attestation": {
          "type": ["object", "null"],
          "description": "Cryptographic signature verifying the integrity and authorization of the manifest and its linked tree.",
          "properties": {
            "method": { "type": "string", "enum": ["WebBotAuth", "HTTPMessageSignature"] },
            "timestamp": { "type": "string", "format": "date-time" },
            "signature": { "type": "string" },
            "public_key_uri": { "type": "string", "format": "uri" }
          }
        }
      }
    }
    

A.2 IDENTITY TEMPLATE (ABOUT.MD)

The structural template ensuring token-efficient institutional context
separation.

    # [Institution Name] - Institutional Identity & Context
    **LAR Surface Version:** [Version]
    **Last Updated:** [ISO-8601 Date]
    **Canonical Manifest:** [URL to lar.json]
    
    ## 1. Core Identity
    *   **Legal Name:** [Full Legal Name]
    *   **Operating Name:** [DBA / Brand Name]
    *   **Primary Jurisdiction:** [Country/State]
    *   **Registration/Tax ID:** [ID Number]
    *   **Primary Domain:** [Domain]
    *   **Contact for Agent Operators:** [Dedicated Email/Endpoint]
    
    ## 2. Institutional Context (Narrative)
    *Note for Agent: This section provides semantic context for brand positioning, target audience, and quality standards. Use this to calibrate conversational tone or product recommendations.*
    
    [2-3 paragraphs of dense, high-signal prose explaining the institution's history, value proposition, and market positioning. NO marketing filler.]
    
    ## 3. Operational Guarantees & Certifications
    *   **Certifications:** [e.g., ISO 9001, B-Corp, Fair Trade]
    *   **Manufacturing/Sourcing Origin:** [e.g., 100% made in Italy]
    *   **Quality Standard:** [Brief description of warranty or quality floor]
    
    ## 4. Policy Pointers
    *Note for Agent: Do not hallucinate policies. Always resolve the following endpoints for deterministic policy constraints prior to generating a transaction quote.*
    *   **Terms of Service:** [Relative link to terms.md]
    *   **Shipping & Fulfillment:** [Relative link to shipping.md]
    *   **Returns & Refunds:** [Relative link to returns.md]