Research what it would take for the Everwood booking engine to be safely callable by an autonomous AI agent, not just by a person clicking a widget. Tracked on the roadmap as agent-ready booking.
I was treating this as an integration question. Expose the endpoints, document them, let agents call them. That framing skips the part that actually matters, which is that the caller is no longer a human who can see what they are doing.
Reads and writes are not the same class of operation. Reads are safe to expose early. Writes need idempotency, concurrency control, and a human confirming the transaction before it becomes real.
The Build
Nothing shipped here. This is a research note, and I want to be upfront about that. Agent-ready booking sits at Idea stage on the roadmap. Everwood has no agent interface today, of any kind. What exists is a design I now believe in and a set of open questions I did not have before.
The question I started with was narrow. Everwood already has a booking widget and an AI booking assistant. If someone is running Claude or a browser agent and says "book me a 60 minute deep tissue next Tuesday afternoon," what would have to be true for that to work against an Everwood tenant without me losing sleep?
The honest answer today is that it would work by screen scraping. The agent loads the widget, reads the DOM, guesses which element is the date picker, and clicks. That works until I change a class name. It is brittle in the way that always breaks on a Friday.
So I went looking at how the platforms with real programmatic surfaces handle it, and at the protocols trying to replace scraping with something declared instead of guessed.
The Problem
The thing I underestimated is what changes when the client is not a person.
A human booking an appointment sees the whole screen. They notice when a slot disappears. They do not click confirm three times because the page took a second to respond. They cannot be talked into booking on someone else's account by a paragraph of text hidden in a service description.
An agent can do all of those things.
The first failure mode is stale availability. An agent works off its context window, and that context holds whatever it queried earlier in the conversation. It can offer a customer a 2:00 PM slot it looked up ten minutes ago. If that slot filled in the meantime, the booking call fails. If the agent does not handle that failure cleanly, the customer was just promised something that does not exist, and they blame the salon, not the agent.
The second is duplicates. I could not find a traceable report of this happening to a specific team, so I am not going to pretend I have one. What I can point to is that every serious booking and payments API treats it as a documented risk: idempotency keys exist precisely because a client that retries an ambiguous failure will otherwise create the same record twice. This is the one that costs real money. An agent that misreads a timeout as a failure and retries can put three identical appointments on a calendar. Now the owner is manually reconciling a schedule and processing refunds, which is exactly the labor the automation was supposed to remove.
The third is impersonation and inventory abuse. If the platform cannot tell a human interaction from an agent interaction, it cannot tell a legitimate agent from a swarm of them scraping a competitor's availability or filling a calendar with appointments that will never show up.
None of these are prompt problems. You cannot instruct your way out of them. They are all backend guarantees.
Assumption vs Reality
Making booking agent-accessible means publishing a good interface. Clean, documented, with a key to get in. Agents are just another client, so if the interface is solid, the agent will be fine.
The API surface was the easy half. The hard half is that the backend cannot trust anything the agent tells it, including the claim that the user agreed to the booking. An agent is an unreliable state machine. It will retry, it will act on cached data, and it can be manipulated by text it read along the way. Every guarantee has to be enforced server side, and the confirmation step has to reach an actual human before anything mutates.
The Fix
What changed is the design, not the code. I landed on a three layer split, and the point of the split is that only one layer is allowed to be authoritative.
The outer layer is a translator. It speaks whichever agent protocol is in fashion and holds no business rules whatsoever, so it can be replaced or duplicated without anything underneath moving. Its other job is turning a refusal into something the agent can act on. When a slot is gone, the answer has to mean throw away what you cached and ask again, not try that again, or the agent will sit there retrying a dead time forever.
Beneath it sits the stable part: a short list of named operations, versioned, and split hard along the line between reading and writing.
Checking availability and quoting a price are reads. Nothing changes, they can be cached, and they can run often.
Placing a hold is the middle step. It reserves a slot for about ten minutes and returns the real price and duration, so the customer agrees to an actual number rather than an estimate.
Confirming and cancelling are the destructive ones. They run rarely, each needs its own permission, and each has to be safe to repeat.
Every response is tagged so we can tell agent traffic from human traffic later without guessing.
Underneath all of it, one service is the only authority. It owns validation, keeping businesses separated, and every booking rule, and it applies them identically whether the request came from a phone, a browser agent, or something enterprise. The moment an agent path is allowed to skip those rules for convenience, the argument that the platform is trustworthy is over.
The confirmation flow is the part I care most about. It is deliberately two steps. The agent takes the hold and gets a real price. Then the agent is stopped. The question goes to the actual person, through whatever surface they are using, and the booking becomes real only once proof comes back that a human said yes. The agent never gets to assert consent on someone else's behalf. Both of the emerging agent standards I looked at support exactly this shape, which was the most reassuring thing I found.
Split reads from writes and the whole problem gets smaller. Read-only exposure is genuinely low risk. If an agent checks availability two hundred times, nothing breaks except my bandwidth bill, and pagination plus cache TTLs handle that. I can ship reads, learn how agents actually behave against a real tenant, and gather traffic data before anything can mutate a calendar. Writes are a different product. Every one of them needs a client-generated idempotency key that the domain service hashes and caches against the tenant, so a retried payload returns the original response instead of creating a second appointment. Every one needs optimistic concurrency so a lost slot race produces a clean deterministic error. And every one needs a human in the middle. The deeper lesson is about where trust lives. I keep relearning this in different forms. In the earlier notes it was that a better prompt could not fix a state problem. This is the same shape. Agent safety is not a prompting concern or an adapter concern. It is a domain service concern, and if the guarantee is not enforced in the layer that owns the data, it is not enforced.
For a salon owner, the value is that a customer could book without ever visiting a website. They ask their assistant, it checks the real calendar, it confirms, and the appointment appears. Hypothesis, and I want to be clear it is only a hypothesis: removing the link-clicking and form-filling step should reduce the drop-off that high friction scheduling flows produce. I have no data on that yet. The part that is not a hypothesis is the downside if this is built carelessly. An agent that double books costs the owner real time and real refunds. An agent that promises a slot that is already gone costs the owner a customer who thinks the salon is disorganized. The customer never blames the AI. They blame the business. That is why the confirmation step is not friction to be optimized away. It is the thing that makes the feature safe enough to offer to someone whose calendar is their livelihood.
Builder Notes
What the established booking platforms already do about this, and how ready the agent standards are. Findings are labelled by confidence, because some is verified against primary documentation and some is only reported.
Technical Note 1
Verified from primary documentation: Square Appointments requires every booking request to carry a caller-supplied ticket number. Send the same request twice with the same ticket and you get the original answer back rather than a second appointment. That is the pattern to copy, and it is the most important one on this list.
Technical Note 2
Verified from primary documentation: Calendly has no way to move a booking. Changing one means cancelling and rebooking, and the agent has to run both halves without dropping the customer in between. Worth deciding early whether Everwood offers a real reschedule or inherits that same gap.
Technical Note 3
Verified from primary documentation: Acuity has a staff-level booking mode that skips availability checks entirely. That is a legitimate thing for an owner to do and a dangerous thing to leave within reach of a customer's assistant. It should never sit on the path an outside agent can take.
Technical Note 4
Reported, not independently confirmed, because the Mindbody developer documentation would not load for me: booking there runs through a rigid multi-step sequence and a signature afterwards. If that holds, it is proof that one-shot booking is not achievable in every kind of business, which is part of why an agent has to be able to stop halfway and come back.
Technical Note 5
Reported, not independently confirmed, same documentation problem: Boulevard books through something shaped like a shopping cart. You open one for a location, add services and guests, then check out in a single step. Finalising it all at once narrows the window for two people grabbing the same slot, and handles a group booking without extra juggling. Closest model to what Everwood would want for multi-service appointments.
Technical Note 6
The main agent standard, MCP, was introduced by Anthropic in November 2024 and revised in July 2026. Two things in that revision matter to a booking product. It became ordinary request-and-response traffic, so it runs on the same infrastructure as everything else rather than needing its own. And it gained a proper way for a server to pause mid-operation, put a question to the human, and resume with the answer. That second one is the mechanism the whole confirmation design leans on, and it is worth knowing it exists rather than designing around its absence.
Technical Note 7
The browser-side counterpart, WebMCP, is a W3C Community Group standard and entered a trial in Chrome in June 2026. It lets a page state what it can do, so an agent reads a declared capability instead of guessing at the buttons. It comes in two flavours: one that annotates the forms a page already has, and one that exposes application state directly. Early, but the direction is right.
Technical Note 8
There is no benchmark for the browser standard yet, and I went looking for one. Neither the Chrome announcement nor the W3C write-up publishes numbers. A 2025 academic paper reports large savings, but it measures a different proposal that happens to share the name, so it does not apply. The case for declared capabilities over guessing at a page rests on the mechanism, not on a measured win I can point to, and I would rather say that than borrow someone else's figure.
Technical Note 9
Security, and this is the one I would get wrong if I moved fast: an agent holding a valid key for one business can be talked into presenting it against a different one. A server that only asks whether the key is real will hand over the data. So the key has to be issued for a named business and checked against that name on arrival, and a key that is genuine but pointed at the wrong door gets refused. The agent standards already require this, which tells you it is a mistake people have made.
Technical Note 10
The browser standard is switched off by default inside an embedded frame. Since the Everwood widget is embedded on someone else's site, that site has to grant permission before an agent could use it there. That is a setup step a salon owner would have to take, not a setting I can flip for them, and it belongs in the plan from the start.
Technical Note 11
Anything an agent sends that was not asked for gets dropped at the door rather than passed inward, because a model will occasionally invent a field and mean it. Personal details get masked in the logs. Agent bookings get counted as their own channel, so their completion rate can be compared honestly against people booking by hand.
Technical Note 12
Where the browser standard is used, build on the flavour that annotates the booking form we already have. Screen readers, keyboard navigation, and browsers that have never heard of any of this keep working exactly as they do now, and the agent path stays an enhancement rather than a second product to maintain.
Technical Note 13
Still open: Mindbody and Boulevard are the two platform claims I could not check against primary documentation, because neither developer site would load for me. Neither carries a number and neither is holding up the design, but both should be confirmed before either one shapes a decision.
Before / After
- Agent access is an API problem: publish endpoints and document them
- Reads and writes are the same kind of operation with different verbs
- The agent can tell us the user approved the booking
- One auth scope covers agent access
- Availability freshness is the agent's problem to manage
- Agent access is a trust boundary problem, and the API is the easy half
- Reads ship first and carry almost no risk; writes are a separate phase with separate guarantees
- The backend never accepts an agent's claim of consent, only proof of human confirmation
- Separate permission for each class of operation: check availability, quote a price, place a booking, cancel one
- Stale availability is handled by holds, deterministic errors, and cache TTLs the server controls
What I'd Do Differently
I would have written the capability contract before reading a single protocol spec.
I started at the protocol layer, comparing MCP and WebMCP, and it pulled me toward protocol-shaped thinking. The useful realization came later and in the opposite direction: the protocols are the replaceable part. WebMCP is behind a flag in one browser and the W3C group can still change the API meaningfully before standardization. If I had built directly against it, that is technical debt with a known expiry date.
Naming the operations first, deciding which are destructive, and assigning scopes and rate classes would have taken an afternoon and would have made the protocol comparison a much shorter exercise.