Resumo da Semana — Salesforce aposta em estrutura para o Agentforce e realiza aquisições

Semana de 13 a 19 de junho de 2026. Não foi uma semana de releases incrementais. Foi uma semana de apostas estruturais — duas aquisições, uma mudança de plataforma de infraestrutura em escala global e um conjunto de artigos técnicos que deixam claro onde a Salesforce quer chegar com o Agentforce nos próximos 18 meses. Quem leu só as manchetes viu movimento. Quem leu o subtext viu uma empresa reorganizando sua arquitetura inteira em torno de agentes autônomos operando sem interface, consumindo dados em escala de quatrilhão e precisando de um marketplace novo para isso. Vou ao que importou.

Arquitetura Agent-Ready: o Flow e o Apex que você já tem são o ponto de partida

Fonte: Salesforce Blog

Esse artigo do blog da Salesforce é o mais importante da semana do ponto de vista prático. Não porque traz novidade de produto, mas porque finalmente articula, com clareza, o que "preparar a org para o Agentforce" significa na prática.

O argumento central é direto: você não precisa reescrever nada. O que você precisa é refatorar a forma como seus Autolaunched Flows e classes Apex estão estruturados para que um agente consiga invocá-los de forma confiável. Isso significa inputs bem definidos, outputs previsíveis, tratamento explícito de erros e — aqui está o ponto que a maioria vai ignorar — nenhuma dependência de contexto implícito de usuário dentro da lógica de negócio.

O problema arquitetural real que o artigo endereça é a fronteira entre o imprevisível e o determinístico. O LLM decide o que fazer; o Flow ou o Apex executa com controle. Se essa fronteira estiver mal definida — se o seu Flow assume que existe um usuário logado, se a sua classe Apex lê configurações do perfil do usuário corrente — o agente vai falhar de formas difíceis de debugar. Não vai lançar exception. Vai simplesmente produzir um resultado errado com aparência de correto.

Para quem está construindo Agentforce hoje: antes de criar qualquer Agent Action nova, passe pelos seus principais Flows de processo e pergunte se eles funcionariam sendo chamados por um sistema sem sessão de usuário. Se a resposta for não, você encontrou sua primeira dívida técnica de agent-readiness.

Headless 360: governança quando o agente opera sem tela

Fonte: Salesforce Blog

O Headless 360 é a funcionalidade que permite que agentes de IA acessem dados do Salesforce via API e MCP sem passar pela interface gráfica. A liberação em si não é surpresa — era o passo lógico depois da estratégia MCP da Salesforce. O que importa é o modelo de segurança que vem junto.

A questão que esse artigo responde — ou tenta responder — é: quando não existe usuário na sessão, quem é o sujeito das permissões? O artigo deixa claro que FLS e Sharing Rules continuam ativas no contexto do agente. O agente opera sob uma identidade configurada, e essa identidade tem seu próprio conjunto de permissões. Isso é correto. Mas a complexidade operacional aumenta: agora você precisa auditar o que o agente pode ver, não só o que o usuário pode ver.

O risco que vejo em implementações descuidadas é a tentação de dar ao agente um perfil de Sistema com acesso amplo "para não travar". Isso já acontece com integrações via usuário de API hoje, e acontecerá de forma ainda mais agressiva com agentes porque os erros de permissão são mais difíceis de rastrear em tempo de execução assíncrona. Principle of least privilege vale para agentes tanto quanto para humanos. Mais, na verdade, porque o agente executa volume maior de operações por unidade de tempo.

Salesforce compra a Fin: atendimento como aposta de US$ 3,6 bilhões

Fonte: Salesforce News & Insights

Três bilhões e seiscentos milhões de dólares. Esse é o preço que a Salesforce pagou para ter um modelo proprietário de atendimento ao cliente dentro de casa. A Fin, para quem não conhece, é a empresa por trás do Intercom AI — um agente de suporte que já opera em produção para milhares de empresas com taxas de resolução documentadas.

O movimento faz sentido estratégico claro: o Agentforce é altamente customizável, mas exige trabalho de implementação. A Fin entrega algo que funciona out-of-the-box para casos de uso de Service. Juntos, eles cobrem dois perfis de comprador diferentes — o que quer controle total sobre a experiência do agente e o que quer velocidade de go-live.

O que observo com atenção é o impacto no Service Cloud e no ecossistema de ISVs que construíram sobre ele. A Salesforce está, progressivamente, reduzindo o espaço de diferenciação de produto que ela mesma deixou para parceiros. Isso não é novidade no ecossistema — aconteceu com CPQ, com Field Service, com Inbox — mas a velocidade está aumentando. Para quem é parceiro de implementação, a Fin não é ameaça imediata. Para quem é ISV construindo produto de atendimento, é sinal de alerta.

AgentExchange: as novas regras para quem quer distribuir no ecossistema

Fonte: Concretio Blog

O post do Concretio é o mais detalhado que li essa semana sobre os requisitos práticos do AgentExchange. O ponto central: não é rebranding do AppExchange. É um marketplace com arquitetura diferente, regras de empacotamento diferentes e uma lógica de descoberta diferente.

O 2GP não é recomendado — é obrigatório. A estrutura de listagem é baseada em blocos modulares: você não lista "um produto", você lista ações, templates e agentes de forma separada e combinável. A busca é guiada por intenção do usuário, não por categoria de produto. Isso muda profundamente como um ISV precisa pensar o produto dele.

Para quem ainda está em 1GP e construindo algo que quer distribuir como Agent Action ou Template no AgentExchange, a conta é simples: a migração para 2GP deixou de ser item de backlog e virou pré-requisito de negócio. Não tem caminho alternativo.

A aquisição da m3ter e o gargalo de billing por consumo no Revenue Cloud

A Salesforce anunciou a compra da m3ter para resolver um problema específico e documentado no Revenue Cloud: faturamento baseado em uso em escala. O CPQ e o Billing nativos foram construídos para modelos de precificação mais tradicionais — por assento, por licença, por contrato fixo. O modelo de consumo, que é exatamente como a Salesforce vende o próprio Agentforce (por conversas), exige uma engine diferente.

A m3ter traz metering em tempo real, agregação de eventos de uso e suporte a tarifas complexas com degradê de volume. É exatamente o que faltava. O que observo é que essa aquisição é também uma admissão implícita de que o Revenue Cloud não estava pronto para o modelo comercial que a própria Salesforce está usando para vender sua principal aposta de produto. Resolvem a contradição comprando a solução.

Menções rápidas

Hyperforce — a migração que não é opcional: O Salesforce Security Blog publicou um guia direto sobre o que muda quando sua Org migra para Hyperforce. A parte técnica que mais impacta implementações no Brasil é resolução de domínio e regras de firewall. Se você tem integrações on-premise ou middleware legado apontando para IPs fixos do Salesforce clássico, você tem um problema futuro datado. Revise agora.

Slack AI no Amazon Bedrock: O Slack Engineering documentou a saída do SageMaker dedicado para o Bedrock. O que interessa para arquitetos não é a troca em si, mas o raciocínio: instâncias dedicadas dão previsibilidade de latência mas custo fixo alto; Bedrock dá flexibilidade mas exige gestão de fallback entre modelos. O artigo detalha os tradeoffs com honestidade incomum para blog de engenharia.

Testes autônomos com agentes de IA: O Slack Engineering testou abordagens de QA conduzidas por agentes. A conclusão prática: agentes validam se um objetivo foi alcançado; testes tradicionais validam se uma rota exata foi seguida. Os dois são complementares, não substitutos. O custo por execução de teste agêntico ainda é proibitivo para suites grandes. Vale acompanhar a curva de custo.

Motor de segmentação do Data Cloud: O Salesforce Engineering Blog detalhando o processamento de 1 quatrilhão de registros com modelos customizados é uma leitura técnica densa, mas vale para quem está projetando implementações de Data Cloud em escala. O gargalo não é volume — é complexidade de modelo de dados. Se você está deixando o modelo de dados do Data Cloud virar um reflexo caótico do seu data warehouse, você está criando problemas de segmentação que escalam rápido.

Carreira em Salesforce: Não tem fonte externa para linkar aqui porque a reflexão é minha. Semanas como essa confirmam: o ecossistema continua se reorganizando em ritmo alto. Quem vai continuar empregável daqui a três anos não é necessariamente quem tem mais certificações — é quem consegue entender o padrão de onde a plataforma está indo antes de ela chegar lá. Essa semana o padrão estava legível: agentes autônomos, billing por consumo, marketplace modular, infraestrutura pública. Se você ainda está discutindo se o Agentforce vai pegar, você já está um ciclo atrás.

O que acompanhar na próxima semana

A aquisição da Fin ainda está como "acordo definitivo assinado" — não fechou. Quando fechar, a questão prática é quando e como os modelos da Fin entram no roadmap do Service Cloud e do Agentforce. Qualquer comunicado de integração técnica ou roadmap conjunto é sinal relevante.

No Revenue Cloud, a m3ter também está em fase de integração. O que interessa para projetos em andamento é saber se as APIs de metering da m3ter serão expostas como capacidade nativa do Revenue Cloud ou se a empresa operará como entidade separada por mais algum tempo. Essa distinção muda muito o planejamento de quem está construindo para contratos de consumo hoje.

E o Hyperforce continua chegando. Se você não mapeou ainda quais das suas integrações dependem de IPs fixos ou resolução de domínio legada, essa é a tarefa da semana que vem.