Headless 360: quando o Salesforce vira infraestrutura de agentes, não só um app
MCP Server, Data 360 exposto por API e Slackbot com MCP Client mudam o jeito de pensar arquitetura na era do Agentforce
O Salesforce está reorganizando toda a plataforma em torno de MCP: cada cloud vira uma capacidade reutilizável que qualquer agente autorizado pode descobrir e acionar. Isso muda a forma como arquitetos vão desenhar integrações, permissões e governança daqui pra frente.
Todo projeto de integração Salesforce que já passei tem o mesmo problema de fundo: alguém precisa recriar, em código ou em outra ferramenta, uma regra de negócio que já existe dentro da org. Validation rule, Flow, permission set, hierarquia de aprovação. Tudo isso já foi modelado, testado e ajustado ao longo de anos, mas na hora de expor aquilo para um sistema externo (ou agora, para um agente de IA) o caminho mais comum ainda é: cria uma API custom, documenta o contrato, torce para ninguém quebrar nada na próxima release.
O anúncio do Headless 360 ataca exatamente esse ponto, e a peça central é o Headless 360 MCP Server, agora em open beta. A diferença dele para uma API REST tradicional não é sutil: ele é metadata-aware. Isso significa que um agente conectado via MCP não recebe só um endpoint, ele enxerga relacionamentos, permissões, workflows e validation rules que já existem na org. Na prática, o agente herda o contexto de segurança e governança que você já configurou, sem precisar reescrever aquela lógica em prompt ou em código novo.
Para quem vive de arquitetura, isso muda o cálculo de esforço de um jeito relevante. Hoje, quando um cliente pede "quero que o agente de IA consiga criar uma oportunidade respeitando as mesmas regras de aprovação que já temos", a resposta normalmente envolve expor uma Apex REST class, replicar validação, e rezar para manter sincronizado. Com MCP Server exposto de forma nativa, a promessa é que essa replicação deixe de ser necessária: o agente consome a capacidade, não a API crua.
Data 360 virou superfície de ação, não só de consulta
O segundo movimento que merece atenção de quem trabalha com Data Cloud é o Data 360 MCP Server, já em disponibilidade geral, expondo cerca de 200 APIs. Até aqui, integrações headless com Data Cloud eram majoritariamente de leitura: você consultava um Calculated Insight, puxava um segmento, lia um Identity Graph. Agora a superfície vira de escrita e transformação também: um agente autorizado pode criar modelos semânticos, mapear campos, montar segmentos de audiência, ativar campanhas e até subir novos data streams via linguagem natural.
Isso é poderoso e assustador na mesma medida. Poderoso porque reduz drasticamente o tempo de setup para casos de uso de ativação. Assustador porque um agente com essas permissões, mal configurado, pode criar segmentos errados ou disparar ativações indevidas em escala. As Agent Skills anunciadas junto (mais de 100 skills reutilizáveis, com previsão de GA para Data 360 ainda em agosto) tentam mitigar isso empacotando orquestração, validação e regra de negócio em capacidades governadas, em vez de deixar tudo solto no prompt.
Slack como camada de ação, não só de notificação
O Slackbot MCP Client, agora GA, também merece nota separada. Ele conecta o Slack diretamente aos MCP servers do Salesforce e a mais de 20 aplicações parceiras (Atlassian, Box, Docusign, Notion, Zoom, entre outras). Na prática, o funcionário atualiza uma oportunidade, busca um contrato ou dispara um workflow direto da conversa, herdando as mesmas permissões e identidade já definidas na org. Isso reforça uma tendência que já víamos crescendo: Slack deixando de ser canal de aviso para virar canal de execução.
O recado de fundo para arquitetura é este: a plataforma está deixando de ser pensada como "aplicações que você acessa" para virar "capacidades que qualquer agente autorizado consome", via MCP, seja ele Agentforce, Claude, ChatGPT ou Cursor. Isso não é só uma mudança de UI, é uma mudança de contrato: quem desenha permission set, sharing rule e fluxo de aprovação agora está desenhando, indiretamente, o que um agente de IA pode e não pode fazer.
Se sua org já tem lógica de negócio bem modelada (Flow, Apex, validation rules, aprovações), o Headless 360 reduz a necessidade de recriar essa lógica toda vez que aparece um novo canal de IA. Isso muda a conversa de arquitetura: em vez de perguntar "como expomos isso via API custom", a pergunta vira "esse recurso já está exposto via MCP, e quem tem permissão para acioná-lo".
Para Data Cloud especificamente, a mudança é ainda mais concreta: sair do modo consulta para o modo ação (criar segmento, ativar campanha, montar modelo semântico) via linguagem natural aumenta o valor da plataforma, mas também aumenta a superfície de risco se a governança de permissões não acompanhar.
Este é um anúncio de produto com data futura (agosto de 2026) e menciona features em disponibilidade geral, GA prevista e open beta. Trate os prazos e o status de disponibilidade como informação da própria Salesforce, sujeita a mudança até o rollout efetivo. Vale validar em ambiente sandbox antes de qualquer decisão de arquitetura que dependa dessas capacidades.
Se você arquiteta integrações hoje, comece mapeando quais processos da sua org fazem sentido expor como capacidade reutilizável via MCP em vez de API custom: aprovação de oportunidade, criação de caso, atualização de contrato são bons candidatos. Revise permission sets e profiles pensando explicitamente em "o que um agente autorizado herda" antes de liberar qualquer MCP server em produção.
Para quem trabalha com Data Cloud, vale testar o Data 360 MCP Server em ambiente controlado assim que disponível, focando primeiro em casos de leitura e evoluindo para ativação apenas depois de validar as Agent Skills relevantes ao seu fluxo. Não pule direto para permitir criação de segmento ou ativação de campanha via agente sem revisar antes as regras de governança de dados.
O maior risco aqui não é técnico, é de governança: expor lógica de negócio de forma tão fácil para agentes pode criar uma falsa sensação de segurança, como se herdar permissões automaticamente resolvesse tudo. Vale auditar com cuidado quem pode configurar essas conexões, não só quem pode usá-las.
Outro ponto de atenção é a maturidade das features. Boa parte do anúncio combina itens já GA (Data 360 MCP Server, Slackbot MCP Client, Salesforce Multi-framework) com itens em open beta ou com GA prevista para uma data futura. Antes de prometer isso a um cliente, confirme o status real na sua versão de org e não assuma paridade de recursos entre ambientes.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.