Question 1

Is the AI Service Infrastructure OS live today?

Accepted Answer

No. Beacon — measuring and fixing how AI represents a business — is live today, real, and what we sell. The OS described on this page is the direction that work is headed, not a shipped product. We’re saying it out loud because it’s why the wedge is built the way it is, not to claim it exists yet.

Question 2

How is this different from schema.org or JSON-LD?

Accepted Answer

Schema.org tells a search engine what a page is about. It was never built to carry the operational detail an autonomous agent needs to actually transact — real-time availability, eligibility rules, verified pricing, provenance of every claim. The protocol we’re working toward is a superset built for that: a service described completely enough for an agent to act on, not just cite.

Question 3

Does this change what Beacon does for my business today?

Accepted Answer

No. Beacon’s job stays exactly what it is: get your business named and correctly represented when a customer asks AI for a recommendation, on a page that converts. Any future protocol work builds on the same factual foundation Beacon already establishes — it doesn’t replace or change today’s product.

Question 4

Why start with small local businesses if the vision is this big?

Accepted Answer

Because the hard, unglamorous part — getting one business’s facts correct, verified, and visible to AI — is the same problem at any scale, and it’s the part that has to be solved first and solved honestly before anything about standardization or transactions means anything. A protocol nobody has actually run against real businesses is just a diagram.

Question 5

What exactly is a Service Object?

Accepted Answer

The structured record shown earlier on this page — the same twelve fields as the standardization stack: who’s offering it, what it actually is, what it costs, when it’s available, who’s eligible, and how sure we are about each of those facts. Today that record lives as the facts ledger behind a Beacon-generated page. The OS is what happens when that record is described the same way for every business, in a form an agent can query directly instead of scraping a website.

Question 6

Who verifies that a Service Object’s claims are true?

Accepted Answer

Nobody should trust a claim just because it’s structured — structure alone doesn’t make something true. Every field in the model carries a confidence tier: measured (confirmed against a real source, like a completed booking), self-reported (the business told us and it hasn’t been independently checked), or inferred (we derived it and flagged that it’s a guess). An agent reading a Service Object can see which tier a fact sits at and weigh it accordingly — the same discipline Beacon already applies to citation data today, extended to the object itself.

Question 7

Is this an open standard, or does Inserviss own it?

Accepted Answer

Undecided, honestly — and it’s premature to decide. A protocol only one company controls isn’t really a protocol, it’s a walled garden with a friendlier name; but a protocol with no steward often never ships at all. Right now this is Inserviss’s own thesis, tested against Inserviss’s own customers. If it proves out, the honest path is probably some form of open governance — but that’s a real decision for later, not a marketing claim to make now.

Question 8

What happens if an AI agent gets a booking wrong?

Accepted Answer

The same thing that should happen today when a human gets a phone booking wrong: the business is the merchant of record, and the transaction terms are whatever the business actually offers, not whatever an agent guessed. The reason to structure a Service Object precisely — price, eligibility, availability, each with a stated confidence — is to shrink how often “the agent got it wrong” is even possible. It’s a real, unsolved problem for the whole industry, not just for us, and worth naming rather than glossing over.

Question 9

How is this different from just listing on Google Business Profile, Yelp, or OpenTable?

Accepted Answer

Those platforms are built for a human to browse and click — the data is theirs, formatted for their own app, and rarely exposed for another system to query directly. A Service Object is built the other way around: owned by the business, structured for a machine to read and act on, and portable across whichever engine or agent is asking, rather than locked to one directory’s listing format.

Question 10

When will an AI agent actually be able to book through this?

Accepted Answer

No date — see the first answer above. The honest sequencing is: Beacon gets the facts right and visible first (live now), the facts get formally structured as Service Objects next, and agent-to-agent booking is the layer after that, once there’s a real counterparty — another agent, not just a person clicking a link — actually asking for it. We’d rather ship each step for real than announce a date we’d have to walk back.

The AI Service
Infrastructure OS

AI without Service Infrastructure is a brain without hands

Why “Inserviss”

How a customer finds a service is changing again

The search era

The answer era

The transaction era

Legible to an agent, not just to a search engine

What exactly gets standardized

Two AI agents, one request

Roughly every kind of service, eventually

Human services

The honest version

The part of this that’s real right now

The AI Service Infrastructure OS