Voice ordering for a restaurant

The model proposes.
The server decides.

A caller talks to an AI receptionist about the menu and places an order. A language model holds the conversation; a Rails server owns the order. Every change the model wants is a request the server checks, applies or refuses.

The demo runs as a browser voice call for signed-in operators.

Conversation from the voice platform · not authoritative

Caller I would like one Margarita pizza with extra cheese. For pickup.

…

AI Added one margarita pizza, with extra cheese.

Order from Rails · authoritative

1 × Margherita Pizza + Extra cheese: $16.00
Total: $16.00

From a recorded test call (#22).

How a call works

The conversation and the order live in different places.

01
Caller

Talks naturally: asks what's on the menu, orders, changes their mind.
02
AI receptionist

The voice platform turns speech into text; a language model decides what to say and which tool to call; the reply is spoken back.
03
Rails tools + rules

Each tool call arrives as a request. Rails checks it against the menu and the rules, applies it in one transaction, and answers with the result or a clear error.
04
Authoritative order

Items, prices, total, cart version and status live in the database. The read-back and the confirmation come from here.

The model's tool calls are requests, not facts. The server is the only place an order changes.

What a caller can do

Each of these is a server tool the model can ask for. The server answers every request; the model never edits the order itself.

Ask what's on the menu get_menu
Ask about a dish, its options and pairings get_menu_item
Order items, with quantities, options and notes add_to_cart
Change a quantity or remove an item update_cart_item_quantity · remove_cart_item
Hear the order read back, exactly as the server has it get_cart
Confirm it for pickup or delivery submit_order

The AI is not the source of truth

A model can say something. Only the server can change the order.

What the assistant said conversation

“Great. I'll add garlic knots.”

No add_to_cart request followed.

What the server recorded order · authoritative

1 × Margherita Pizza + Extra cheese: $16.00
Garlic knots: not in the order
Total: $16.00

In a call to the early prototype, the assistant announced garlic knots but never called the tool that adds them. Nothing asked the server to change the order, so it stayed one Margherita pizza for $16, and that is what was submitted. The caller had been told something the order never contained.

The rewrite closes that gap on the server side. The read-back is now a sentence the server writes from the cart, so the caller hears exactly what will be submitted, and the operator's console highlights assistant lines that claim a change the server never received.

From the frozen prototype baseline, recorded before the rewrite.

Built for reliable tool execution

The rules that keep the order right when the model is wrong.

Prices come from the menu

The model names an item; Rails looks up its price and options and computes the total. Nothing the model says can set a price.

One version of the cart

Every change creates a new cart version. The read-back records which version the caller heard, and an order is accepted only at that version, so nothing can slip in after it.

Nothing is submitted without the caller

The server refuses a submit unless the caller spoke after the read-back. In a recorded call the model read the order back and submitted it in one breath; the server refused, then accepted it after the caller's yes.

Every request counts once

Each tool call is validated, applied at most once even if the voice platform retries it, and recorded in the same database transaction as the change it made.

Two submit_order rows from recorded test call #20. The first, 1.8 seconds after the last get_cart, is rejected with customer_confirmation_required: 0 caller turns since the last get_cart, nothing submitted, cart version 1 kept. The second, after the caller answered, is accepted: confirmed at version 1. — Recorded test call #20, server events: the first submit refused (customer_confirmation_required), the second accepted after the caller's yes.

Around it: the voice platform must present a shared secret with every webhook, and every page except this one and the sign-in page requires a signed-in operator.

See what the server actually accepted

What the model said, next to what the server did.

The operator console shows a call as it happens, and reviews it afterwards, in three views that never mix sources.

Conversation What was said, from the voice platform. Shown, never trusted.
Order board The order as the server holds it: items, total, cart version, read-back, confirmation.
Server events Every tool call: its arguments, the result, the cart version and how long it took.

The console's review of recorded test call #22. Left, the conversation from the voice platform, labelled not authoritative. Right, the server call and the order board from Rails, labelled authoritative: order #13, one Margherita Pizza with extra cheese, total $16.00, cart version 1, read-back delivered for v1, confirmation submitted v1. Below, server events: call started, get_menu, get_menu_item, add_to_cart (cart v0 to v1), get_cart. — Recorded test call #22, as the console's review page shows it. Select the image to open it full size.

Try the receptionist

Talk to it from the browser.

The voice console starts a real voice call in the browser and shows the conversation, the order and the server events side by side. Each call is a real, paid voice session, so the console is open to signed-in operators only.

What this demo is, and is not

✓Browser voice calls to one demo restaurant
✓Menu questions, ordering, changes, read-back and confirmation
–No phone number or text messages
–No payments and no transfer to a person

The model proposes.The server decides.