River CadeConcepts
Menu

Agent Presence · version 0.2

A business should be able to state what it is, in a form a machine can read and a person can check.

Search engines gave businesses a way to be found. Nothing gave them a way to be answered — to publish an account of themselves that an AI assistant reads instead of inferring, and to receive a question from an agent acting for a customer without a machine improvising on their behalf.

Agent Presence is a small scheme for that: four documents at fixed URLs, one rule about what may be claimed, and a set of refusals that are part of the specification rather than a deployment choice. It is published because it is implemented. Four public domains serve every document below, and every claim on this page can be re-run by opening a URL.

The document set

Each is served from the business’s own canonical domain, over HTTPS, at a fixed path.

  • Site-root pointer — /llms.txt (text/plain)

    A pointer at the front door, for an agent that does not already know the /.well-known convention. It names where the business's own account of itself lives.

  • Business record — /.well-known/ard.json (application/json)

    A machine-readable statement of what the business is. It conforms to the external Agentic Resource Discovery draft, and it is a pointer, not the authority.

  • Capability catalog — /.well-known/business-capabilities.json (application/json)

    What the business actually does. Each capability carries evidence: a claim id, the claim's value, and the source URLs it came from. This document is the authority.

  • Interaction surface — /.well-known/agent-interaction.json (application/json)

    How an agent may ask this business something, on the business's own terms: the endpoint, the authorization scheme, the idempotency contract, and what the business will never do.

A 200 is not a document. A response that does not parse as the type it claims to be — the site’s HTML shell served at a .json path, an empty body, a redirect notice — is a soft 404, and a conforming reader must treat it as absent rather than present.

One version governs the documents

Every published document carries a spec block naming the scheme and the version: { "scheme": "agent-presence", "name": "Agent Presence", "spec_version": "0.2" }. That number, and only that number, tells a reader whether it understands what it is reading.

An earlier draft published three competing version fields across its documents, and an agent could not tell which one governed what. From 0.2 onward, a document’s authoring format may version independently and is reported for traceability only. It is never the document version.

One document is the authority

Facts appear in more than one place. When they disagree, the capability catalog wins: it is authoritative for capabilities, representative queries, contact, and evidence. The business record points at it and must agree with it. An implementation is expected to prove that agreement rather than assert it.

Evidence, not assertion

Every claim in the catalog carries a claim_id, its value, and the source URLs it came from. This is the load-bearing part of the scheme. A record without sources is a marketing document that a machine can parse; a record with sources is something a reader — or the business’s own lawyer — can check line by line.

The refusals

An answering surface implementing this scheme answers only from published claims, and returns the sources it used with every answer. It follows that it cannot:

  • quote or estimate a price;

  • confirm a date, a deadline, or availability;

  • describe a service the business has not published;

  • agree to terms, or accept anything on the business’s behalf.

A question it cannot answer from the record returns a refusal, not an approximation. An agent may request a proposal within a written authority envelope, and receives a receipt with no terms in it; a human sets the terms afterward. This is not a setting that can be switched on. There is no route through a conforming implementation by which software prices work.

What a conforming reader must not claim

This applies to any tool that assesses a business against this scheme, and it is stated here because getting it wrong does real harm to real businesses.

A check that could not complete is unknown, never absent. A timeout, a 5xx, a 429, or a 401 from a firewall means the document was not read. It does not mean the business publishes nothing. Only an authoritative answer — 404 or 410 — establishes absence.

The inverse is equally a false claim: a score computed from whatever happened to be readable is not a readiness score. A reader that could not read the documents the scheme is about must withhold its score and say why, rather than reporting a passing grade earned from unrelated checks.

Implementations

Four domains serve the full document set at version 0.2. Each link below returns the live document.

Checking a site against this

The readiness check runs these tests against any domain and reports what each URL returned, with the status and the time. It is deliberately conservative, per the rule above, and it reports what it could not read as unread.

The answering surface on this site is a working implementation. A useful way to read this specification is to try to make that surface say something River Cade Concepts has not published, and watch what it does instead.

Status

Version 0.2 is a working draft published by River Cade Concepts, an independent studio. It is not a standard, it has no standards body behind it, and it should not be described as one. It is a specification that is implemented in public, which is the only claim being made for it. The business record adapter targets the external Agentic Resource Discovery draft; that project’s identifiers belong to it, not to this scheme.

Version 0.2 · published August 29, 2026 · implementations verified live the same day.