Superintelligence for Craft Breweries: Record Orders and Batches Properly

In practice, superintelligence for a craft brewery is an AI agent that answers customers and staff about orders, batches and deliveries using reliable records from the brewery's own operation. It can only tell whether beer is available, when a delivery leaves or which stage an order is in when that data exists in a place the agent can query. Without that foundation, the model tends to give a plausible answer, and that is exactly where availability often gets invented.

Key takeaways

• The agent should only state availability when it checks an up-to-date record of batches, reservations and deliveries.
• Physical stock, reserved stock and promised lead time are different pieces of information and need separate fields.
• Each batch needs a clear status, such as maturing, released, reserved or sold out.
• Orders and deliveries should keep a status history so the agent can explain what changed and what is still pending.
• When data is missing, outdated or conflicting, the correct rule is to hand the case to the team, not to estimate.

Why the agent invents availability

A brewery's operation has many moving parts: a batch that has not finished maturing, kegs already reserved for a bar, bottles damaged at the filling line, a distributor who asked for a volume that no longer exists. A conversational agent that cannot access this information fills the gaps with what sounds reasonable. This is not only a model defect. It is a process failure: the question arrived, the source of truth did not exist or was not accessible, and the agent answered anyway.

In our reading, this kind of error usually starts before the agent, because the record either does not exist or lives in a spreadsheet nobody updates. This is a working hypothesis, and each operation should verify it in its own routine before any pilot.

Which records the agent needs to query

Before connecting any tool, list the records that support the most common answers. In most breweries, there are five groups:

• Batches: identification, style, production start date, planned volume, volume actually filled, current status and the person responsible for release.
• Sellable items: each packaging format and each keg size, with its own code, so the team and the agent refer to the same thing.
• Reservations: link to the order or customer, reserved quantity and reservation expiry.
• Orders: sales channel, items, status (received, confirmed, picked, dispatched, delivered or cancelled) and change history.
• Deliveries: carrier or route, agreed window, responsible person and log of incidents.

It also helps to record sales restrictions by channel or region, so the agent does not offer a product where it cannot be delivered. In every case, keep only the customer data needed for the purpose of the conversation. This reduces exposure and makes compliance with Brazil's LGPD data protection law easier, as we explain in the last question of this page.

How to separate physical stock, reservation and promise

The most common availability mistake is treating three numbers as one. Physical stock is what is actually in the brewery. Reserved stock is what has already been committed to orders or customers. Promised lead time is the date someone communicated to the customer. When a single field mixes these, the agent answers based on a number nobody checked.

The recommended rule is simple: available for sale is released physical stock minus reserved stock. The system or official spreadsheet should calculate this value, and the agent should only read it. If the agent has to work this out from old messages, the answer is already wrong by design.

Step by step: building the query source

The setup can start small and grow after a pilot. The sequence below avoids the mistake of connecting everything at once:

• Step 1: list the questions the agent will answer, such as availability of one style, status of an order and expected delivery.
• Step 2: for each question, define which record is the official source and who is responsible for updating it.
• Step 3: standardize batch and order statuses with a few fixed values, avoiding free text in the status field.
• Step 4: at the start, give the agent read-only permission on these fields, with no ability to change stock or reservations.
• Step 5: test with real questions from a recent week and compare the agent's answer with what the team would say after checking the system. Tests with simulated data help at this stage, as we explain in how to test AI agents with mocks and a sandbox.
• Step 6: record, in each answer, which source was used and the date that record was last updated.

Illustrative scenario: an order for a style near the end of a batch

Illustrative scenario: a customer asks for cases of an IPA that appears on the website. The record shows that the batch is still maturing, that part of the volume is already reserved for a distributor, and that the rest appears as released for the taproom. The agent checks the calculated available quantity, tells the customer how much can be offered, explains that the release date still depends on production confirmation, and creates a request for the team to confirm. If the record were empty or had not been updated for a long time, the correct answer would be to say that availability cannot be confirmed right now and to hand the case over.

Decision rules: when to answer and when to hand over

A useful agent knows when not to answer. These rules are a good starting point for the team to discuss and adjust:

• Answer directly when the batch status and the calculated availability are up to date and sufficient for the question.
• Report an order's status when the history shows the latest change and the date it was recorded.
• Hand over to the team when the record is outdated, conflicts with another record or is missing.
• Never confirm a delivery date that depends on a carrier without a registered pickup window.
• Never change a reservation, stock figure or promised date without recorded human approval.

If service happens on WhatsApp, also check the rules for sending messages outside the conversation window before scheduling automatic follow-ups. This point is covered in the WhatsApp 24 hour window and the AI agent.

How to apply the method in a pilot

Our working method follows four moves: map the current process and its baseline, limit data and actions, pilot a real flow with records and a success metric agreed in advance, then bring the result to the team and decide whether the operation expands, adjusts or stops. In a brewery, it makes sense to start with one product line and one type of question, such as order status or availability of one style. Order and reservation flows with similar logic appear in other sectors, such as AI for restaurants with orders and reservations, and the lesson repeats: the record comes first, then the answer.

The goal of the pilot is not to prove that the AI knows a lot about beer. It is to verify that the agent answers only with what is recorded and hands off the rest clearly.

Frequently asked questions

Can the agent see stock in real time? It depends on how the brewery records movements. If counts are updated once a day in a spreadsheet, the agent can only answer with that delay stated explicitly, including the date of the last update. Real time requires that filling, reservation and dispatch movements are recorded at the moment they happen.

Do I need a specific system to start? Not necessarily. A well-structured spreadsheet with fixed fields, one owner for each field and a change history can support a pilot. What matters is that each type of information has a single source and the agent always reads from the same place.

How does the LGPD apply in this case? Orders and deliveries contain personal data about customers, such as name, address and phone number. For that reason, the agent should access only what is necessary for each purpose, with restricted permissions and a log of queries. Check the official guidance from Brazil's data protection authority (ANPD) for the current requirements.

What if the customer insists on a date the system does not confirm? The agent should not invent a date to end the conversation. The right response is to explain that the date depends on confirmation, log a callback request and hand the case to a person on the team with the full context already summarized.

Sources

• Anthropic: Writing effective tools for agents
• OWASP: Authorization Cheat Sheet
• ANPD: Autoridade Nacional de Proteção de Dados