Na quinta-feira, 9 de julho, a Meta liberou o Muse Spark 1.1 — um modelo multimodal desenhado especificamente para tarefas agênticas e orquestração de sub-agentes. Ele lidera os benchmarks de uso de ferramenta (JobBench, MCP Atlas) e chega ao mercado custando US$ 1,25 por milhão de tokens de input, abaixo do Opus 4.8 e do GPT-5.5.
É o terceiro modelo agêntico competitivo lançado em duas semanas. E a leitura estratégica é incômoda para quem apostou a diferenciação na escolha do LLM: capacidade de agente está virando commodity de preço.
O que não vira commodity é o dado que alimenta o agente. Este artigo explica por que a camada de dados unificada — no ecossistema Salesforce, o Data Cloud; em qualquer outro stack, o equivalente — passou a ser o ativo que efetivamente separa um agente que funciona em produção de um que alucina em demo.
1. O que mudou em julho: modelo agêntico bom ficou barato
Até meados de 2025, "colocar um agente para executar tarefas" era uma decisão cara e arriscada. Poucos modelos sustentavam cadeias longas de tool-use sem se perder, e os que sustentavam cobravam caro por isso. A escolha do modelo era, de fato, uma decisão de arquitetura.
Em julho de 2026, essa premissa caiu. Três modelos com capacidade agêntica comparável foram lançados em quinze dias, o preço de input caiu para a faixa de US$ 1–3 por milhão de tokens e os benchmarks de tool-use passaram a empatar dentro da margem de erro. Trocar de modelo hoje é, na maioria das arquiteturas bem construídas, mudar uma linha de configuração.
Quando um insumo fica abundante, barato e intercambiável, ele deixa de ser vantagem competitiva. Vira infraestrutura. É exatamente o que aconteceu com banda larga, com computação em nuvem e — agora — com capacidade de raciocínio agêntico.
A pergunta que sobra é: se o modelo não é mais o diferencial, o que é?
2. Por que trocar de LLM não melhora a resposta do seu agente
Existe um padrão que se repete em praticamente todo projeto de agente que trava antes de produção. O time coloca o agente em piloto, ele responde errado, e a hipótese imediata é "o modelo não é bom o suficiente". Troca-se de modelo. A qualidade não melhora. Troca-se de novo. Não melhora.
Na terceira troca, alguém finalmente vai olhar o que o agente recebeu como contexto — e descobre que o erro não estava no raciocínio. Estava no insumo.
O caso típico no varejo brasileiro é este: um cliente pergunta ao agente sobre o pedido dele. O agente consulta o CRM e encontra um cadastro. Consulta o ERP e encontra outro cadastro, com CPF igual e e-mail diferente. Consulta a plataforma de e-commerce e encontra um terceiro, criado como guest no checkout. Três registros, três históricos parciais, nenhuma chave que os una.
O agente então faz o que qualquer sistema faria diante de informação contraditória: escolhe uma das versões, e frequentemente escolhe a errada. Do ponto de vista do cliente, o agente "mentiu". Do ponto de vista técnico, ele apenas reproduziu com fidelidade a bagunça que recebeu.
Nenhum modelo compensa dado fragmentado. Um LLM melhor apenas erra com mais eloquência — a resposta fica mais bem escrita, mais confiante, e continua factualmente errada. É por isso que a curva de melhoria por troca de modelo satura tão rápido: o teto não é o raciocínio, é o contexto.
3. A camada que decide: dado unificado (CRM + ERP + e-commerce) em tempo real
A camada de dados unificada resolve três problemas distintos que costumam ser confundidos:
Identidade
Quem é este cliente? Não "qual registro do CRM ele é", mas: quais registros, em quais sistemas, correspondem à mesma pessoa física ou jurídica. É um problema de identity resolution — matching determinístico (CPF, CNPJ, e-mail verificado) combinado com probabilístico (nome + endereço + telefone). Sem isso, o agente não tem sujeito.
Estado
Qual é a verdade agora? O estoque que o e-commerce mostra é o estoque que o WMS tem? O status do pedido no CRM reflete o que o ERP já faturou? Uma camada de dados que sincroniza em batch noturno não serve para agente — porque o agente age em cima do que lê, e agir sobre estado defasado é como faturar duas vezes o mesmo item.
Ativação
Como esse dado chega ao agente no momento da decisão, com a granularidade certa e sem estourar a janela de contexto? Não adianta ter o perfil unificado num data lake se o agente precisa de três chamadas e oito segundos para montá-lo. Ativação é a diferença entre um dado que existe e um dado que é usado.
Os três problemas são de engenharia de dados e integração, não de inteligência artificial. E são exatamente os três que nenhum upgrade de modelo resolve.
4. Como o Data Cloud alimenta o Agentforce — e o que a orquestração multi-agente exige do dado
Não é coincidência que a Salesforce tenha ancorado o Agentforce no Data Cloud, e não no modelo. A arquitetura anunciada é explícita nesse ponto: o Data Cloud ingere dados de Sales Cloud, Service Cloud, Commerce Cloud, ERPs externos e fontes de terceiros; resolve identidade num perfil unificado (o Customer 360); e expõe esse perfil como contexto de execução para os agentes — via grounding, harmonização de schema e camadas de recuperação semântica.
O agente, na prática, é o consumidor final dessa cadeia. Ele não é o produto — ele é a interface do produto, que é o dado.
A onda de orquestração multi-agente — anunciada tanto pela Meta com o Muse Spark quanto pela Salesforce no release Summer '26 — aperta ainda mais essa exigência. Quando um único agente lê dado inconsistente, você tem uma resposta errada. Quando cinco agentes coordenados leem dado inconsistente e cada um age sobre a sua leitura, você tem cinco ações incoerentes entre si: um agente aplica desconto, o outro reserva estoque que não existe, o terceiro dispara a nota fiscal.
Multi-agente multiplica o custo do dado ruim. Não linearmente — combinatoriamente.
E vale registrar o ponto de neutralidade, porque ele importa: essa lógica não é uma peculiaridade da Salesforce. Vale igual para quem roda SAP com camada semântica própria, para quem usa VTEX Master Data como fonte de verdade de catálogo, para quem construiu um customer data platform em cima de Snowflake ou BigQuery, ou para quem simplesmente montou um perfil unificado com eventos em Kafka. O nome do produto muda. O requisito arquitetural, não.
5. O teste de maturidade: quantos sistemas seu agente precisa consultar?
Um diagnóstico rápido, que qualquer líder técnico pode aplicar na próxima reunião de arquitetura. Pegue a pergunta mais comum que seu agente recebe — algo como "cadê meu pedido?" ou "esse produto tem no tamanho M?" — e conte:
- Quantos sistemas precisam ser consultados para responder?
- Quantas dessas consultas retornam dado que pode estar defasado?
- Existe uma chave única que amarra o cliente entre todos eles?
- Se dois sistemas discordarem, existe uma regra explícita de qual vence?
- Se o agente agir com base nessa resposta, existe rastro de qual dado ele usou?
Se a resposta para a pergunta 1 for "mais de um" e a resposta para a 3 for "não", o problema do seu agente nunca foi o LLM. E nenhum modelo lançado em julho — nem o próximo, em agosto — vai mudar isso.
6. Como a CCX ajuda: unificação de dados e ativação para agentes
A CCX implementa Salesforce Data Cloud como camada de unificação, segmentação e ativação de dados (§22 do nosso portfólio) — conectando CRM, ERP e plataforma de e-commerce em um perfil único de cliente, que é o contexto sobre o qual qualquer agente passa a operar. Não é um projeto de IA: é um projeto de dados que habilita IA.
Na prática, o trabalho tem duas frentes que andam juntas. A primeira é a camada de integrações event-driven: conectividade em tempo real entre os sistemas via REST, GraphQL e arquitetura de eventos com Kafka ou RabbitMQ — incluindo integrações SAP ↔ e-commerce (OData, iDocs, RFC), Protheus ↔ e-commerce e CRMs. É o que garante que o perfil unificado reflita o estado atual, e não o de ontem à noite. A segunda é a frente de IA para Negócios: RAG, busca semântica, agentes conversacionais e automação com LLMs construídos em cima dessa base — com a arquitetura desenhada para trocar de modelo sem reescrever o sistema, justamente porque o modelo é a peça barata.
Somos agnósticos de plataforma por princípio. Se a sua camada de dados vai ser o Data Cloud, um CDP em Snowflake ou um perfil unificado construído sobre eventos, a recomendação sai do seu contexto — não do nosso catálogo de parcerias. O que não é negociável é a existência da camada.
Trocar de modelo é barato. O dado é que decide a resposta. Se o seu agente ainda precisa de três sistemas para saber quem é o cliente, comece pela base.
7. FAQ
O que é o Salesforce Data Cloud?
É a plataforma de dados da Salesforce que ingere informações de múltiplas fontes (Sales Cloud, Service Cloud, Commerce Cloud, ERPs, sistemas externos), resolve identidade para formar um perfil unificado do cliente — o Customer 360 — e ativa esse perfil em tempo real para segmentação, personalização e, mais recentemente, como contexto de execução para agentes do Agentforce.
Preciso do Data Cloud para usar o Agentforce?
Tecnicamente é possível operar um agente com fontes de dados apontadas diretamente, mas a arquitetura recomendada pela própria Salesforce usa o Data Cloud como camada de grounding. Sem uma camada de unificação — seja ela o Data Cloud ou um equivalente —, o agente consulta fontes que podem se contradizer, e a qualidade da resposta fica limitada pela pior fonte.
Se o modelo virou commodity, faz sentido investir em IA agora?
Faz — mas o investimento muda de lugar. Deixa de ser "escolher o melhor modelo" e passa a ser "construir a camada de dados e integrações que qualquer modelo vai consumir". Esse ativo não deprecia quando sai um modelo novo; ele fica mais valioso, porque o custo de trocar de modelo cai a quase zero.
O que é orquestração multi-agente e por que ela exige mais do dado?
É a arquitetura em que múltiplos agentes especializados coordenam a execução de uma tarefa complexa — um planeja, outro consulta, outro executa. Ela exige mais do dado porque cada agente age com base no que lê: dado inconsistente deixa de gerar uma resposta errada e passa a gerar ações incoerentes entre si (venda duplicada, estoque negativo, desconto indevido). O erro deixa de ser cosmético e vira transacional.
Quanto tempo leva para unificar CRM, ERP e e-commerce?
Depende do número de fontes, da qualidade dos identificadores e de quanto do dado já está exposto via API. Projetos de unificação costumam ser entregues em ondas: primeiro os casos de uso de maior valor (perfil do cliente e status de pedido), depois catálogo, estoque e histórico de atendimento. O erro comum é tentar unificar tudo de uma vez antes de entregar valor — e travar o projeto por 18 meses.