Multi-agentes para SMB: o discurso é bonito, mas a arquitetura de dados é que decide
Salesforce publica case de adoção de múltiplos agentes Agentforce em pequenas empresas. Fato interessante, mas o texto esconde o trabalho pesado que faz isso funcionar
O blog da Salesforce vende a ideia de um 'time de agentes' rodando em paralelo para pequenas empresas sem time de TI. A promessa é real, mas o artigo pula a parte difícil: modelo de dados, governança e o motivo de 50% dos agentes hoje operarem em silo.
Esse post do blog da Salesforce mira o público SMB e vende uma ideia sedutora: você não precisa de um time de TI para ter uma "força de trabalho de agentes". Basta ativar o Employee Agent dentro do Starter ou Pro Suite e pronto, você tem um funcionário digital cuidando de contexto de conta e status de negociação.
Antes de qualquer crítica, vamos separar o que é fato do que é discurso comercial. É fato que a Salesforce embutiu o Agentforce dentro das Suites, sem custo adicional de setup para quem já está no Starter ou Pro. É fato que existe um dado de pesquisa interna citado no texto: organizações usam em média 12 agentes hoje, com projeção de crescimento de 67% em dois anos. E é fato, também citado na própria pesquisa da Salesforce, que 50% dos agentes hoje operam isolados, sem trocar contexto entre si. Esse último ponto é o mais importante do artigo e, ironicamente, o que recebe menos atenção no texto.
O que o artigo não conta (e todo arquiteto sabe)
A promessa de "múltiplos agentes trabalhando em paralelo, todos puxando da mesma fonte de verdade" só é verdadeira se a modelagem de dados por trás for coerente. Não é o Agentforce que resolve isso. É o seu Data Model, sua estratégia de Permission Set, sua governança de Sharing Rule e, cada vez mais, o quão bem você estruturou o Data Cloud (ou pelo menos os objetos padrão do CRM) para que um agente de Service e um agente de Sales estejam de fato olhando para o mesmo registro de cliente, com o mesmo histórico, sem duplicidade.
Já vi projeto de CPQ nascer simples e virar uma colcha de retalhos de exceção comercial em seis meses. É exatamente o mesmo risco aqui, só que multiplicado. Um agente que qualifica lead, outro que atende, um terceiro que rascunha e-mail: se cada um desses agentes foi configurado em um momento diferente, por pessoas diferentes, sem visão de arquitetura, você não tem um
O case é vendido como prova de que multi-agentes já funcionam para SMB, e sim, funcionam. O problema é o que fica de fora da narrativa. Nenhum agente conversa com outro por telepatia. Eles precisam de um modelo de dados coerente, de objetos bem definidos, de metadados que digam claramente "isso aqui é responsabilidade do agente A, aquilo é do agente B". Sem isso, o que você tem não é orquestração, é dois bots pisando na bola um do outro.
Quem já implementou Agentforce sabe que a parte visível (o prompt, o Topic, a Action) é a ponta mais fácil do trabalho. A parte que realmente decide se o projeto vai para produção ou fica travado em POC eterna é a arquitetura de dados por trás. Data Cloud entra aí não como acessório, mas como pré-requisito. Sem um dado unificado e confiável, cada agente vira uma ilha tomando decisão com informação parcial, e isso em SMB é ainda mais perigoso porque o volume de erro por cliente pesa proporcionalmente mais.
O texto da Salesforce faz o que todo material de marketing faz: mostra o resultado e pula o meio do caminho. Não tem nada de errado nisso como peça de vendas. O problema é quando arquiteto e time técnico leem aquilo e acham que a complexidade de modelagem, governança de dados e definição de fronteiras entre agentes é detalhe menor. Não é. É o projeto inteiro.
Minha leitura prática: se você está avaliando multi-agentes para um cliente SMB, comece pela pergunta que ninguém faz no case. Qual é o modelo de dados que sustenta isso? Se a resposta for vaga, o resto é cenografia bonita sobre uma base que ainda não existe.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.