Superinteligência em cervejaria: registrar pedidos e lotes sem improviso

Na prática, uma superinteligência em cervejaria artesanal é um agente de IA que responde a clientes e à equipe sobre pedidos, lotes e entregas usando registros confiáveis da própria operação. Ele só consegue informar se há cerveja disponível, quando sai uma entrega ou em que etapa está um pedido quando esses dados existem em um lugar que ele consulta. Sem essa base, o modelo tende a dar uma resposta plausível, e é exatamente aí que a disponibilidade costuma ser inventada.

Principais pontos

• O agente só deve afirmar disponibilidade quando consulta um registro atualizado de lotes, reservas e entregas.
• Estoque físico, estoque reservado e prazo prometido são informações diferentes e precisam de campos separados.
• Cada lote precisa de um estado claro, como em maturação, liberado, reservado ou esgotado.
• Pedidos e entregas devem manter histórico de status, para que o agente explique o que mudou e o que falta.
• Quando o dado está ausente, desatualizado ou em conflito, a regra correta é transferir para a equipe, não estimar.

Por que o agente inventa disponibilidade

A operação de uma cervejaria tem muitas variáveis: um lote que ainda não terminou a maturação, barris já reservados para um bar, garrafas avariadas no envase, um distribuidor que pediu um volume que não existe mais. Um agente de conversa que não acessa essas informações preenche as lacunas com o que parece razoável. Isso não é apenas defeito do modelo. É uma falha de processo: a pergunta chegou, a fonte de verdade não existia ou não estava acessível, e o agente respondeu mesmo assim.

Na nossa leitura, esse tipo de erro costuma nascer antes do agente, porque o registro simplesmente não existe ou está em uma planilha que ninguém atualiza. Trata-se de uma hipótese de trabalho, que cada operação deve verificar em sua própria rotina antes de qualquer piloto.

Quais registros o agente precisa consultar

Antes de conectar qualquer ferramenta, vale listar os registros que sustentam as respostas mais comuns. Em geral, são cinco grupos:

• Lotes: identificação, estilo, data de início da produção, volume previsto, volume efetivamente envasado, estado atual e responsável pela liberação.
• Itens vendáveis: cada formato de envase e cada tamanho de barril, com código próprio, para que a equipe e o agente falem da mesma coisa.
• Reservas: vínculo com o pedido ou cliente, quantidade reservada e validade da reserva.
• Pedidos: canal de origem, itens, status (recebido, confirmado, separado, despachado, entregue ou cancelado) e histórico de mudanças.
• Entregas: transportadora ou rota, janela combinada, responsável e registro de ocorrências.

Também é útil registrar restrições de venda por canal ou região, para que o agente não ofereça um produto onde ele não pode ser entregue. Em todos os casos, mantenha apenas os dados de clientes necessários para a finalidade do atendimento. Isso reduz exposição e facilita a conformidade com a LGPD, como detalhamos na pergunta final desta página.

Como separar estoque físico, reserva e promessa

O erro mais comum de disponibilidade é tratar três números como se fossem um só. Estoque físico é o que está fisicamente na cervejaria. Estoque reservado é o que já foi comprometido com pedidos ou clientes. Prazo prometido é a data que alguém comunicou ao cliente. Quando um campo único mistura essas informações, o agente responde com base em um número que ninguém conferiu.

A regra recomendada é simples: disponível para venda é o estoque físico liberado menos o reservado. Esse valor deve ser calculado pelo sistema ou pela planilha oficial, e o agente deve apenas lê-lo. Se o agente precisar fazer a conta de cabeça a partir de mensagens antigas, a resposta já está errada por construção.

Passo a passo para montar a fonte de consulta

A montagem pode começar pequena e crescer depois de um piloto. A sequência abaixo evita o erro de conectar tudo de uma vez:

• Passo 1: liste as perguntas que o agente vai responder, como disponibilidade de um estilo, status de um pedido e previsão de entrega.
• Passo 2: para cada pergunta, defina qual registro é a fonte oficial e quem é responsável por atualizá-lo.
• Passo 3: padronize estados de lote e de pedido com poucos valores fixos, evitando texto livre no campo de situação.
• Passo 4: dê ao agente permissão somente de leitura sobre esses campos no início, sem poder de alterar estoque ou reserva.
• Passo 5: teste com perguntas reais de uma semana anterior e compare a resposta do agente com a que a equipe daria consultando o sistema. Testes com dados simulados ajudam nessa etapa, como explicamos em como testar agente de IA com mocks e sandbox.
• Passo 6: registre, em cada resposta, qual fonte foi usada e a data da última atualização daquele registro.

Cenário ilustrativo: pedido de um estilo em fim de lote

Cenário ilustrativo: um cliente pergunta por caixas de uma IPA que aparece no site. O registro mostra que o lote está em maturação, que parte do volume já está reservada para um distribuidor e que o restante aparece como liberado para o taproom. O agente consulta o disponível calculado, informa a quantidade que pode ser oferecida, explica que a data de liberação ainda depende da confirmação da produção e cria uma solicitação para a equipe confirmar. Se o registro estivesse vazio ou com a última atualização de semanas atrás, a resposta correta seria dizer que não é possível confirmar agora e transferir o caso.

Regras de decisão: quando responder e quando transferir

Um agente útil sabe quando não deve responder. Estas regras são um bom ponto de partida para a equipe discutir e ajustar:

• Responder diretamente quando o estado do lote e o disponível calculado estão atualizados e são suficientes para a pergunta.
• Informar o status de um pedido quando o histórico mostra a última mudança e a data em que foi registrada.
• Transferir para a equipe quando o registro está desatualizado, em conflito com outro registro ou ausente.
• Nunca confirmar prazo de entrega que depende de transportadora sem janela de coleta registrada.
• Nunca alterar reserva, estoque ou prazo sem aprovação humana registrada.

Se o atendimento acontece pelo WhatsApp, também vale verificar as regras de envio de mensagens fora da janela de conversa antes de programar retornos automáticos. Esse ponto está detalhado em janela de 24 horas no WhatsApp API e o agente de IA.

Como aplicar o método em um piloto

Nosso método de trabalho segue quatro movimentos: mapear o processo atual e a linha de base, limitar dados e ações, pilotar um fluxo real com registros e uma métrica de sucesso combinada antecipadamente, e então transferir o resultado para a equipe e decidir se a operação expande, ajusta ou para. Em uma cervejaria, faz sentido começar por uma linha de produtos e por um tipo de pergunta, como status de pedido ou disponibilidade de um estilo. Fluxos de pedido e reserva com lógica parecida aparecem em outros setores, como em IA para restaurantes com pedidos e reservas, e a lição se repete: primeiro o registro, depois a resposta.

O objetivo do piloto não é provar que a IA sabe muito sobre cerveja. É verificar se o agente responde apenas com o que está registrado e transfere o resto com clareza.

Perguntas frequentes

O agente consegue ver o estoque em tempo real? Depende de como a cervejaria registra as movimentações. Se a contagem é atualizada uma vez por dia em planilha, o agente só pode responder com essa defasagem explícita, informando a data da última atualização. Tempo real exige que a movimentação de envase, reserva e saída seja registrada no momento em que acontece.

É preciso um sistema específico para começar? Não necessariamente. Uma planilha bem estruturada, com campos fixos, um dono para cada campo e histórico de alterações, pode servir ao piloto. O importante é que a fonte seja única para cada tipo de informação e que o agente leia sempre do mesmo lugar.

Como a LGPD entra nesse caso? Pedidos e entregas trazem dados pessoais de clientes, como nome, endereço e telefone. Por isso, o agente deve acessar somente o necessário para cada finalidade, com permissões restritas e registro das consultas. Orientações oficiais sobre o tema estão disponíveis na página da ANPD.

E se o cliente insistir em uma data que o sistema não confirma? O agente não deve inventar uma data para encerrar a conversa. A resposta adequada é explicar que a data depende de confirmação, registrar o pedido de retorno e transferir o caso para uma pessoa da equipe com todo o contexto já resumido.

Fontes

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