Yasmin — agente de IA para pedidos via WhatsApp
Um agente de IA que cria pedidos reais, com travas determinísticas em código para conter as falhas do próprio modelo.
- pedidos a cada dois dias
- ~100
- travas, cada uma de um incidente real
- 12
- agentes especialistas + um validador de voz
- 3 + 1
Problema
Uma hamburgueria atendia pedidos pelo WhatsApp à mão: alguém lia cada conversa e redigitava o pedido em um sistema à parte. Conectar as APIs era a parte fácil. O problema real era manter um agente com tool-calling confiável o bastante para lidar com dinheiro — um ID de produto alucinado ou uma forma de pagamento não confirmada não é bug cosmético, é pedido errado ou receita perdida.
Solução / arquitetura
Um sistema multi-agente em n8n: um orquestrador fino que roteia por gates determinísticos, especialistas por domínio (pedidos, atendimento, pós-venda) com ferramentas próprias, e um Validador final que reescreve toda saída numa voz única. A lógica mora no especialista e a voz mora no Validador, então mexer no tom nunca arrisca quebrar a lógica de pedido. Entre o modelo e a API do fornecedor fica uma camada de travas em código.
Impacto
- Doze travas determinísticas, cada uma nascida de um incidente em produção — todas rejeitando com uma instrução acionável para o agente, não com um código de erro que ele parafrasearia mal para o cliente.
- Causa raiz de IDs de produto inválidos: a API do fornecedor expunha um campo interno não documentado com o mesmo formato numérico dos IDs reais. Duas correções de prompt já tinham falhado; a solução foi uma trava em código.
- Encontrei uma falha silenciosa que existia havia meses — uma ramificação de fluxo nunca conectada — auditando as conexões depois de descartar todas as outras hipóteses com evidência.
- Engenharia reversa da precificação não documentada do fornecedor, com pedidos reais: dois campos que enviávamos eram descartados em silêncio, e o campo de troco documentado era outro.
- Um interceptador substitui a mensagem quando o agente anuncia um pedido que nunca foi criado. Já pegou uma confirmação falsa ao vivo.
- Testes de falha (credencial inválida, host inalcançável) em clones isolados do fluxo — degradação graciosa provada sem tocar no atendimento real.
Ler a história completa
O princípio que saiu disso, e que hoje aplico por padrão: a prova de um evento de conversa tem que ser externa ao modelo. Exigir um campo não faz a pergunta acontecer. Um pedido saiu marcado como crédito para um cliente que tinha dito débito, porque o modelo preencheu o campo obrigatório com um valor plausível. A correção não foi reescrever o prompt — o valor que o modelo manda passou a ser ignorado, e a forma de pagamento é derivada da fala do cliente por mapeamento fixo, que o agente não consegue forjar.
A mesma ideia tirou um evento de negócio das mãos de um classificador LLM: o clique em “Bom” na pesquisa de satisfação era classificado como saudação. Virou um gate de igualdade exata.
Do lado do fornecedor, dois pedidos reais provaram que os campos de total e de taxa que enviávamos eram descartados e recalculados pelo catálogo dele. O modo de falha mais caro de API não documentada é o nome de campo errado que não dá erro, só não faz nada. Uma taxa de entrega que a plataforma não deixava cadastrar foi resolvida desacoplando a zona de cobrança da localidade real de entrega.