Demo
The model talks, code books
An AI receptionist for an invented bike repair shop, over text messages and web chat. The model handles the conversation. Code makes every decision that matters: when a text may go out, what a stop or help word does, whether a time is really free before it is booked, what a message may contain, and who on the staff may read what.
This is a simulation. No AI model runs on this page: the model’s replies are scripted, and the shop, its customers, staff, calendar, prices and addresses are all invented. No text, chat, email or booking is ever sent or made, nothing you do leaves your browser or is kept, and reloading the page starts again.
The sandbox week numbers its days: day 1 is today, and Thursday is day 4. The shop is open 09:00 to 12:00 and 13:00 to 18:00 on days 1 to 5, 09:00 to 13:00 on day 6, and is closed on day 7. A service takes an hour.
1. Text messages
Wren is away on a trip, in another time zone, and asked for a service through the shop’s web form. The assistant follows up by text, but only outside quiet hours (21:00 to 08:00) on Wren’s own clock, which is UTC minus 3 while the shop is UTC plus 2. Then pick what Wren texts back, in any order.
Shop clock: day 1 08:30 (UTC plus 2). Wren’s clock: 03:30 (UTC minus 3), inside quiet hours.
The text thread
- Code: A service request from Wren arrived through the web form at 08:30 shop time.
- Code: Opening text held: it is 03:30 for Wren (UTC minus 3), inside quiet hours. A check on the shop’s own clock would have sent it now. It goes at 13:00 shop time, 08:00 for Wren.
Wren texts back
Nothing has been sent yet.
What the model returned and what code did, turn by turn, is below the staff alerts.
Staff alerts
- None yet.
What the model returned, and what code did
The model must answer through one tool with three fields: message, time and person. Code reads the fields, runs its checks and decides what goes out. Stop and help words never reach the model. The newest turn is at the top and open; earlier ones open from their heading.
Each check is marked Pass, Fail or Caught. Fail means what the model proposed did not pass, so code did not act on it. Caught means code found a problem in the model’s own words and removed it, or held the words back. Both are the checks doing their job.
- No turns yet.
2. Web chat booking
Finch is on the shop’s web chat. Pick how Finch answers the question about when. Code turns the words into a search window, reads the sandbox calendar and offers real free times. While Finch decides, someone at the counter takes one of them, so one pick fails its re-check.
The chat
- Code: Contact details collected at the start of the chat: Finch, with an email address for confirmations.
- Assistant: Thanks for waiting, Finch. I’m the bike shop’s AI assistant. When would you like to bring your bike in for a service?
Finch writes
Finch picks a time
Nothing has been asked yet.
How code read it
The search window
- Nothing asked yet.
The sandbox calendar
- Shown once a day is asked for.
Checks
- None yet.
3. Lead intake into a mock CRM
After each conversation the lead goes through five steps, and every one of them ends in a route: no lead is ever dropped. Addresses are invented, end in the reserved .example, and are shown in two parts. Run a lead twice to see it matched instead of copied.
Wren
A service, as the lead arrived
- name
- " wren "
- address name part
- "Wren"
- address domain
- "MailBox.Example "
Rowan
A new chain, as the lead arrived
- name
- "ROWAN"
- address name part
- " rowan"
- address domain
- "Post.EXAMPLE"
Juniper
A puncture repair, as the lead arrived
- name
- "juniper"
- address name part
- "juniper"
- address domain
- "throwaway.example"
Hazel
A brake check, as the lead arrived
- name
- "Hazel "
- address name part
- "hazel"
- address domain
- "mailbox.example"
Contacts in the mock CRM
- Contact 12: Rowan. Address name part "rowan", domain "post.example". Tags: customer. Leads: 1.
The steps: Tidy, then Match, then Throwaway check, then Verify, then Route.
4. Staff audit
Staff read what the assistant said, but only for the branch their sign-in allows. The server maps a verified sign-in to its branches from its own settings and never from the request. A conversation from another branch gets the same answer as one that does not exist.
2 conversations at Riverside, summaries only.
C-104: Robin by text. Booked for day 3 at 11 am. 3 messages.
C-109: Otter by chat. Handed to a person. 2 messages.
The server’s answer
Open a conversation to see it here.
5. A safety-first phone receptionist
Designed add-on
The same idea for a regulated, safety-sensitive setting, where a phone receptionist must follow stricter rules. This is a design only: nothing of it is built, and nothing on this page runs it.
- A call comes in. Existing numbers forward to the voice agent by working hours, so nothing changes for callers.
- The shared safety policy listens first. One policy sits above every site’s settings, and no site setting can weaken it.
- Sounds urgent or unsafe: straight to a person, at once.
- Otherwise: the call goes on to the next step.
- The site’s own settings apply. Hours and services per site, inside the shared policy.
- Times come from the existing scheduling system. Read only at first, through an integration layer. Writing back comes later, only if the data provider’s terms allow it, with a guard against stale times.
- The caller gets a time or leaves a message. Anything uncertain goes to staff to confirm.
Before any voice testing, a suite of scenarios runs against the policy. Go-live would be one site at a time.
What the demo shows
- The model proposes; code decides. The model’s reply is three fields from one required tool call. Code checks the fields and writes the words of every booking itself, so the model’s “you are booked” never reaches a customer unless a booking was really written.
- A re-check before every booking. A time is checked against opening hours, the shop clock and a fresh read of the calendar, not the read it was offered from. A time taken in between is refused, with real free times or a promise that a person will confirm by email.
- Time zones handled in code. Quiet hours use the customer’s own clock, a phrase like “Thursday after lunch” becomes a window on the shop’s clock and in UTC, and a time the model sends back is normalised before it is checked, with or without its zone.
- An unreadable calendar is no answer. A reply that carries an error is never read as “nothing busy”, which would offer every time. The assistant says so and promises an email instead of guessing.
- Rules the model cannot skip. Stop and help words are answered by code without the model, links and phone-like numbers are stripped from what the model wrote, an answer longer than one text of 160 characters is held back for a short reply of code’s own and a staff alert, and a request for a person alerts staff and quiets the assistant.
- No lead dropped, no record exposed. Every lead is tidied, matched, screened, verified and routed, and each route keeps it. Staff see only their own branch, and a conversation from another branch looks exactly like one that does not exist.