The Reference Flow

This section is non-normative. It exists to answer one question a reader should be able to answer in two minutes: if I build against this, how far does it get me?

8.1 The task

A person tells their agent:

Find me a mid-size SUV under $400 a month near me, and book a test drive.

That is an ordinary request. It is also the shortest task that touches every hard problem in agent-to-business interaction: discovery, valuation, freshness, identity, delegation, multi-party routing, communication consent, and audit.

8.2 What has to happen

#	Step	Covered by
1	The agent finds businesses that expose an agent surface at all	Not yet specified. §10 Discovery.
2	The agent reads inventory across several of them	§4 Domains, §5 Naming, published schemas
3	The agent asks for a real monthly payment, not a sticker price	Not yet specified. §13 Substantiation.
4	The agent confirms the item is still available	Not yet specified. §13 Freshness.
5	The person decides to book, so identity is now required	Not yet specified. §12 Delegated Identity.
6	The person proves control of an email address or phone number	Not yet specified. §12 Delegated Identity.
7	The agent presents proof it acts for that person	Not yet specified. §12 Delegated Identity.
8	The request fans out to several independent systems	Not yet specified. §11 Federation.
9	Those systems will now contact the person directly	§9 Consent Portability
10	One of them touches a regulated decision	§6.2 scopes, but no runtime challenge path. §12.
11	The whole exchange is auditable and revocable	Not yet specified. §12 Delegated Identity.

8.3 Reading that honestly

Two of eleven steps are fully specified today, and a third is partially. Step 2 is the one the published schemas answer, and it is the step this specification has spent the most effort on.

That is worth stating plainly rather than burying, for three reasons:

• An implementer should not go looking for something that is not there. The machine-readable gap list at /llms.txt exists for the same reason.
• The gaps are the interesting part. Steps 5 through 11 are not automotive problems. They are unsolved for agent-to-business interaction generally, and no profile of any protocol has specified them yet. That is where this work is going.
• Anyone claiming otherwise is describing something they have not built. A specification that reads as complete at this stage is a specification that has not been implemented.

8.4 How the remaining sections are organised

Sections 9 through 13 are written to be domain-neutral: their normative text describes parties, subjects and systems rather than dealerships, shoppers and DMS platforms. Automotive appears in their examples only.

This is deliberate. The problems in steps 5 through 11 are not specific to retail automotive, and specifying them in automotive vocabulary would make the result useless to everyone else and harder to contribute upstream. Retail automotive is where these problems are most acute, because one purchase involves several independent vendors, a regulated credit decision, and statutory rules about contacting the buyer, all at once. It is a good place to solve them. It is not the only place they need solving.

8.5 Status of each planned section

Section	Status
§9 Consent Portability	Drafted. Normative.
§10 Discovery	Planned. Where a conformant server publishes its manifest.
§11 Federation	Planned. Rooftop identity, namespacing, provenance, partial failure, bridge token exchange.
§12 Delegated Identity	Planned. Agent identity, delegation, step-up, revocation, audit record.
§13 Data Contracts	Planned. Freshness, staleness, substantiation of quoted figures.

If you are implementing something that needs one of these before it is written, the working group wants to hear what you did instead. A workaround built against a real system is worth more to a draft than an opinion about what the answer should be.