An AI phone agent for restaurants is really a grammar for your cuisine. Pick the vendor that actually ships yours.
Pizza shops, sushi bars, Indian chains, Chinese family restaurants, and Mexican kitchens do not share a phone order. They share a dial tone. The voice stack is the same for all of them. The grammar is not. This is the grammar PieLine ships per cuisine, and how to tell a real restaurant agent from a rebranded generic one in under five minutes.
The word "restaurant" hides five different products
A generic "AI phone agent for restaurants" demo reel always uses a neutral test order: a cheese pizza, a small sushi roll, a chicken fried rice. Any voice bot with a menu lookup can handle that call. The real test is the first phone order that is specific to your cuisine: the half-pepperoni-half-veggie with extra cheese on the veggie half, the nori-out spicy tuna roll with cucumber instead of rice, the saag paneer with tofu instead of paneer extra spicy as a lunch combo.
Those three phone orders share a dial tone. They do not share a backend. A pizza shop needs fractional pricing on a single pie. A sushi bar needs a roll builder with typed swaps. An Indian chain needs a spice level on every curry and a protein substitution tree. The agent that can handle all three is not one product. It is five products stacked behind one voice stack.
The anchor fact
PieLine's feature copy names four cuisine-specific modifier patterns explicitly: half-and-half pizzas, spice levels, protein substitutions, and custom sushi rolls. Each is a declared modifier type on the dish ontology.
That phrase is not marketing flavor. It is the shape of the backend. A modifier type is a validated field with bounded options, not a free-text note appended to the kitchen ticket. When the caller says "half pepperoni, half veggie," the agent writes a structured modifier that the POS understands, not a string that a cook has to interpret.
Source: llms.txtin this repo, Features line 27 ("cuisine-specific customization including half-and-half pizzas, spice levels, protein substitutions, custom sushi rolls").
Five cuisines, five grammars the agent has to speak
Every row below is a real modifier pattern a restaurant phone agent has to understand before it takes the first call in that cuisine. These are not edge cases. They are the shape of 80% of the orders.
Pizza
Fractional pricing on half-and-half pies, per-half toppings, crust types (hand-tossed, thin, gluten-free), oven-ready timing cues. The agent has to quote a price that respects the more expensive half, not average the two.
Sushi
A roll builder with fish and rice swaps, nori-in vs nori-out, spice additions, and per-roll allergen flags. Custom rolls are a first-class declared type, not a free-text note to the itamae.
Indian
Spice level on every curry (mild, medium, spicy, extra spicy) with per-dish defaults, protein substitutions (paneer, chicken, tofu), and lunch combo applicability windows.
Chinese
Protein substitution trees across entrees (beef, chicken, shrimp, tofu), sauce intensity, family-style combo math, and "no MSG" or "no onion" as typed dietary modifiers, not kitchen notes.
Mexican
Salsa heat choices, build-your-own-bowl or burrito grammar with base, protein, toppings, extras, and a corn vs flour tortilla switch. The agent asks in a fixed order so the ticket is always consistent.
QSR + delis + family diners
Combo deals, happy-hour pricing windows, minimum order thresholds, and delivery zone caps. Applicability rules are declared so the agent never offers the lunch combo at 9pm.
A pizza order, frame by frame
Half-and-half pizzas are the pizza-shop acid test. A generic voice bot will either average the topping prices, mis-quote the total, or write the halves as a free-text note the oven tender has to read at 10pm on a Friday. Here is what the grammar looks like when it is declared, not guessed.
Caller: half pepperoni, half veggie
What the agent is doing while the caller talks
Voice in, ticket out. The middle is where a restaurant agent differs from a generic one. Every beam below carries a structured payload the ontology already knows how to validate.
A single call, five cuisines, one backend shape
One dish, one grammar, in code
A curry on an Indian menu is not just a POS row. The row the phone agent works from has to include a spice level default and offered set, a protein substitution tree, and an applicability window for lunch combos. This is what that looks like.
Notice the applicability window on the lunch combo. The agent will offer the combo at noon, quietly drop the option at 4pm, and never contradict the kitchen. That rule lives in the grammar, not in a prompt.
Grammar required by cuisine
Same voice stack. Entirely different modifier backends. A restaurant agent either has the grammar built for your cuisine or it does not.
| Feature | What the agent must handle | Example shape |
|---|---|---|
| Pizza shop | Fractional pricing on half-and-half pies, per-half topping sets, crust types, oven timing. | Typed pizza object with two halves, per-half modifier list, scoped extras. |
| Sushi bar | Roll builder with fish and rice swaps, nori-in vs nori-out, per-roll allergen flags. | Typed roll object with swap options as declared modifier fields. |
| Indian chain | Spice level per dish with a default and offered set, protein substitutions, lunch combos. | select_one spice modifier, optional protein_sub, boolean combo with applicability window. |
| Chinese family restaurant | Protein substitution trees across entrees, sauce intensity, family-style combo math. | Per-entree protein_sub options, sauce enum, family_combo typed bundle. |
| Mexican kitchen | Salsa heat, build-your-own bowl or burrito grammar, tortilla switch. | Ordered step builder: base, protein, toppings, extras, salsa_level enum. |
| QSR, delis, diners | Combo deals, happy-hour pricing, minimum order thresholds, delivery zone caps. | Applicability rules declared per item and per order. |
A vendor that lists 'restaurant' as a single use case is probably shipping the first column. A vendor built for restaurants is shipping the second one per cuisine.
How to tell in five minutes whether a vendor ships your grammar
Do not accept a neutral demo. Run the acid test order from your own menu. Watch where the agent and the ticket disagree. These are the five steps a phone-ordering operator should run before signing anything.
The five-minute vendor test
Pick the hardest real order you took last week
Not a cheese pizza. Not a California roll. The actual three-modifier order with an allergen question and a substitution. If the vendor cannot handle it, you already have your answer.
Ask to hear the agent take it
Any serious vendor can run a live sample call during a demo. The voice stack is commodity, so this part will sound fine. That is not the test yet.
Ask to see the resulting POS ticket
This is where the grammar question gets answered. A real restaurant agent writes line items with modifier IDs. A generic agent writes a free-text kitchen note and hopes.
Ask what happens if your menu changes tomorrow
If the vendor says 'we update the prompt,' the grammar does not exist. If they say 'we update the modifier tree and the ontology,' the grammar exists and you can trust month two.
Ask which POS systems are wired out of the box
Clover, Square, Toast, NCR Aloha, and Revel are the table stakes. If they only integrate via webhook, you are going to be re-keying at a station and the 95% accuracy number is meaningless.
The test call, as a printout
Here is what a clean grammar looks like when a sample order is echoed from the agent into the POS payload. Nothing in the ticket is a string. Every modifier is a typed value.
How PieLine builds the grammar for your restaurant
The reason you cannot just buy a generic voice bot and expect this to work is that the grammar has to exist before the first call. Here is the pipeline PieLine runs during step 2 of onboarding, the same day you sign up.
Scrape your existing online menu
Whatever you already publish (DoorDash, Toast Online Ordering, your own site) becomes the first pass. Names, prices, categories, and short descriptions are extracted.
Map each item to a POS item ID
We match every scraped dish to your Clover, Square, Toast, NCR Aloha, or Revel catalog so tickets land with the right price and tax row.
Pick the cuisine grammar
Pizza, sushi, Indian, Chinese, Mexican, QSR, or one of the variant grammars. Your restaurant's cuisine determines which modifier types get wired in by default.
Wire the modifier tree
Half-and-half patterns for pizza, roll builders for sushi, spice and protein trees for Indian, and so on. Declared types against the POS item IDs, not prompts.
Monitored first month
Active call monitoring and AI refinement during the first 30 days. Every call where the agent escalated on a grammar gap becomes the next week's grammar update.
What a restaurant actually sees when the grammar is missing
These are the failure modes a phone-ordering operator sees on a Saturday night when a generic agent was configured against a raw POS export without a cuisine grammar on top. They are not speculative. They are what happens when the modifier tree does not exist.
- Half-and-half pizzas priced as an average. Generic agents without fractional pricing quote the mean of the two halves. That is not how pizza pricing works. The shop either loses margin on every half-and-half or angers callers with a correction after the quote.
- Custom sushi rolls as free-text notes. Without a roll builder, "spicy tuna, cucumber instead of rice, nori out" hits the kitchen as a string. The itamae either reinterprets it or calls the caller back from a cell phone.
- Indian spice level as a guess. Without a declared default plus offered set, the agent either always defaults to mild (angering regulars) or tries to answer "how spicy is it" from whatever text was scraped off DoorDash.
- Lunch combos offered at dinner. Without applicability windows declared in the grammar, the agent will cheerfully offer the lunch combo at 9pm. The kitchen refuses, the caller remembers, and the phone line earned a complaint.
Modifier types PieLine ships as declared grammar, not free-text
What this looks like at restaurants running on PieLine
PieLine runs across multiple cuisines in live production. The grammar is not the same for each, but the way it gets built is. Three examples from the current roster.
Mylapore (South Indian, 11 locations)
Projected additional revenue per location per day from eliminating the phone bottleneck. Grammar: per-curry spice level, protein substitution, lunch combo window.
Idly Express (Almaden)
Share of calls completed end-to-end by AI. The 10% that escalates is by design: catering, complaint, or an edge case the grammar has not indexed yet.
Chinese, pizza, Indian, Mexican
POS systems integrated. Clover, Square, Toast, NCR Aloha, and Revel are in the default path. Grammar is wired per cuisine, not per POS.
“The experience was better than speaking to a human. No hold time, no confusion, no rushing.”
Bring your hardest real order to the demo
Book a 20 minute walkthrough. Tell us your cuisine. We will show you the modifier grammar your agent needs and play a sample call against your own menu.
Book a call →Frequently asked
Why do you say there is no such thing as a single AI phone agent for restaurants?
Because the word "restaurant" covers radically different phone orders. A pizza phone order needs fractional pricing for half-and-half pies. A sushi order needs a roll builder with optional fish and rice swaps. An Indian order needs a spice level on every curry. A Chinese order needs a protein substitution tree. A Mexican order needs salsa heat plus a build-your-own-bowl grammar. These are different products in the backend, even though they share the voice stack on the front. The right question for a vendor is not "does it work for restaurants" but "does it ship the grammar for my cuisine."
What does PieLine actually ship per cuisine?
PieLine names four cuisine-specific modifier patterns in its feature copy: half-and-half pizzas (fractional pricing and kitchen note shape), spice levels (per-dish default plus offered set), protein substitutions (typed options per dish), and custom sushi rolls (roll builder with swap options). Each is a declared modifier type on the dish ontology, not a free-text note. Add the POS item ID map on Clover, Square, Toast, NCR Aloha, or Revel and the modifier IDs land on the kitchen ticket without a human re-keying anything.
What is the fastest way to tell if a vendor built restaurant grammar or just rebranded a generic voice bot?
Pick the hardest phone order your shop actually takes and ask the vendor to play it back. For a pizza shop: "half pepperoni, half veggie, extra cheese on the veggie half only, gluten-free crust." For sushi: "spicy tuna roll, swap rice for cucumber, add avocado." For Indian: "saag paneer with tofu instead of paneer, extra spicy, as a lunch combo." If they answer in natural language but the ticket comes out as a free-text note, the grammar does not exist. If the ticket lands with modifier IDs in the POS, it does.
Does PieLine work for cuisines you have not explicitly listed?
Yes. The modifier tree is a general structure, and the cuisines PieLine ships grammar for are just the ones where the patterns are common enough to be declared as standard types. New cuisines get their patterns declared during onboarding step 2, where PieLine's team wires the modifier tree against your POS item IDs before the first call. A Thai shop, a Vietnamese pho counter, a Mediterranean bowl place: all build grammars from the same modifier primitives.
Who actually builds the grammar for a specific restaurant?
PieLine's onboarding team. The owner does not sit down and type out a spice level for 180 dishes. Step 2 of onboarding scrapes your online menu, maps each item to a POS item ID, writes the description rows, and wires the modifier tree. Owner reviews, not authors. This is why PieLine can go live same day on a typical restaurant, and why a generic voice bot that makes you author the grammar yourself takes weeks.
What happens when a caller asks about a menu item PieLine has not indexed yet?
The agent routes the call to a manager with the full transcript attached. Novel menu items not yet in the ontology are one of the named escalation triggers. The agent does not price a dish it has not seen, and it does not claim an allergen fact on a dish without verified flags. 90%+ of calls complete end-to-end by AI; the 10% escalation is by design, not a failure mode.
What does this cost, and how does it compare to a phone employee?
$350 per month covers up to 1,000 calls. $0.50 per call beyond that. Onboarding, including the grammar build for your cuisine, is included. A dedicated phone person costs $3,000 to $4,000 per month and handles one call at a time. PieLine handles up to 20 simultaneous calls on the same line. There is a money-back guarantee on the first month if the 95%+ order accuracy or 90%+ AI-handled call rate does not hold for your restaurant.
How does PieLine connect to my phone line and POS?
No hardware. You forward your existing restaurant line to PieLine, or set PieLine as an overflow destination when staff cannot pick up. Takes about ten minutes on your carrier's website. POS integration runs on Clover, Square, Toast, NCR Aloha, and Revel out of the box, with 50+ POS systems supported. Orders land in the POS as line items with modifier IDs, not free-text notes a cashier has to re-enter.
Deeper on the layers that make a restaurant phone agent work
Keep reading
The dish ontology layer behind every real restaurant phone agent
The four layers of a generic phone agent plus the one layer only a restaurant-specific agent ships: the per-dish description schema.
POS integration: what actually happens between the agent and Clover, Square, Toast
Where modifier IDs come from, why a webhook is not a POS integration, and how PieLine avoids re-entry.
20 simultaneous calls: the capacity math behind zero hold time
What it takes to answer every Friday night call on the first ring, and why a human phone employee cannot.