Agente de superinteligência em estoque: reposição com trava

Um agente de superinteligência em estoque é, na prática, um agente de IA que lê o histórico de vendas, o saldo e as regras de compra da empresa e sugere o que repor e em que quantidade. A decisão de gastar dinheiro não fica com ele: travas de valor e aprovação humana definem até onde a sugestão vira pedido. O termo superinteligência é um rótulo de mercado. O que se opera de verdade é um sistema com escopo estreito, regras explícitas e registro de cada decisão.

Principais pontos

• O agente sugere, calcula e justifica a reposição. A compra só acontece depois de regras e aprovação.
• A qualidade da sugestão depende mais de cadastro limpo, histórico confiável e prazo real do fornecedor do que do modelo de IA escolhido.
• As travas de valor funcionam melhor em camadas: por item, por pedido, por período e por fornecedor.
• Toda sugestão precisa deixar rastro: dados usados, regra aplicada, valor, quem aprovou e o que aconteceu depois.
• O piloto deve cobrir uma categoria de produtos, com métrica combinada antes de começar e com a opção real de parar.

O que um agente de estoque faz de fato?

Pense em quatro tarefas: consultar, calcular, explicar e encaminhar. O agente consulta saldo, vendas, pedidos em trânsito e dados do fornecedor. Calcula quanto falta para atingir a cobertura desejada. Explica em linguagem simples por que sugere aquela quantidade. E encaminha o rascunho para quem tem autoridade de aprovar.

Isso não substitui o ponto de pedido que muitos ERPs já oferecem. Um ponto de pedido fixo funciona bem para item estável e falha nas exceções: uma promoção que vai começar, um fornecedor que avisou atraso, um item que ficou parado por ruptura e parece ter demanda zero quando, na verdade, não havia o que vender. É nessas exceções que o agente agrega julgamento, porque consegue ler uma observação do comprador, um e-mail do fornecedor ou uma variação fora do padrão e sinalizar o que merece atenção.

Um princípio de desenho ajuda muito: o cálculo fica em código determinístico, e o modelo de linguagem entra para interpretar contexto, redigir a justificativa e apontar anomalias. Misturar as duas coisas, deixando o modelo fazer conta de cobertura de cabeça, é um risco desnecessário. A orientação geral da Anthropic em Building effective agents vai nessa direção: começar simples, usar fluxos previsíveis quando o caminho é conhecido e reservar a autonomia para onde ela é necessária.

Se você quer entender por que o nome superinteligência merece cautela nesse contexto, vale ler a diferença entre AGI e superinteligência. O agente de estoque não pensa sobre a empresa inteira. Ele resolve um fluxo bem delimitado.

Quais dados e regras alimentam a sugestão?

A sugestão é tão boa quanto o que entra nela. Os insumos mais comuns são:

• Histórico de vendas por item e por período, separado por canal quando fizer diferença.
• Saldo disponível, saldo reservado e pedidos de compra já em trânsito.
• Prazo de entrega real de cada fornecedor, não só o prazo combinado em contrato.
• Lote mínimo, múltiplo de compra e custo unitário.
• Validade, giro e itens substitutos, quando existirem.
• Calendário de promoções, sazonalidade conhecida e observações do comprador.

Sobre isso entram as regras de negócio, que pertencem à empresa e não ao agente: cobertura alvo em dias para cada classe de item, estoque de segurança, lista de itens que nunca devem ser repostos automaticamente, fornecedores autorizados e condições que exigem negociação humana.

O ponto mais negligenciado é a qualidade do histórico. Venda zero durante ruptura não é demanda zero. Devolução em massa distorce a média. SKUs duplicados e kits mal cadastrados fazem o agente sugerir compra de algo que já existe com outro código. Antes de qualquer piloto, vale uma revisão do cadastro da categoria escolhida.

Sobre dados pessoais: estoque costuma ter pouco dado pessoal, mas pedidos de venda podem trazer nome e contato de clientes. Para a reposição, o agente quase sempre precisa apenas de quantidades agregadas por item. Enviar só o necessário reduz risco de LGPD e também reduz ruído na análise.

Como funcionam as travas de valor?

A trava é uma regra que o agente não consegue contornar, mesmo que o modelo "queira". Ela deve viver no sistema que executa a ação, não apenas no texto das instruções. Instrução em prompt orienta, mas não garante. A OWASP, em seu guia de autorização, trabalha o princípio do menor privilégio: dar a cada ator só a permissão de que precisa. Para o agente, isso significa que ele pode criar um rascunho de pedido, mas não pode enviá-lo ao fornecedor.

Um desenho em camadas costuma funcionar bem:

• Trava por item: a quantidade sugerida não pode ultrapassar um múltiplo definido da cobertura alvo.
• Trava por pedido: acima de um valor definido pela empresa, a aprovação sobe de nível.
• Trava por período: o total acumulado na semana ou no mês tem um teto, e ao atingi-lo novas sugestões ficam em espera.
• Trava por fornecedor: só fornecedores já cadastrados e ativos, sem possibilidade de o agente criar ou alterar dados bancários e condições.
• Trava por variação: se a sugestão difere muito da média recente, o agente gera alerta para análise em vez de pedido.

Os valores de cada trava são decisão de quem responde pelo caixa e pela operação. Este artigo não sugere números, porque eles dependem de margem, giro, capital de giro e tolerância a ruptura de cada negócio. O que importa é que existam, estejam escritos e possam ser alterados com registro de quem alterou.

Um cuidado adicional: texto vindo de fora (e-mail de fornecedor, observação colada de planilha) deve ser tratado como dado, nunca como instrução. Se um e-mail disser para ignorar limites, o sistema não deve obedecer, e a trava em código garante isso.

Como deve ser a aprovação de compra?

A aprovação é o ponto em que a sugestão vira responsabilidade humana. Para que ela seja real e não um clique automático, o aprovador precisa receber um resumo que dê para decidir em poucos minutos:

• Item, quantidade sugerida e fornecedor.
• Cobertura atual em dias e cobertura depois da compra.
• Motivo da sugestão, em uma ou duas frases.
• Valor do pedido e posição frente às travas.
• Alternativas relevantes, como outro fornecedor ou quantidade menor.
• Alertas: variação atípica, histórico distorcido por ruptura, atraso conhecido.

O aprovador deve ter três saídas claras: aprovar, ajustar ou recusar com motivo. O motivo da recusa é valioso, porque alimenta a melhoria das regras. O canal pode ser o próprio ERP, o e-mail ou uma mensagem interna, desde que o registro fique guardado e a identidade de quem aprovou seja confiável.

Duas boas práticas evitam problemas comuns. A primeira é separar funções: quem aprova a compra não deve ser a mesma pessoa que cadastra fornecedor ou altera limites. A segunda é garantir que aprovar duas vezes não gere dois pedidos. Esse conceito se chama idempotência, e a documentação da Stripe sobre requisições idempotentes é um exemplo claro de como um sistema trata a repetição da mesma solicitação. Em fluxos de automação, o mesmo raciocínio vale para falhas e novas tentativas, tema do artigo sobre erros e retentativas no n8n.

Cenário ilustrativo: uma manhã de reposição

Este é um cenário ilustrativo, sem relação com empresa real. Uma distribuidora de produtos de limpeza roda o agente toda manhã sobre uma única categoria, a de itens de alto giro.

O agente identifica que um desinfetante está com cobertura abaixo da meta e que o fornecedor costuma entregar mais tarde que o prometido. Ele sugere um pedido que cobre o prazo real, com a justificativa escrita. O valor total fica dentro da trava por pedido, então o comprador responsável aprova com um ajuste de quantidade para fechar o múltiplo da embalagem.

Um segundo item mostra um pico de vendas na semana anterior. O agente verifica o histórico e percebe que um único pedido grande explica quase todo o pico. Em vez de elevar a compra, ele sinaliza a variação como atípica e pede decisão humana. O comprador confirma que foi uma venda pontual e recusa a sugestão, registrando o motivo.

Um terceiro pedido, somado aos anteriores, ultrapassaria o teto do período. A trava segura a sugestão e avisa o gestor. Nada foi comprado sem alguém decidir, e cada passo ficou registrado.

Como colocar em operação: mapear, limitar, pilotar, transferir

O método que Juan Carlo aplica em projetos de agentes segue quatro movimentos, e cabem bem aqui.

Mapear: descrever como a reposição acontece hoje, quem decide, com que planilha ou sistema, quais exceções aparecem e como a empresa mede ruptura e excesso atualmente. Esse levantamento vira o baseline para comparar depois. Sem ele, qualquer melhora é opinião.

Limitar: escolher quais dados o agente enxerga e quais ações pode executar. Para a reposição, o limite natural é leitura de dados, cálculo e criação de rascunho. Envio de pedido, alteração de fornecedor e mudança de parâmetros ficam fora.

Pilotar: rodar um fluxo real, em uma categoria, com logs e uma métrica de sucesso acordada antes. Antes de conectar ao ERP de produção, vale testar em ambiente isolado, como descrito em testes de agentes com mocks e sandbox.

Transferir: entregar a operação, a documentação e os critérios de decisão para o time da empresa, e então decidir se vale expandir, ajustar ou parar. Para visualizar onde cada peça se encaixa (dados, regras, ferramentas, registro e supervisão), a arquitetura em cinco blocos da camada de superinteligência ajuda a organizar a conversa com TI e com compras.

Uma sequência prática para o piloto:

• Escolher uma categoria com histórico razoável e fornecedores conhecidos.
• Limpar o cadastro dessa categoria: duplicidades, kits, unidades de medida.
• Escrever as regras de cobertura, segurança e itens excluídos.
• Definir as travas de valor com quem responde pelo caixa.
• Rodar o agente em modo sombra, apenas sugerindo, enquanto o comprador segue o processo habitual.
• Comparar sugestões com decisões humanas e revisar as divergências.
• Só então ligar a criação de rascunho no sistema, mantendo a aprovação.

O que monitorar depois e quando parar

O agente em operação precisa de acompanhamento, não de confiança cega. A NIST AI Risk Management Framework oferece uma referência de como organizar governança, medição e gestão de risco em sistemas de IA, e os mesmos princípios cabem num fluxo de compras.

Indicadores úteis para o acompanhamento:

• Proporção de sugestões aceitas sem ajuste e motivos dos ajustes e recusas.
• Rupturas e excessos nos itens do piloto, comparados ao baseline.
• Quantidade de vezes que cada trava foi acionada.
• Falhas de integração, dados ausentes e sugestões baseadas em histórico distorcido.
• Tempo que o comprador gasta por ciclo de reposição.
• Custo de operação do agente por ciclo.

Defina antes os critérios de parada: se as sugestões divergem sistematicamente das decisões humanas sem que isso melhore o resultado, se os dados de origem deixam de ser confiáveis ou se as travas são acionadas de forma recorrente por falha de regra, o fluxo deve pausar para revisão.

O agente acelera a análise de reposição, mas o limite de gasto e a decisão de compra continuam sendo da empresa.

Perguntas frequentes

O agente de estoque pode comprar sozinho? Tecnicamente pode, mas não é o desenho recomendado para começar. O mais seguro é limitar o agente a rascunhos e exigir aprovação humana, ampliando a autonomia só em itens de baixo risco, depois de evidência no piloto e com travas claras.

Preciso de um ERP específico para usar um agente de reposição? Não necessariamente. O requisito é ter dados acessíveis de saldo, vendas, pedidos em trânsito e fornecedores, seja por API, exportação ou banco de dados. Em muitas empresas brasileiras, o primeiro passo é organizar o que já existe no ERP ou na planilha antes de pensar em conectar qualquer agente.

O agente substitui o comprador? Não. Ele reduz o trabalho de consulta, cálculo e redação, e destaca exceções. O comprador continua responsável por negociação, relacionamento com fornecedor e decisões que dependem de contexto que não está nos dados.

Como evitar que o agente sugira compras erradas por causa de histórico ruim? Com revisão do cadastro antes do piloto, tratamento explícito de períodos de ruptura e uma trava por variação que transforme sugestões atípicas em alertas. Também ajuda registrar os motivos de cada recusa, porque eles mostram onde o histórico ou a regra precisam de correção.

Fontes

• Anthropic: Building effective agents
• OWASP: Authorization Cheat Sheet
• Stripe: Idempotent requests
• NIST: AI Risk Management Framework