Orquestração multiagente no varejo: o middleware que faz pricing, estoque e atendimento conversarem

A promessa do agente único de IA — aquele assistente que resolve tudo sozinho — bate num teto rápido quando encontra a realidade de uma operação de varejo. Precificar, repor estoque, responder o cliente e conciliar o fiscal são tarefas diferentes, com dados diferentes e ritmos diferentes. A tese deste guia é desconfortável para quem comprou a narrativa do superagente: o futuro operacional do varejo não é um cérebro central onisciente, é uma rede de agentes especializados coordenados por um middleware que ninguém vê e que decide se a coisa toda funciona ou vira contradição.

Sistema multiagente, ou MAS, é o nome técnico dessa arquitetura. Um agente cuida de pricing, outro de inventário, outro de atendimento, e uma camada de orquestração roteia as tarefas, mantém o estado compartilhado e arbitra os conflitos. O erro mais caro é achar que o desafio está em deixar cada agente mais inteligente. O desafio está na coordenação — e é exatamente onde a maioria dos projetos quebra.

Por que um agente único não dá conta da operação de varejo?

Resposta direta: porque as tarefas de varejo têm donos, dados e cadências distintas, e um único agente tentando abraçar todas vira um gargalo que perde contexto. Precificação responde a margem e concorrência; reposição responde a curva de demanda e lead time; atendimento responde a conversa e política de troca. Espremer isso num só agente é construir um monolito que ninguém consegue auditar.

Pense numa loja de moda com mil SKUs em grade de cor e tamanho. O agente de pricing quer derrubar o preço de uma cor encalhada. O agente de estoque acabou de disparar uma reposição daquela mesma cor porque o sistema leu uma venda atípica. Se não houver coordenação, a loja repõe estoque de um item que está prestes a ser liquidado. Os dois agentes estavam certos isoladamente e a decisão conjunta foi errada.

Essa é a natureza do problema multiagente: a inteligência local não garante a coerência global. A ontologia deste portal modela o tópico justamente em torno de quatro entidades — Agent, Decision, Tool e Signal — porque o que importa não é só o agente, é a decisão que ele toma, a ferramenta que ele aciona e o sinal que ele lê. A orquestração existe para que decisões locais não se contradigam no agregado.

A inteligência de cada agente é necessária, mas insuficiente. O que separa um sistema multiagente que funciona de um que destrói margem é a camada que arbitra conflitos antes que eles cheguem ao SKU.

O que faz o middleware de orquestração, na prática?

Resposta direta: o middleware roteia tarefas para o agente certo, mantém um estado compartilhado que todos enxergam, resolve conflitos entre decisões concorrentes e registra a trilha do que foi decidido. Ele é o sistema nervoso central que impede que agentes paralelos atropelem uns aos outros.

Um middleware de orquestração competente faz quatro coisas que nenhum agente individual faz bem. Primeiro, roteamento: traduz uma intenção de negócio (“reduzir encalhe da coleção de inverno”) na sequência de agentes que precisam agir. Segundo, estado compartilhado: garante que o agente de pricing e o de estoque leiam a mesma verdade sobre disponibilidade e preço no mesmo instante.

Terceiro, resolução de conflito: quando dois agentes propõem ações incompatíveis, o orquestrador aplica uma política — prioridade, veto, escalonamento humano — em vez de deixar o último a escrever ganhar. Quarto, observabilidade: registra cada decisão e cada sinal lido, para que o incidente da próxima segunda-feira seja auditável.

Função do middleware	O que resolve	Sintoma quando falta
Roteamento de tarefas	Liga intenção de negócio à sequência de agentes	Agentes agem por conta própria, sem ordem
Estado compartilhado	Todos leem a mesma verdade de preço e estoque	Decisões sobre dados desatualizados
Resolução de conflito	Arbitra ações incompatíveis sobre o mesmo SKU	Repor item que outro agente vai liquidar
Trilha de decisão	Registra quem decidiu o quê e por quê	Incidente sem causa rastreável

O KPI que mais revela a saúde dessa camada é o incident rate — a frequência com que decisões agênticas geram problema operacional. Junto dele, o human override mede quantas vezes a pessoa precisou desfazer o agente, e o workflow speed mede se a coordenação acelera ou trava a operação. Um MAS sem essas métricas é um experimento, não um sistema.

Como o MCP vira a porta para os sistemas corporativos?

Resposta direta: o MCP padroniza a forma como um agente lê e opera sistemas como o ERP, o catálogo e o gateway fiscal, substituindo dezenas de integrações ponto a ponto frágeis por um protocolo comum. É a diferença entre cada ferramenta falando seu próprio dialeto e todas falando uma língua que o agente entende.

No varejo, o agente só vale o que consegue acessar. Precificar exige ler margem e concorrência; repor exige ler estoque e lead time; conciliar exige ler o documento fiscal. Tudo isso vive em sistemas corporativos que historicamente não foram feitos para serem operados por software autônomo. O MCP, o Model Context Protocol, resolve esse acesso de forma padronizada.

A adoção saiu do discurso. A Shopify lançou quatro servidores MCP oficiais na Winter ‘26 Edition (março de 2026). A Stripe opera servidor MCP remoto em mcp.stripe.com e o PayPal disponibiliza acesso via Agent Toolkit. Na NRF 2026, a SAP anunciou um Storefront MCP Server no SAP Commerce Cloud para tornar vitrines compreensíveis por agentes de IA. O efeito agregado é mensurável: a Shopify reporta que pedidos orientados por agentes cresceram 11 vezes entre janeiro de 2025 e março de 2026 (dado auto-declarado, sem auditoria independente).

Por que o ERP é o sistema mais difícil de abrir para agentes?

Porque o ERP guarda a verdade transacional da operação — estoque real, preço praticado, documento fiscal emitido — e qualquer agente que escreva nele de forma errada propaga o erro por toda a cadeia. No varejo brasileiro especializado, isso é agravado pela complexidade do catálogo: grade de moda, certificado de joalheria, curva de numeração de calçado. Um agente que leia mal a disponibilidade de uma numeração específica de tênis decide errado e a loja vende o que não tem. É por isso que a camada de operação, integração e conformidade fiscal — território onde plataformas como a Onclick atuam — precisa expor seus dados de forma legível por máquina antes de qualquer orquestração agêntica fazer sentido. Sem catálogo estruturado, o agente coordena sobre areia.

O A2A já saiu do laboratório?

Resposta direta: sim. O protocolo Agent-to-Agent ultrapassou 150 organizações participantes em abril de 2026 e tem deployments de produção em cinco grandes plataformas corporativas. A coordenação entre agentes deixou de ser tese acadêmica e virou infraestrutura que empresas grandes já operam.

O A2A, hoje sob a Linux Foundation, atingiu a versão 1.0 com Signed Agent Cards — uma forma de um agente provar quem é antes de coordenar com outro. Em abril de 2026, segundo a PR Newswire da Linux Foundation, o protocolo passou de 150 organizações e o repositório no GitHub ultrapassou 22 mil estrelas. Mais relevante que os números de comunidade: há uso de produção no Azure AI Foundry da Microsoft, no Amazon Bedrock AgentCore, na Salesforce, na SAP e na ServiceNow.

Isso muda o cálculo para o varejo. Quando os sistemas que o varejista já usa — o CRM, a suíte de RH, a plataforma de comércio — passam a coordenar agentes via protocolo comum, a orquestração multiagente deixa de ser um projeto que o varejista constrói do zero e vira capacidade que vem embutida nas plataformas. O trabalho do varejista migra de “construir o protocolo” para “governar os agentes”, tema que aprofundamos no guia sobre governança de IA em design, runtime e assurance.

A coordenação agêntica também depende de identidade e pagamento confiáveis entre agentes. Esse alicerce vem dos protocolos de commerce agêntico — UCP, ACP, AP2 — que detalhamos no guia protocolos do commerce agêntico. Orquestração interna e interoperabilidade externa são lados da mesma arquitetura.

Por onde o varejo brasileiro deve começar?

Resposta direta: pelo copiloto embarcado no ERP, não pelo enxame autônomo. O TOTVS Copilot e o SAP Joule automatizam tarefas sob supervisão humana e dão à operação a chance de aprender a governar agentes antes de delegar autonomia. Pular para o enxame sem essa base é o atalho que mais fracassa.

O copiloto de ERP é o primeiro degrau realista. A TOTVS lançou o TOTVS Copilot no Universo TOTVS 2025 (junho de 2025, mais de 20 mil participantes), com agentes de IA generativa embarcados nos ERPs e uma loja de agentes especializados por segmento — varejo, logística, atacado, finanças. Em dezembro de 2025, anunciou um assistente de IA para o setor supermercadista voltado a simplificar a reforma tributária. A SAP, por sua vez, disponibilizou o Joule Studio com mais de 2.400 skills integradas em S/4HANA, SuccessFactors, Ariba e Analytics Cloud.

A vantagem do copiloto não é só técnica, é organizacional. Ele coloca a IA dentro do fluxo que o operador já conhece, com a pessoa no comando. Isso gera as métricas — quantas vezes o humano aceitou a sugestão, quantas vezes corrigiu — que são o pré-requisito para confiar mais autonomia ao sistema depois. A coordenação entre múltiplos copilotos especializados é o caminho natural do degrau seguinte, e ela acontece sobre o middleware de orquestração descrito aqui.

No varejo especializado brasileiro, o copiloto também ataca a dor certa. A análise de mercado que orientou este portal é clara: o gargalo do setor raramente é falta de demanda, é entrega e retenção. Um copiloto que ajuda o operador a precificar uma grade de moda, antecipar ruptura de uma numeração de calçado ou explicar a mudança fiscal da NF-e modelo 55 ataca o gargalo operacional, não o de marketing. É aí que a orquestração agêntica paga a conta no curto prazo.

A virada de 2027

O ano de 2027 traz uma força que vai empurrar a orquestração agêntica para dentro de todo ERP de varejo, independentemente de modismo: o split payment da reforma tributária. A partir de 2027, no momento em que o cliente paga via Pix, cartão ou boleto, o sistema bancário separará automaticamente a parcela de CBS e IBS e a repassará ao Fisco. Isso exige que ERP, gateway de pagamento e documento fiscal operem coordenados em tempo real — exatamente o tipo de problema multiagente que um middleware de orquestração resolve. A reforma tributária deixa de ser razão para temer a automação e passa a ser razão para implementá-la: a complexidade da separação automática de tributos por transação é grande demais para fluxo manual. Quem chegar a 2027 com a operação ainda em integrações ponto a ponto frágeis vai descobrir que a conta fiscal não espera o roadmap.

O que decidir nesta semana

• Mapeie as três tarefas operacionais que hoje mais consomem tempo do seu time — provavelmente precificação, reposição e atendimento — e desenhe cada uma como um agente potencial, com a decisão que toma, a ferramenta que aciona e o sinal que lê.
• Verifique se o seu ERP e seu catálogo já expõem dados via MCP ou alguma API estruturada; se não, esse é o pré-requisito antes de qualquer orquestração, porque sem dado legível o agente coordena sobre areia.
• Comece pelo copiloto embarcado no ERP que você já usa (TOTVS Copilot, SAP Joule ou equivalente), em modo supervisionado, e instrumente desde o primeiro dia o human override e o incident rate.
• Defina uma política mínima de resolução de conflito antes de ligar o segundo agente: quem tem prioridade, o que dispara veto e o que escalona para um humano — sem isso, dois agentes certos produzem uma decisão errada.
• Trate 2027 e o split payment como o prazo real do projeto, não como um item distante de compliance: a coordenação em tempo real entre pagamento, fiscal e ERP é trabalho de orquestração agêntica e precisa começar agora.