
Saturday, 8:14 AM. A customer asks their AI assistant: "Find me a yoga class this morning in the city center, under $30, beginners welcome."
The agent doesn't open a browser. It queries six providers it already knows about, filters out the four that don't expose live availability, and shortlists two that match — clear pricing, the right level, an open slot at 10:15. It books one, pays the deposit, drops the confirmation into the customer's calendar with the right timezone.
You weren't on that shortlist. Not because your studio is worse. Because the agent couldn't see you.
This is the new game. SEO got businesses found by humans typing into Google. Agent Experience Optimization (AEO) is what gets you found by autonomous AI agents calling APIs. The rules are different. Most businesses haven't noticed yet.
AEO Is the New SEO
For twenty years, discoverability meant ranking on a search engine. You optimized titles, structured headings, built backlinks, fought for the top three blue links. The currency was attention — humans scanning a page.
Agents don't scan pages. They call functions. An AI booking assistant doesn't read your hero section, doesn't admire your photos, doesn't notice your testimonials. It asks: "What services do you offer? What's available between 9 and 11 on Saturday? What's the cancellation policy?" — and it expects machine-readable answers, in milliseconds.
If the answer requires a human to interpret a calendar widget, you don't exist. If your prices are buried in a PDF, you don't exist. If your "real-time availability" refreshes once a night, you don't exist.
AEO is the discipline of making sure your booking infrastructure is legible to machines as effortlessly as your website is legible to humans.
What Makes a Service Agent-Readable
There are four things every AEO-ready booking service needs. Skip any one of them and agents skip you.
1. Structured service data
Agents need to know what you sell, in machine-readable form. Not "60-min energizing morning class with our award-winning instructor" as flowing prose, but a typed object: name, duration, price, currency, category, prerequisites, language, format (in-person/online), location, tags. The same fields every agent gets, with the same names, every time.
On the public web, this is what schema.org was designed for. Service, Reservation, OfferCatalog, LocationFeatureSpecification — embedded as JSON-LD, they let crawlers and agents understand your offer without parsing layout. On the API side, the same shape lives in your booking system's data model.
If you can't programmatically answer "give me the full service catalog as JSON" in one request, your agent-readability score is zero.
2. Live, machine-readable availability
A booking page that looks live to a human (because it loads via JavaScript) is often invisible to an agent that doesn't run a browser. What agents need is a public availability endpoint: given a service, a location, and a date range, return the open slots.
GET /availability?serviceId=...&from=...&to=... returning a JSON array of slot objects with start time, end time, capacity, and timezone — that's the contract. Static HTML calendars, "call to confirm" links, manual spreadsheets that sync overnight: all useless to agents.
Real-time means real-time. If a slot was booked thirty seconds ago, the next agent query has to reflect it.
3. Stable identifiers and IANA timezones
Agents don't reason about your data, they reference it. Every project, service, location, and slot needs a stable, durable ID. Renaming a service shouldn't change its ID. Migrating regions shouldn't either.
And every time field has to carry an explicit IANA timezone — Europe/Warsaw, America/New_York, never just "+02:00" or local time without context. We covered why in the timezone post. When an agent books a Tokyo customer with a Berlin therapist for "3 PM," it doesn't get to guess.
4. Transparent pricing and policies
Hidden fees, "ask for a quote," deposit rules buried in a terms page — agents won't dig for these. If the price isn't a number on the wire, the agent treats your service as priced unknown and ranks it below clearer competitors.
Same for cancellation, deposits, prerequisites, age restrictions, equipment requirements. Whatever a human guest would ask before booking, an agent will ask too — through your API. If the answer isn't a structured field, you lose the slot.
The MCP Layer: How Agents Actually Talk to You
Even with all four pillars in place, you still have an integration problem. Every agent in the wild — Claude, ChatGPT, Gemini, Copilot, the next ten platforms nobody's heard of yet — would otherwise need a custom adapter to talk to your API.
That's where Model Context Protocol (MCP) changes the math. MCP is an open standard (originally proposed by Anthropic, now adopted broadly) that lets an agent connect to a server, ask "what can you do?", and get back a self-describing list of operations. No bespoke integration. No prompt engineering for each platform.
We covered the Timerise MCP server in a separate deep dive — 16 tools covering the full booking lifecycle, mounted at /mcp. The point for AEO: an MCP-compatible booking system gets onboarded by an agent in seconds. A non-MCP system requires a developer to hand-write a tool manifest before the agent can use it. Guess which one ends up on shortlists.
If schema.org is the agent-readable map of your services, MCP is the agent-readable map of your capabilities.
How Agents Actually Discover Providers
A reasonable question: how does an agent know your studio exists in the first place?
Today, four entry points dominate, and you should be visible on at least two:
- Marketplace platforms with public catalogs. Booksy, ClassPass, Eventbrite, Mindbody — agents already pull live availability from these via partner APIs. Being listed makes you discoverable to any agent that integrates with the platform.
- Search engines that surface structured data. Google's
/Reservationschema and similar Bing/Apple equivalents are increasingly read by AI assistants. Marking up your services with proper JSON-LD is still the best way to land in answers from a general-purpose AI search. - MCP registries. Just as
npmlists packages andApp Storelists apps, MCP server directories are emerging where agents look up booking servers by domain or category. Registering your MCP endpoint is becoming the equivalent of submitting your sitemap to Google in 2005. - Direct hand-off from your existing channels. Customers paste your booking link into their AI assistant — "book me into this". The agent crawls the link, finds (or doesn't find) an MCP endpoint or a typed availability API, and proceeds. This pathway rewards businesses whose booking page exposes machine-readable hooks even when a human is the entry point.
If you're absent from all four, agents have no way to reach you.
The AEO Checklist (Do This Week)
Concrete moves that move the needle, none of which require rebuilding your stack:
- Audit your service catalog. Every service should have a name, duration, price, currency, category tag, and a 1-2 sentence description optimized for matching, not marketing. Vague titles like "Premium Package" lose every comparison.
- Expose a public availability endpoint. If your booking provider doesn't offer one, that's the migration signal. Agents won't scrape your widget.
- Add
schema.org/Serviceandschema.org/ReservationJSON-LD to your booking pages. Fifteen minutes of work, lasting benefit for AI search. - Set explicit IANA timezones on every service and slot. Drop "local time" everywhere — it's a silent bug factory.
- Make policies machine-readable. Cancellation window, deposit amount, prerequisites, language — fields, not paragraphs.
- Register your MCP endpoint if your booking system supports MCP. If it doesn't, ask your provider when it will.
- Tag services with intent keywords ("beginner-friendly", "outdoor", "kid-safe", "wheelchair-accessible"). Agents match on tags long before they parse descriptions.
- Verify your real-time availability is actually real-time. Open two browser windows, book a slot in one, refresh the other. If there's a delay, you're invisible at the moment that matters most.
- Track agent traffic separately. Tag programmatic API calls with a distinct user-agent or auth scope so you can see how much of your booking volume is already coming from agents. Most operators are surprised.
Where Timerise Fits
Timerise was built API-first, well before AEO had a name, because we believed the booking layer would eventually be consumed by software more often than by humans. Concretely:
- The GraphQL API returns a fully typed service catalog and live availability — agent-readable by construction.
- The MCP server mounted at
/mcpexposes 16 booking tools to any MCP-compatible agent without integration code. - IANA-aware timezone handling means cross-border bookings never fall into the local-time trap.
- Structured policies (deposits, cancellation windows, prerequisites, form fields) live as first-class data, not free-text disclaimers.
- Stable IDs on projects, services, locations, slots, and bookings make agents safe to reference your data over time.
None of this is a marketing layer bolted on. It's the underlying shape of the system. If you're building a service that needs to be agent-discoverable in 2026 and beyond, this is the substrate you want.
The Window Is Open, Briefly
Every prior shift in distribution had a window. Businesses that opened a Google My Business listing before competitors won local search. Businesses that exposed live availability via API before competitors won marketplace integrations. Businesses that mark themselves AEO-ready before competitors will win the first wave of AI-mediated booking traffic.
The window stays open until the platforms that mediate AI bookings start deciding which providers they'll source from by default — and once those defaults harden, climbing into them is a years-long battle. Right now they're listening. Right now your service catalog, your availability endpoint, and your MCP server are the audition.
Show up legibly, and the agents will find you. Stay invisible, and your competitors will collect the bookings that used to ring your phone.
Timerise is built API-first with native MCP support, IANA timezones, and machine-readable service data — the substrate AI agents need. If you want to see what AEO looks like for your business, leave a brief, open the chat in the corner, or write to us at hello@timerise.ai.
Further reading

Your Customers Will Soon Book With AI, Not Forms - What This Means for Your Business
AI assistants are learning to make bookings on behalf of customers. Here's what that shift means for business owners - and how to make sure you're not left out.

MCP Server: Your AI Agent Just Learned to Book
The Timerise API includes a built-in MCP server that lets AI agents search services, check availability, and manage bookings without writing integration code.