A automação da reposição de estoque começa com uma previsão de demanda — e, no varejo, essa previsão tem validade curta. Quando o planejador a exporta, confere contra a disponibilidade de fornecedores e percorre dezenas de milhares de SKUs, os itens de maior giro já estocaram. Durante anos, o gargalo era a própria previsão. Os modelos de fundação mudaram isso, prevendo demanda em todo o catálogo sem ajuste por item. O gargalo migrou para a distância entre uma boa previsão e o pedido efetivamente realizado.
O elo perdido entre prever e agir
Essa distância persiste porque previsão e ação vivem em sistemas diferentes: a previsão fica numa plataforma de dados governada, a disponibilidade do fornecedor vive num feed operacional separado, e a pessoa que faz o pedido não tem login em nenhum dos dois. O tutorial da AWS constrói a peça que faltava: um loop que detecta um pico de demanda, decide qual fornecedor consegue cobri-lo e faz o pedido sem supervisão — escalando para um humano apenas quando nenhuma regra se encaixa.
As quatro etapas do loop
- Prever (Forecast): o Many Model Forecasting (MMF) do Databricks serve o modelo Chronos-2 para prever a demanda de 7 dias de cada SKU.
- Detectar (Detect): um Databricks Genie Agent identifica os SKUs em pico — definido como média dos próximos 7 dias pelo menos 1,5× a média dos 14 dias anteriores, com um piso mínimo para filtrar ruído de baixo volume.
- Decidir (Decide): o Amazon Quick reconcilia cada SKU em pico contra a disponibilidade ao vivo de fornecedores no Amazon S3 Tables e escolhe o fornecedor mais barato capaz de cobri-lo.
- Agir (Act): o Amazon Quick Flows faz o pedido de compra de rotina pela Supplier Order API ou abre um ticket de revisão humana quando nenhum fornecedor único cobre o pico.
O papel central do Amazon Quick
O Amazon Quick fica no meio, sendo o único componente que toca os dois mundos: alcança a previsão por um Databricks Genie Agent via Model Context Protocol (MCP), puxa o feed de fornecedores do S3 Tables e chama a Order API por um conector OpenAPI — juntando tudo numa chave de produto compartilhada no momento da decisão, em vez de copiar tudo para um único data warehouse. O Databricks produz a inteligência; o Amazon Quick age sobre ela.
O padrão generaliza além do varejo: sempre que uma previsão em um sistema precisa ser reconciliada com dados operacionais de outro e transformada em ação, a estrutura detectar-decidir-agir se aplica. O repositório acompanha o exemplo, com instruções de Genie, lógica de fornecedor e Order API prontas para adaptar a outros domínios.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
