Why your restaurant has multiple AI mouths

The same AI brain serves three different audiences in your restaurant. A customer at table 4 gets one answer, the waiter taking their order gets another, and you sitting in the office get a third — about the same dish. This is not three different AIs. It’s one AI with three different microphones, and each microphone is tuned for who’s holding it.

This page is for owners and managers who wonder why the customer-facing assistant won’t tell a diner the cost of a dish, why the cashier-side AI tells the waiter exactly that, and why the admin chat can do things neither of the others can.

What it does

The three AI surfaces share the same notebooks (live menu, catalogue, narrative — see How the AI thinks about your menu), but each one is given different rules about what it’s allowed to say, what it’s allowed to do, and what tone it speaks in.

The mouth	Who it serves	What it sees	What it can do	What it never does
The customer assistant	A diner on the public menu	Live menu + catalogue + venue narrative + dish descriptions	Recommend dishes, explain ingredients, suggest pairings, escalate allergen questions to the manager	Quote costs to the diner, reveal internal notes, confirm allergen safety alone, recommend anything not currently available
The waiter / cashier coach	A server at the till, mid-service	Everything the customer sees, plus internal dish notes, supplier names, upsell rationale, allergen cross-contamination flags	Suggest upsells, explain a dish in depth, flag allergen risks, surface pairing logic with the why	Move money, place orders for the guest, override the kitchen on availability
The admin chat	You, the owner or manager, in the back office	Everything the waiter sees, plus the ability to act: change a price, hide a dish, mark something recommended	Change menu prices, set items unavailable, set items featured, look up sales data	Delete data, change financial records, do anything outside the admin’s audit-logged tool set

Notice that each row is a strict superset of the row above it: the customer sees the smallest slice, the waiter sees more, the admin sees the most. This shape is enforced at the code level — the AI cannot accidentally tell a customer what’s in the waiter’s notebook.

How to use it

The “is it gluten-free?” scenario, three ways

Same question, three mouths, three different correct answers.

Customer asks the menu AI on the public site: “Is the pasta al limone gluten-free?”

→ AI answer: “The pasta al limone is made with regular wheat pasta — it contains gluten. We can swap to a gluten-free pasta if you let us know now; let me ask the kitchen to also check for cross-contamination since the cooking water is shared.”

The customer mouth declares the ingredient honestly, offers the swap, refuses to confirm safety alone, and escalates to the kitchen. It never says “yes, it’s safe.”

Waiter asks the cashier AI: “Is the pasta al limone safe for a celiac?”

→ AI answer: “The dish itself is regular wheat pasta. Our gluten-free alternative is available, but check the internal note on this dish — the chef has flagged that the boiling water is shared with the standard pasta. For a celiac, we need to switch to the dedicated allergen-pan setup — talk to the chef before confirming.”

The waiter mouth pulls up the same dish but adds the internal note (cross-contamination risk in the boiling water) and tells the waiter what to do about it. The customer mouth would have escalated; the waiter mouth tells you how to escalate.

Admin chat: “Make the pasta al limone unavailable for the rest of tonight.”

→ AI action: “Marked the pasta al limone as unavailable on the POS, hidden from the public menu until you re-enable it. Logged the action in the audit log under your name.”

The admin mouth doesn’t just say — it does. The customer and waiter mouths can never act on the data; the admin mouth can, and every action is recorded.

The rule that justifies three mouths instead of one

Each mouth is tuned for the cost of saying the wrong thing.

A customer hearing the wrong allergen answer is a hospital visit. A waiter hearing the wrong allergen answer can verify with the chef before plating. An owner hearing the wrong availability answer just refreshes the screen. The three mouths exist because the same data, said to the wrong audience, would be dangerous, unhelpful, or annoying.

The technical word for this is surface. The customer surface is the most defensive (refuses to confirm safety, never reveals internal data). The waiter surface is more informative (sees internal notes, suggests upsells). The admin surface is most powerful (can act on the data, audit-logged). The same underlying retrieval — same notebooks — but a different ruleset wrapped around each one.

Worked examples

🍕 Pricing question — Customer asks “how much is the truffle pizza?” on the public menu. Customer mouth: “The price is shown next to the dish — €28.” (Reads from POS, returns the public price.) Waiter mouth, asked the same question by a server: “€28 to the guest. The kitchen makes about €19 margin on this — the truffle is the cost driver. If the guest asks about value, you can mention the truffle is 8 grams from Acqualagna.”
🍷 Allergen question on a beverage — Customer asks the menu AI “does the house cocktail contain dairy?”. The AI checks the catalogue (the dish has no dairy tag), but escalates anyway: “The house cocktail is made with vodka, lime, basil, and a sugar syrup. No dairy ingredients in the recipe — but let me confirm with the bar that the syrup doesn’t use a dairy-based fining agent.” Waiter mouth, asked by the bartender, gets a direct answer because the chef has flagged in internal notes that the syrup is plant-based, no fining.
⚠️ An action question — Owner asks the admin chat “why is the carbonara not selling?”. The admin mouth pulls last 7 days of POS data, returns “You sold 4 carbonaras this week vs 22 last week. The price was raised from €16 to €19 on Monday — the drop correlates.” The customer and waiter mouths cannot do this — they don’t read sales data and can’t reason about trends.
🛑 An action a mouth refuses — Admin asks “delete all the data from last Tuesday.” The admin mouth refuses: “Deletion of historical sales data is not in the audit-logged tool set. If you need to correct a specific entry, point me to the row and I’ll flag it for correction.” Every mouth has a refusal list — that’s part of being tuned.

What you set, where

You don’t configure the three mouths directly. They are pre-built and locked. What you can configure is what you put into the three notebooks, knowing how it flows downstream:

Public dish description → readable by all three mouths.
Internal notes on a dish → readable by waiter and admin mouths; the customer mouth strips it out.
Venue AI context → readable by all three; the customer mouth ignores any section explicitly marked ## Internal (a convention, planned for Phase D).
Prices, costs, availability → operational data; the customer sees only the public price, the waiter sees the cost, the admin sees both plus history.

Where your information lives — five places, one restaurant — the data behind every mouth
How the AI thinks about your menu — the three notebooks each mouth reads from
How the AI uses your food & beverage knowledge — the narrative layer all three mouths share