Superintelligence for Restaurants: What Data to Structure Now

Superintelligence for restaurants is not something you can buy yet. What exists are increasingly capable AI agents, and they only perform well when they find a menu, orders and customer data that are properly organized. The useful work today is structuring those three blocks, with clear rules for access and limits. Restaurants that do this can switch tools or models later without starting over.

Key takeaways

• The gain comes less from the AI model and more from the quality of your menu, order history and customer records.
• The menu must exist as structured data: ingredients, allergens, variations, availability and combination rules, not just as a photo or a PDF.
• Orders need consistent records of channel, items, changes, status and the reason for any problem, so an agent can learn what actually happens.
• Customer data requires a defined purpose, consent and the minimum necessary under Brazil's data protection law (LGPD) before any automation.
• The safe path is to map, limit, pilot one real workflow, and only then decide whether to expand.

What does superintelligence mean for someone running a restaurant?

The term is usually used to describe an AI that would outperform humans at practically any intellectual task. For a restaurant owner, the practical question is different: what can the next generation of agents do with the information your restaurant already has, and what can they not do because that information is a mess?

A more capable agent understands a confusing WhatsApp message better, combines information from several sources and carries out tasks in sequence. But it still depends on what it can look up. If the menu is an image, the stock lives in the cook's head and a customer's phone number sits in three different spreadsheets, the extra capability of the model solves nothing. It only produces more fluent answers built on uncertain data.

If you want to separate operational reality from futuristic debate, it helps to read about the difference between AGI, superintelligence and the agents a company actually runs. The conclusion that matters here: prepare your data, because it stays useful whatever direction the technology takes.

How to structure your menu so an agent can use it

The menu is the most consulted source of truth in a restaurant. Questions about ingredients, portion size, dietary restrictions and price come up constantly. For an agent to answer well, each dish needs a record with predictable fields.

Fields worth having for every item:

• Official name and the popular names customers usually use when ordering.
• A short description and a technical description (ingredients and general preparation method).
• Known allergens and restrictions: gluten, lactose, shellfish, nuts, pork, alcohol used in cooking.
• Suitability for diets (vegetarian, vegan), only when the kitchen is certain.
• Portion size and how many people it serves, in language the customer understands.
• Allowed variations and add-ons, and which combinations the kitchen does not accept.
• Availability by day, time and channel (dine-in, pickup, delivery).
• Current price, with the date of the last review and the person responsible for updating it.

The golden rule is that there is a single up-to-date version. If the dine-in menu, the delivery app menu and the WhatsApp menu differ, the agent will repeat the discrepancy. Pick one main source (a well-kept spreadsheet or your point-of-sale system) and treat every other channel as a copy.

For allergens, the stance should be conservative. If the kitchen has not confirmed a piece of data, the field should say it is unconfirmed, and the agent should pass the question to a person instead of risking an answer. That is a rule about limits, not about the capability of the model.

Which order data really matters?

Order history shows how the restaurant works in practice. The problem is that many places record the bare minimum: items and total. For an agent to genuinely help, it needs more context, always without overcollecting.

What is worth recording consistently:

• Channel of origin: dine-in, WhatsApp, delivery app, phone, pickup.
• Items, quantities and requested changes (no onions, how the meat is cooked, a swapped side dish).
• Status at each stage: received, confirmed, in preparation, ready, out for delivery, delivered or canceled.
• The reason for a cancellation, delay or complaint, chosen from a short list instead of free text.
• Payment method (for example Pix, card, cash), without storing sensitive card data.
• A flag for items that were missing or substituted.

This information lets an agent say where an order is, explain a delay based on the real status and suggest adjustments without making things up. It also lets you measure what works: which questions repeat, at what stage orders get stuck, which items generate the most changes.

One important detail is separating data from interpretation. Order status is a fact recorded by the system. Estimated arrival time is a forecast. The agent must know which is which and never present an estimate as a promise.

If you are thinking about how this flow shows up in customer service, the article on AI for restaurants: orders, reservations and FAQs on WhatsApp covers the conversation layer. This text covers the layer underneath: the data that supports that conversation.

Customer data: what to keep and what to leave out

This is where the most care is needed. A restaurant handles names, phone numbers, delivery addresses, dietary preferences and sometimes indirect health information, such as allergies. The LGPD requires a defined purpose, collection limited to what is necessary and transparency toward the person whose data it is. The national data protection authority (ANPD) is the official source for following guidance on the topic.

A lean customer record is usually enough:

• Basic identification: name and WhatsApp phone number.
• Addresses used for deliveries, linked to the customer and deletable on request.
• Preferences stated by the customer, such as not eating red meat.
• Dietary restrictions the customer reported, with the date and context in which they were said.
• A record of consent for outbound messages, with date and channel.

What to leave out: data with no clear use, complete conversations stored indefinitely without need, and any inference about health or religion drawn from consumption habits. An allergy reported by the customer is data to handle carefully, and it should be used to protect, not to segment campaigns.

Outbound messages, such as promotion alerts, require permission. It is worth learning how to collect WhatsApp opt-in before any automated campaign, because a contact list without recorded permission blocks future use and can cause problems with the channel.

Another practical point: define who can see what. The support agent needs the status of an order, but it does not need the full history of every customer. Role-based permissions, for both people and agents, reduce risk and make audits easier.

A step-by-step plan to start without a giant project

You do not need to replace your systems to get ready. The plan below fits a restaurant with only a few people in management, and each step delivers value even if the AI arrives later.

• Step one: list every place where the menu appears (dining room, app, WhatsApp, social media) and choose the main source.
• Step two: build a record for each dish with the fields described above and ask the kitchen to validate allergens.
• Step three: define a short list of order statuses and problem reasons, and get the team to always use the same words.
• Step four: write down on one page which customer data you collect, for what purpose and how long you keep it.
• Step five: record consent for outbound messages and separate those who agreed from those who did not.
• Step six: pick the ten most frequent customer questions and check whether the structured data can answer them.
• Step seven: define what the agent never decides alone, such as refunds, allergy exceptions and serious complaints, and who receives those cases.

Step six is a good maturity test. If a simple question, such as whether a dish contains lactose, requires opening three sources and calling the kitchen, the data is not ready for any agent, human or software.

Illustrative scenario: a simple question that depends on three pieces of data

Imagine a neighborhood restaurant that takes orders on WhatsApp. This is an illustrative scenario, not a real case. A customer writes: I would like the moqueca (a Brazilian seafood stew) for two people, but my wife cannot eat shrimp. Can we swap it?

To answer well, the agent needs to check the dish record (portion, ingredients, whether the swap is allowed), the day's availability (whether the alternative fish is in stock) and the house rule on allergies (whether the kitchen can avoid cross-contact). If the record says the swap is allowed and the dish is prepared in a separate pan, the agent confirms, records the change on the order and repeats the note for the kitchen. If the cross-contact field is empty, or the customer mentions a severe allergy, the agent does not improvise: it hands the conversation to a person with the summary already prepared.

No part of that decision depends on the model being more or less intelligent. It depends on the data existing, the rule being written down and the limit being defined. A more capable model improves how natural the conversation feels and how well it handles messy messages, but safety comes from the structure.

How to map, limit, pilot and hand over

The method we use in AI projects follows four moves, and they fit restaurants well.

Map: understand the current process and record the starting point. Which questions arrive, how much time the team spends answering, where orders get stuck. Without that picture, you cannot know whether the AI improved anything.

Limit: decide which data and which actions the agent can access. It looks up the menu and order status, but it does not change prices or refund money. This approach to limits follows the principle of giving the agent only the tools it needs, a theme covered in Anthropic's guidance on writing effective tools for agents.

Pilot: choose a single real workflow, such as answering menu questions on WhatsApp, with decisions logged and a metric agreed in advance. Anthropic recommends starting with the simplest solution and adding complexity only when necessary, an idea developed in its Building effective agents article.

Hand over: give the documented workflow to the team and decide, based on the records, whether to expand, adjust or stop. Stopping is also a legitimate result of a pilot.

To see how these blocks fit into a larger structure, the article on the company superintelligence layer shows the overall architecture. On the technical side, managing what the agent sees in each conversation is discussed under the name context engineering: short, well-organized records help more than dumping the entire menu into the agent.

What not to delegate, even to more capable agents

Technical capability does not remove responsibility. Some decisions should stay with people, or at least require human approval.

• Any answer about a severe allergy or health condition that the kitchen has not confirmed.
• Refunds, discounts outside the rules and compensation for mistakes.
• Public complaints and cases with a tone of conflict or reputational risk.
• Changes to prices, the menu and delivery rules.
• Use of customer data for new purposes without a new legal basis.

The same goes for automated decisions that affect the customer. If the restaurant ever uses automatic criteria to deny or limit something, you need to know the right to review provided by the LGPD, explained in the article on LGPD automated decision-making and the right to review. And every flow must have a clear path to reach a person.

Frequently asked questions

Do I need to wait for a more advanced AI to start? No. Organizing the menu, orders and consent is useful today, because it reduces errors and rework for the team, and it stays valid when better models arrive. What better models change is the quality of the conversation, not the need for reliable data.

Which data should I structure first? Start with the menu, because it answers the most frequent questions and carries low privacy risk. Next, standardize order statuses and problem reasons, and only then handle the customer records under the LGPD rules.

Can an agent answer questions about allergies? It can only report what the kitchen has confirmed and recorded in the dish record, making clear what is confirmed data. When the information is missing or the case is serious, it should pass the conversation to a person. The final decision on food safety should not belong to the agent.

Can I use customer conversation history to train or feed the AI? It depends on the purpose communicated to the customer, the legal basis and the minimum necessary. Before reusing conversations, review your privacy notice, anonymize what you can and confirm with the provider where the data is processed. If in doubt, seek specialized legal advice.

Sources

• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents
• Anthropic: Effective context engineering for AI agents
• ANPD: Autoridade Nacional de Proteção de Dados