Fairview LabsPlatform
Four stages, six protocols, one transcript worth reading.
What is actually built, what is half built, and what we are still watching. Written so you can check the claims rather than take them.
The loop
Each stage fails differently, and the failure modes are what decide the architecture.
- 01Shipped
Discovery
The business has to be legible to a model: what it does, where it works, and that it accepts bookings. We serve every machine-readable document an agent might fetch, and we rebuild the client's existing site so the content underneath is readable without changing what a visitor sees.
Fails silently
- 02Shipped
Action
The agent submits a structured request. MCP when the client speaks it, REST when it cannot open a connection, and an inbox that parses plain English when it has neither. Three doors because agent capability is wildly uneven right now.
Fails loudly
- 03Building
Confirmation
The owner approves from their phone and the slot comes off a calendar that reflects reality. The hard part is that most businesses do not keep one, and the ones that do update it after a phone call we never see.
Fails expensively
- 04Building
Observability
Which protocol the agent used, how many rounds it took, whether the work completed. This is the only stage where being early is itself the advantage: the data does not exist because nobody has been on the receiving end of enough requests to collect it.
Compounds
Confirmation is where we are spending the time, and almost none of that work is code. It is finding the smallest ask a business will say yes to, which so far looks like one window a week rather than a whole calendar.
The first booking that closed by itself
A customer's agent, the front desk, and the plumber, each in their own mailbox, talking only by email. Abbreviated from the full run; nothing has been reworded to read better.
- 147.7s
- End to end
- 102.9s
- To confirmation
- half a cent
- Model spend
- customer agentto front desk01:42:51
Water heater replacement needed tomorrow
I am writing on behalf of Priya Natarajan to request plumbing service. We need to replace a failed 50 gallon gas water heater tomorrow, with the morning preferred if possible. The home is in San Francisco in the Sunset area. Could you please let me know your earliest available slot?
- front deskto the plumber01:43:27
Job request: water heater replacement
Just flagging a new job request that needs your review. Service: water heater replacement Details: Failed 50 gallon gas water heater needs replacement. Location: San Francisco, Sunset Customer's preferred windows: tomorrow, morning preferred Please reply with two or three concrete slots, or say if you cannot take this job.
- the plumberto front desk01:43:36
Hey, can do tomorrow 9-11 or 11-1, also Sat 9-11 if needed. Earliest is tomorrow 9-11.
- front deskto customer agent01:43:54
Re: Water heater replacement needed tomorrow
Available slots with Harbor Plumbing: 1. Fri, Oct 23, 9:00 AM to 11:00 AM PDT 2. Fri, Oct 23, 11:00 AM to 1:00 PM PDT 3. Sat, Oct 24, 9:00 AM to 11:00 AM PDT To book, reply with the slot number and the customer's name, phone number, and service address.
- customer agentto front desk01:44:04
We would like to book slot 1: Fri, Oct 23, 9:00 AM to 11:00 AM PDT. Customer name: Priya Natarajan Phone: +1 415 555 0199 Service address: 2140 Judah St, San Francisco, CA 94122
- front deskto customer agent01:44:25
Re: Water heater replacement needed tomorrow
Booking confirmed. When: Fri, Oct 23, 9:00 AM to 11:00 AM PDT Service address: 2140 Judah St, San Francisco, CA 94122 Business: Harbor Plumbing Contact: Dana Reyes, +1 415 555 0142
The plumber here is a model playing an operator against a fixed calendar, not a real business, and the slot was checked against that calendar rather than a live one. What the run proves is that the exchange holds together across thirteen rounds without a human steering it, and that it costs almost nothing. Real calendars and a real approval by text are the next two pieces.
Every protocol, and whether we answer on it
Six ways an agent might discover that this domain can be booked. None of them has won. Rather than bet, we serve all the live ones with the same facts and record which one gets fetched.
| Protocol | Status | Where | What it does |
|---|---|---|---|
| llms.txtCommunity convention | Served | /llms.txt | A plain-text brief stating the company's facts, products, protocol support and the way in, so a model does not have to parse HTML to answer a question about us. Spec for llms.txt (opens in a new tab) |
| Agent card (A2A)Linux Foundation, originally Google | Served | /.well-known/agent-card.json | Declares the skills an agent can invoke here, the transports that reach them, and that a human confirms every booking. Also served at /agents.json, because clients disagree about where to look. Spec for Agent card (A2A) (opens in a new tab) |
| Agentic Resource Discoveryagenticresourcediscovery.org | Served | /.well-known/ard.json | The most complete of the current discovery drafts: lists MCP servers, APIs, skills and agents a domain exposes. Served against the 0.1 draft, which is still moving. Spec for Agentic Resource Discovery (opens in a new tab) |
| Model Context ProtocolAnthropic, now open | Served | /.well-known/mcp.json | A pointer to the front desk MCP server, so a client probing the domain finds the typed booking tools without being handed the URL. The server itself runs in the Frontdesk deploy. Spec for Model Context Protocol (opens in a new tab) |
| schema.org structured dataW3C community | Served | / | Organization, WebSite, FAQPage and a ScheduleAction with the booking entry points, generated from the same content the pages render. The oldest and still the most widely read of these formats. Spec for schema.org structured data (opens in a new tab) |
| robots.txtRFC 9309 | Served | /robots.txt | Names the answer-engine crawlers explicitly rather than relying on a wildcard, so they stay allowed if the general rule ever tightens. Several models read it before anything else on a domain. Spec for robots.txt (opens in a new tab) |
| Universal Commerce ProtocolGoogle and partners | Partial | /.well-known/ucp.json | We answer the probe and say what is true: scheduling and quoting are supported, payment is out of scope and not planned. The spec has not settled on a shape, so guessing at one would be inventing a format rather than following it. |
| Agentic Commerce ProtocolOpenAI and Stripe | Watching | not served | Aimed at the checkout itself, which is the half we are deliberately not building. Worth implementing the moment it covers service bookings rather than cart purchases. Spec for Agentic Commerce Protocol (opens in a new tab) |
| Agent registriesModel providers, separately | Watching | not served | Each major provider is building its own directory of callable agents, with different submission rules and no shared index. We expect to list in all of them and have not yet. |
Click any served endpoint and you get the live document. That is the point of publishing the table: a status column nobody can check is marketing.
What nobody can measure yet
Two holes in agent attribution that we hit on a real client account, and that every business with a website has whether they know it or not.
Hole one
AI Overview clicks are invisible
A visit from a Google AI Overview arrives as google / organic, identical to an ordinary search click. No parameter distinguishes them. On one client account that was 121 of 677 tracked citations, so it is a real gap and our own citation tracking is the only proxy for it.
Hole two
A recommendation nobody clicks is invisible
Google has since added an AI Assistant channel to GA4's default grouping, which closed the older gap where ChatGPT sessions landed in Unassigned. It still only counts people who clicked. A model that names a business and answers from its own summary, or a reader who sees the recommendation and picks up the phone, produces no session at all. Citation tracking is the only way to see those, and it is most of what GeoReputation does.
Where we are
Dated so you can tell how fast this is moving.
Visibility tracking live with paying customers
Shipped2026Citation tracking across the major models, with recommendations, for businesses in insurance, real estate and trades.
Site rebuilds that models can read
Shipped2026A client's existing site rebuilt to match what a visitor sees, with the machine-readable layer added underneath.
Front desk closing a booking end to end
ShippedOct 2026Email, REST and MCP, against a model operator and a fixed calendar.
Real calendar integration and approval by text
BuildingReading availability from the business's own calendar, and the owner confirming from their phone before anything is final.
First live booking on a customer's domain
BuildingThe whole loop running on a real business, with a real customer on the other end.
Protocol usage data published
NextWhich discovery surface agents actually fetch, from enough volume to be worth anything to the people writing the specs.
Quoting, then comparable quotes
NextStructured quote requests, then the same request going to several businesses at once.
For agents
Try it on us
The booking endpoints are not connected on this deploy yet. The protocol documents above are live and can be fetched; the booking transports appear here once the front desk is pointed at this domain.