Agentforce Commerce chegou à disponibilidade geral no início de julho de 2026 com três agentes especializados: Shopper Agent, Buyer Agent e Merchant Agent. É o maior lançamento de comércio agentic que a Salesforce já fez — e o material de anúncio é generoso em número de conversão, escasso em guardrail.
Isso não é acidente de comunicação. É uma escolha de ênfase que qualquer decisor precisa reconhecer antes de ligar o agente na própria loja: o vendor mostra o que o agente ganha em velocidade e conversão, mas deixa pra o cliente decidir onde a venda precisa de um humano por perto antes de fechar.
O que o Agentforce Commerce lançou de fato
Os três agentes cobrem papéis diferentes na cadeia de venda, e entender a divisão evita tratar "Agentforce Commerce" como um produto único.
Shopper Agent conduz a conversa do comprador final do início ao fim — descoberta de produto, checkout, e serviço pós-compra — mantendo a voz da marca na loja própria do cliente. Ele checa estoque, prazo de transportadora e opção de retirada em loja dentro da mesma conversa, sem transferir o comprador entre sistemas.
Buyer Agent ataca o outro lado do comércio: procurement B2B via WhatsApp e SMS. O exemplo que a Salesforce usa é direto — um comprador manda "preciso de 40 caixas do parafuso de 16oz, igual ao pedido de março", o agente devolve imagem do produto pra confirmar o SKU, mostra o preço de contrato vigente e fecha o pedido, sem login em portal nem ligação.
Merchant Agent fica do lado da operação: o time de catálogo organiza produtos, cria regra de "boost and bury" e ajusta ordem de exibição descrevendo o que quer, em vez de navegar menu de admin.
Os números do lançamento reforçam a narrativa de urgência: durante a última temporada de fim de ano, IA influenciou 20% das vendas online globais — cerca de US$ 262 bilhões — e varejistas que já rodam shopper agent próprio cresceram vendas 59% mais rápido que quem ainda não adotou. Tráfego vindo de referência de IA converte a 8x a taxa do tráfego social. Clientes iniciais do Merchant Agent relatam redução de 88% no tempo de conclusão de tarefa de catálogo.
O que a cobertura de lançamento não menciona
Nenhuma das fontes que cobriram o anúncio — press release, imprensa especializada, análise de mercado — trouxe uma linha sobre limite de aprovação, teto de valor de transação, ou o que acontece quando o Buyer Agent confirma um SKU errado antes do comprador perceber. A ênfase é 100% capacidade e adoção, 0% risco.
Isso não significa que o risco não exista — significa que a Salesforce está vendendo a plataforma, e cabe ao cliente desenhar o controle. É o mesmo padrão que já discutimos ao mapear onde MCP quebra: o protocolo em si não é o problema, é a distância que ele cria entre a decisão automatizada e a revisão humana — e essa distância é decisão de configuração, não de produto.
É também a mesma pergunta que já fizemos sobre Agentforce em atendimento humano: o que automatizar e o que não. Lá o critério era capacidade emocional e ambiguidade do caso; aqui é reversibilidade financeira e exceção de contrato — o framework muda de eixo, mas a lógica de fundo é a mesma.
O lançamento vende autonomia. O guardrail contra erro caro ainda é trabalho do cliente, não do produto.
O Buyer Agent é o caso mais claro. Confirmar SKU por imagem reduz fricção — mas também reduz o número de pontos onde um humano intercepta um pedido errado antes de ele virar fatura. Preço de contrato exibido automaticamente é conveniência real, até o contrato ter uma exceção que o agente não foi treinado pra reconhecer.
Três variáveis que decidem se o agente pode vender sozinho
A pergunta certa não é "o agente pode vender sozinho" — é "sob quais condições". Três variáveis, na ordem em que valem a pena checar:
- Reversibilidade da transação. Uma troca de item de baixo valor é barata de desfazer. Um pedido B2B de 40 caixas com preço de contrato errado gera nota fiscal, frete e retrabalho de conciliação — reversão cara, não trivial.
- Complexidade de exceção. Quanto do processo de venda depende de negociação, desconto fora de tabela ou condição de contrato não padronizada? Catálogo com preço fixo tolera automação total. Contrato com cláusula específica por cliente não tolera.
- Ticket e frequência. Compra recorrente de baixo valor — a mesma lógica de risco que já vale na matriz de ROI de Salesforce, onde ticket médio decide se a plataforma se paga — tolera decisão automática. Compra pontual de alto valor pede aprovação antes de completar.
Nenhuma das três variáveis, isolada, decide sozinha. Um Shopper Agent vendendo item de catálogo padrão, ticket baixo, transação reversível, cumpre as três — autonomia total é decisão de baixo risco. Um Buyer Agent fechando pedido B2B com preço de contrato, ticket alto, reversão cara, falha em pelo menos duas — aí o desenho certo é aprovação automática dentro de faixa pré-definida, e escalonamento pra humano fora dela.
Onde autonomia total já faz sentido — e onde ainda é cedo
Aplicando o critério aos três agentes:
Shopper Agent em B2C de catálogo padrão já está maduro pra autonomia completa. Item com preço fixo, estoque visível, política de troca clara — as três variáveis do critério apontam pra baixo risco. É onde o ganho de conversão citado no lançamento (8x no tráfego referenciado por IA) faz mais sentido capturar rápido.
Buyer Agent em B2B com preço de contrato ainda pede desenho de aprovação — não porque o agente seja ruim, mas porque a exceção de contrato é a norma em procurement B2B, não o caso raro. Faixa de valor com aprovação automática, e qualquer coisa fora da faixa (SKU novo, desconto além do combinado, primeiro pedido de um cliente novo) indo pra revisão humana antes de completar, é o desenho que evita o erro caro sem devolver a fricção que o agente veio resolver.
Merchant Agent fica no meio: a ação em si (mudar regra de sort, ajustar boost/bury) é interna e reversível — não fecha venda, não gera fatura. O risco real aqui não é financeiro, é operacional: uma regra malfeita pode esconder produto certo ou destacar produto errado por dias antes de alguém notar. Log de mudança e rollback fácil resolvem esse risco sem exigir aprovação prévia de cada ajuste.
- Shopper Agent, catálogo padrão, ticket baixo: autonomia total, sem aprovação humana no fluxo.
- Buyer Agent, contrato B2B, exceção de preço: aprovação automática dentro de faixa definida; fora dela, humano antes de completar.
- Merchant Agent, regra de catálogo: sem aprovação prévia, mas com log de mudança e rollback rápido disponível.
Ticket baixo e SKU padrão toleram autonomia total; contrato e exceção de preço exigem humano no loop.
A adoção rápida não dispensa o desenho de controle
Os números do lançamento são reais e o incentivo pra adotar rápido também é — quem espera perde a janela de tráfego referenciado por ChatGPT, Google AI Mode e Gemini app que a Salesforce está conectando nativamente ao longo do segundo semestre de 2026. Mas adotar rápido e adotar sem desenho de controle são decisões diferentes, e o material de lançamento não separa as duas.
O trabalho que fica pro cliente — porque nenhuma cobertura do lançamento tratou disso — é decidir, agente por agente, onde a transação é reversível o bastante pra rodar sozinha e onde a exceção de contrato ainda pede um humano antes de completar. Quem pula esse desenho não descobre o erro no dia do lançamento. Descobre na primeira exceção que o agente tratou como regra.
Perguntas que sempre voltam
Antes de fechar, as três dúvidas mais comuns sobre o lançamento.
O que é o Agentforce Commerce?
Agentforce Commerce é a arquitetura de comércio agentic da Salesforce lançada em disponibilidade geral em julho de 2026, com três agentes especializados: Shopper Agent (atende o comprador final do descobrimento ao pós-venda), Buyer Agent (procurement B2B via WhatsApp e SMS) e Merchant Agent (gestão de catálogo por linguagem natural). Os três têm conexão nativa com estoque, gestão de pedidos e dado de cliente — o que os diferencia de um chatbot genérico é justamente essa integração, que permite ao agente prometer prazo de entrega, honrar preço de contrato e manter contexto sem transferir o comprador entre sistemas.
Dá pra deixar o Agentforce Commerce vender sem revisão humana?
Depende do agente e da transação, não é resposta única. Três variáveis decidem: reversibilidade da transação, complexidade de exceção (negociação, desconto, contrato fora de tabela) e ticket/frequência da compra. Shopper Agent em catálogo padrão de ticket baixo cumpre as três condições de baixo risco — autonomia total já faz sentido. Buyer Agent fechando pedido B2B com preço de contrato falha em pelo menos duas — reversão cara, exceção frequente — e por isso pede aprovação automática só dentro de uma faixa de valor pré-definida, com escalonamento pra humano fora dela.
Por que a Salesforce não fala sobre guardrails no lançamento?
Porque o material de lançamento — press release, cobertura especializada, análise de mercado — foi construído pra vender capacidade e velocidade de adoção, não pra desenhar controle de risco. Nenhuma das fontes do anúncio menciona teto de aprovação, limite de transação ou o que acontece quando o agente confirma um SKU errado antes do comprador perceber. Isso não é falha de produto: é decisão de configuração que cabe ao cliente, do mesmo jeito que qualquer sistema que automatiza decisão com efeito real no mundo — quanto mais perto a ação chega de gerar fatura ou mover estoque, mais perto precisa estar de uma revisão humana antes de completar.