AI waiter agent and kitchen display

AI with clear boundaries

• The menu is the only source. The model looks dishes up with a tool and the order is validated on the server: it cannot invent dishes, ingredients or prices. On allergens it only reports what is declared and never claims a dish is “safe”.
• “Gluten-free” only where it can be guaranteed. It is a regulated claim: the dish must not exceed 20 mg/kg of gluten (Regulation (EU) No 828/2014). The waiter only uses it for dishes made in the gluten-free area with their own utensils; for everything else it says “no gluten declared”.
• AI communicates; rules decide. The estimated wait, the load level and the delay notice to the platforms are calculated by fixed rules. The waiter only passes them on and cannot change them, not even if someone claims to be the manager.
• No personal data. The waiter never asks for names, phone numbers or payment details, and the table is set by the screen itself.
• Bounded cost. Short replies, a cap on messages per conversation, limits per visitor and per day, and a monthly spending cap on the API account. The key never reaches the browser.
• If the AI fails, service carries on. The kitchen does not depend on the model: it works just the same with a sample order.

Thoroughly tested: fixed rules around the model

The waiter was put through a battery of 65 test conversations, many of them tricky: allergens and coeliac disease, a minor asking for a beer, someone posing as the manager, requests for discounts, cancellations, impossible quantities, notes for the kitchen, other languages and a forged chat history. Real failures came up, such as saying an order had been sent when it had not, making up a price or promising a cancellation it could not make. The critical ones were not fixed with instructions alone, but with rules on the server:

• If the guest confirms the order that has just been summarised, the server forces it to be sent; if the reply still claims it was sent without sending it, the turn is repeated.
• Totals and per-dish waiting times are worked out by a tool (revisar_pedido), not by the model. Any amount that does not come from the tools or the conversation is corrected before the guest sees it.
• When an allergy is involved, a reply that guarantees something is “safe”, “suitable” or “risk-free” is corrected too.
• Every reply from the waiter is signed by the server: the history that comes back from the browser cannot be forged to make it “say” something it never said.

The battery is rerun after every change to the instructions, and the rules have automated tests with a simulated model, at no cost.

The waiter in person, and order tracking

The conversation takes place in an illustrated trattoria, by day or by night depending on the page theme. The waiter, a caricature, gestures according to what is happening: he greets you, takes out his notepad while you type, shows you the menu, does the chef’s kiss when recommending, gives a thumbs-up when the order is sent, raises a finger for allergens, checks his watch when the kitchen is busy and comes out with the plate when your order is ready. The gestures are chosen by fixed rules, not by the AI. Below the chat, order tracking shows what stage each of the table’s orders is at (received, in the oven or on the hot line, nearly ready, ready), how many minutes are left and whether it is running late. The waiter receives the same tracking with every message, so “how is my order going?” gets an answer based on data, not guesswork.

Sections and the service crew

The kitchen works by section, like a real one: pizza oven, hot line, salads and cold starters, and desserts and wash-up (whoever does desserts also washes up, so they handle less at once). At the start of service you choose the day and assign each employee a section. Capacity comes from the people and the equipment in each section: for example, each pizza chef handles 3 batches at once and the oven takes 8. On the pizza oven and the hot line, one person is designated for gluten-free dishes, with their own area and utensils, and only they prepare those dishes; without one, the service cannot start. Each section has its own wait, so the waiter can say a salad will come out well before a pizza.

Peak time: priority measured, not assumed

With 4 orders in the queue or 10 portions pending, the kitchen switches to “peak time” on its own, and returns to normal service with a lower load so it does not flip back and forth. The priority rule was chosen by measuring several alternatives on the same orders. Across 30 scenarios, with different loads and crew allocations, it never does worse than order of arrival, either in tables served on time or in the longest wait, and an automated test checks this again with every change. And the simulation makes one conclusion clear: when the kitchen is overwhelmed, no ordering fixes it; you need more hands.

Busy kitchen: no order turned away, the real wait communicated

Load is measured by what a new order would wait: the pending work in each section shared among the people in it, plus the dish’s own preparation time. From 20 minutes, the kitchen automatically notifies the online ordering platforms of that wait, updates it if it changes by 5 minutes or more, and withdraws the notice once it drops below 17: online customers see a realistic time and the restaurant does not lose the order. In the demo the notice is a simulated webhook (the call is shown, but nothing is sent); in a real restaurant it would connect to the platform’s API or to an order integrator, which allow the preparation time to be updated. In the dining room, the waiter mentions the wait when the load is high and suggests dishes from the least busy sections.

Service analysis: by section, never by person

Each dish records when it arrives, when it should start, when it starts and when it is ready, its section and how many people were in it. To show what those records can reveal, the demo generates eight weeks of fictitious services, Tuesday to Sunday, lunch and dinner, with the same kitchen simulator: demand changes with the day and the hour, and the crew from one service to the next. The panel shows demand by day and hour, the busiest services, the most ordered dishes and the share of gluten-free, the dishes that run late most often, the sections that act as bottlenecks and how each section performs by crew size. The crew planner tries every possible allocation against that service’s actual demand and proposes the best one. In a real restaurant, the records would go to a database with a dashboard on top (for example, PostgreSQL and Superset); each chart shows the equivalent SQL query.

There is no employee ranking, on purpose. Using AI to evaluate workers’ performance is high-risk under the EU AI Act (Annex III); in Spain, any algorithm that affects working conditions must have its rules disclosed to the works council (art. 64.4.d of the Workers’ Statute), and the GDPR requires personal data to be kept to a minimum. Besides, a section’s pace depends on the workload and the crew, not just on who is in it. That is why the records keep how many people were in each section, not who.