clique é passado

A primeira reação de muita gente foi pânico de posicionamento: 'a Salesforce está deixando o Claude rodar dentro da própria stack, isso não enfraquece o produto?'. Errado. Isso fortalece a tese que a Salesforce vem defendendo desde o CRM 360: a interface é descartável, a plataforma é o ativo.

O detalhe técnico que ninguém está discutindo o suficiente é o Headless 360. Se o Claude consegue executar uma ação de vendas respeitando sharing rules, validation rules e automações existentes sem passar pela tela do Sales Cloud, isso significa que a Salesforce transformou a própria org em uma API de confiança, não só um banco de dados com formulário bonito em cima.

Isso muda a conversa de arquitetura. Se seu Revenue Cloud, seu Flow Approval Process e suas regras de aprovação de desconto estão bem modeladas na camada de dados e processo, qualquer agente, seja Agentforce, seja Claude, seja o próximo LLM que a Salesforce trouxer pra dentro de casa, vai conseguir operar sobre isso sem quebrar nada. Se sua arquitetura depende de lógica escondida em Screen Flow ou validação só na UI, você já está exposto.

A provocação que fiz no post fica: times de Revenue que tratam CPQ e billing como 'só telas de configuração de preço' vão sentir isso primeiro. Quando o clique morre, o que sobra é o modelo de dados e a regra de negócio. Melhor eles estarem sólidos.

Juntei três sinais que pareciam desconexos e não são. A Dreamforce precisa provar em produção que o Agentforce entrega resultado, não só demo. Profissionais no campo continuam desconfiando de agente autônomo tomando decisão sem supervisão. E a própria engenharia da Salesforce, em documentação técnica, admite que gerar resposta é fácil, confiar nela é o trabalho difícil.

Minha leitura de arquiteto é que confiança em IA dentro de uma org não nasce de um anúncio de keynote. Ela se constrói em camadas: dados confiáveis primeiro (se o Data 360 está sujo, o agente vai herdar a sujeira e amplificar), depois regras de negócio explícitas e testáveis, depois guardrails de execução (o que o agente pode fazer sozinho e o que exige aprovação humana), depois observabilidade (você consegue auditar por que o agente decidiu X), e só no topo dessa pilha entra a experiência do usuário confiando no resultado.

A maioria das implementações de Agentforce que vejo no mercado está pulando direto pra última camada. Quer resultado bonito na tela sem ter resolvido dado sujo, sem guardrail de execução, sem log de decisão. Isso não é confiança, é sorte com prazo de validade curto.

Se você é arquiteto ou admin pensando em Agentforce agora, o exercício não é escolher qual skill ativar primeiro. É perguntar: minha org tem as quatro camadas de baixo prontas? Se não tem, resolve isso antes de colocar um agente conversando com cliente.

Essa thread do Reddit tocou num nervo que eu venho sentindo em consultoria há meses. Antes, o gargalo de criar automação era o tempo de escrever. Isso, sem querer, funcionava como controle de qualidade natural: enquanto você digitava o Flow, pensava na exceção, no volume, no bulkificação. A fricção era chata, mas educava.

Com Claude ou Agentforce for Flow gerando o esqueleto em segundos, essa fricção sumiu. E o que sobrou foi só a decisão de aceitar ou não o que foi gerado, sem o processo mental de construir que forçava entendimento profundo. O resultado é uma org que cresce em automação numa velocidade que a governança não acompanha.

Não é ludismo dizer isso. É reconhecer que velocidade sem processo de revisão vira dívida técnica composta. A saída não é frear a IA, é subir o nível de rigor na esteira: standard de nomenclatura obrigatório, revisão de arquitetura antes de deploy, e principalmente, o novo Flow Test Mode da Winter '27 usado como portão de qualidade, não como curiosidade opcional.

Se sua org adotou IA generativa pra automação sem mudar processo de governança, você não ganhou velocidade, só antecipou o dia em que vai precisar parar tudo pra entender o que foi construído.

Reuni os três posts da semana sobre Winter '27 numa leitura só porque juntos eles contam uma história maior que a soma das partes: o Flow deixou de ser 'automação declarativa pra quem não sabe código' e virou uma plataforma de engenharia de verdade, com testing, debugging e orchestration no nível que Apex sempre teve.

Screen Flow em ações em massa é o exemplo mais visível. Anos de gambiarra com botão customizado e Apex invocável só pra rodar uma tela em cima de registros selecionados, resolvidos com um recurso nativo que entrega a coleção de IDs pronta. Mas o que me chama mais atenção é o pacote de testing: mock outputs pra callout, debug por Record ID, coleções como input no debugger. Isso é o tipo de ferramenta que separa quem constrói Flow de produção de quem constrói Flow de demo.

O detalhe que pode passar batido é a entrada do Business Rules Engine dentro do bloco de Automation para C360, junto com Agentforce. Isso é a Salesforce amarrando definitivamente decisão de negócio, dado unificado e agente numa única esteira de execução. Se você trabalha com Revenue Cloud ou qualquer processo de decisão complexa, vale estudar essa peça com calma, ela vai aparecer em proposta de arquitetura em breve.

Minha recomendação prática pra quem administra Flow em produção: não adote tudo de uma vez. Comece pelo Test Mode nos fluxos críticos de aprovação e billing, depois migre as gambiarras de ação em massa, e só então explore orchestration e BRE com calma.