A Salesforce colocou o Agentforce Operations em disponibilidade geral. A proposta muda de patamar em relação ao que se vendia até aqui: não é mais o agente que orquestra o trabalho — sugere o próximo passo, resume, redige. É o agente que executa o processo de back-office. Ele coordena etapas, valida dados, checa compliance, persegue aprovações e fecha o ciclo.
Os números divulgados são fortes: 50 a 70% de corte no tempo de ciclo em processos como auditoria e onboarding, e –80% em entrada manual de dados. E vem acompanhado da frase que tranquiliza qualquer CIO: "sem rip and replace" — sem substituir os sistemas que você já tem.
Tudo isso é verdade. E é exatamente aí que mora a confusão.
"Sem rip and replace" não significa "sem trabalho de integração". Significa que o trabalho de integração é exatamente o que sobra.
1. O que é o Agentforce Operations — e o que muda em relação a orquestrar tarefas
A distinção entre orquestrar e executar é a razão de existir do produto, e vale entendê-la com precisão.
Um agente que orquestra lê o contexto, decide o que deveria acontecer e entrega isso a um humano ou a um sistema: "este fornecedor está pendente de análise de crédito, encaminhe para o time X". O valor está na decisão. O trabalho continua sendo feito por outra pessoa.
Um agente que executa vai além: ele abre o cadastro, preenche o campo, dispara a validação, consulta a lista de sanções, monta o pedido de aprovação, aguarda a resposta e atualiza o registro. O valor está na ação. E ação exige alcance — o agente precisa escrever em sistemas.
É por isso que o Agentforce Operations não é uma feature incremental. É uma mudança de requisito de arquitetura.
2. Os números — e em que condições eles aparecem
50–70% de corte no tempo de ciclo e –80% em entrada manual são números de referência plausíveis para processos que têm três características simultâneas:
- São repetitivos e de alto volume — onboarding de fornecedor, conciliação, auditoria de conformidade, abertura de conta.
- Gastam a maior parte do tempo esperando, não decidindo. O tempo de ciclo de um onboarding raramente é consumido por análise; é consumido por gente esperando outra gente responder um e-mail.
- Têm todos os sistemas envolvidos acessíveis por API.
As duas primeiras condições são sobre o processo — e a maioria dos processos de back-office as atende. A terceira é sobre a sua arquitetura. E é a que quase nunca é verdade.
Números de fornecedor sempre pressupõem o cenário em que o produto funciona. Isso não é desonestidade: é o contrato implícito de qualquer demo. O trabalho do lado do comprador é descobrir qual pressuposto o próprio ambiente não cumpre.
3. A letra miúda do "sem rip and replace"
Repare no que a frase promete e no que ela não promete.
O que ela promete: você não vai precisar trocar o ERP, aposentar o WMS, migrar o fiscal ou substituir o sistema de contas a pagar para rodar o agente. Isso é verdade e é uma promessa relevante — troca de sistema de registro é um projeto de anos.
O que ela não promete: que o agente vai conseguir falar com esses sistemas. E aqui está o salto lógico que muita gente faz sem perceber. "Não preciso trocar meus sistemas" foi ouvido como "não preciso mexer nos meus sistemas". São coisas diferentes.
O agente precisa alcançar o sistema de alguma forma. As formas possíveis são poucas e conhecidas: uma API (REST, SOAP, OData), um evento, um arquivo, ou um robô de RPA clicando numa tela. Se a resposta para um determinado sistema é "nenhuma das anteriores", o agente não executa nada nele — ele para e espera um humano.
4. Onde os pilotos de back-office morrem: o passo que exige escrever no ERP
Faça o teste com um processo real. Pegue o onboarding de fornecedor, que é o caso de uso favorito das demos.
Um onboarding típico toca, no mínimo:
- CRM / cadastro — dados básicos do fornecedor. Tem API. ✅
- Compliance / KYC — consulta a listas restritivas, verificação de documentos. Geralmente tem API de terceiro. ✅
- Jurídico — revisão de contrato, assinatura. Às vezes API, às vezes e-mail e PDF. ⚠️
- Fiscal / tributário — validação de inscrição, regime, retenções. Frequentemente um módulo do ERP sem superfície exposta. ⚠️
- ERP — cadastro de fornecedor e condições de pagamento. Aqui é onde o agente precisa escrever. ❌
- Contas a pagar — vínculo do fornecedor ao fluxo de pagamento. Depende do passo 5. ❌
- Uma planilha que alguém mantém desde 2019 e que ninguém assume em reunião. 🤷
Observe o padrão: o agente executa lindamente os passos 1 a 3 e trava no 5 — que é justamente o passo que define se o fornecedor existe ou não para a empresa. Tudo antes dele é preparação. O gargalo real do processo, aquele que você contratou o agente para eliminar, é exatamente o que ficou de fora.
O piloto entrega um relatório dizendo que "70% das etapas foram automatizadas". E o tempo de ciclo do processo não cai — porque a etapa que restou é a que segura a fila.
O agente não falha por burrice. Falha por alcance.
5. O pré-requisito real: back-office exposto por API e eventos
A camada que precisa existir antes tem quatro propriedades não-negociáveis:
- Superfície de escrita, não só de leitura. Expor "consultar fornecedor" é fácil e inútil sozinho. O que destrava o processo é "criar fornecedor", "atualizar condição de pagamento", "lançar título". Escrita é onde mora o risco — e por isso é onde a maioria das exposições para por medo, não por dificuldade técnica.
- Idempotência. Um agente que dá timeout e repete a chamada não pode duplicar o cadastro nem o lançamento. Chave de idempotência por operação, deduplicação no consumidor, dead-letter queue para o que falhar. Isso não é refinamento de arquiteto: é o que permite dormir à noite com um agente escrevendo no ERP.
- Eventos para o que é assíncrono. Aprovação não é chamada síncrona. "Aguardando jurídico" pode levar três dias. Um processo de back-office real é uma máquina de estados dirigida por eventos (Kafka ou RabbitMQ), não uma sequência de chamadas REST que espera na linha.
- Trilha de auditoria por ação. Quando o agente cadastrar o fornecedor errado — e em algum momento ele vai —, a pergunta será "quem aprovou o quê, com base em qual dado, e quando". Se a resposta for um log de acesso, você tem um problema de compliance, não um bug.
Note que nada disso é específico do Agentforce. É a mesma camada que um agente da OpenAI, um fluxo de RPA ou um microserviço novo precisaria. Ela é independente de fornecedor — e é por isso que ela é o investimento que sobrevive à próxima troca de plataforma de IA.
6. Como a CCX ajuda: Salesforce + a camada de integração que faz o agente alcançar o ERP
A CCX opera os dois lados dessa equação, que é raro e é exatamente o que esse tipo de projeto exige.
Do lado da plataforma: implementação de Salesforce Commerce Cloud e Salesforce Data Cloud (unificação de dados, segmentação, ativação), com integrações para Marketing Cloud, Service Cloud e Sales Cloud. É o terreno onde o agente vive.
Do lado do alcance — que é onde o piloto morre — a prática de Integrações & APIs Enterprise: conectividade via REST, GraphQL e gRPC, com arquitetura event-driven em Kafka e RabbitMQ, cobrindo SAP ↔ e-commerce, Protheus ↔ e-commerce (estoque, preço, pedido, NF), CRMs, gateways de pagamento, antifraude e ERPs de médio porte como Bling e Tiny. Com expertise em OData, iDocs e RFC para as superfícies que o SAP não entrega de bandeja.
São 200+ projetos entregues, 99,9% de uptime em produção e engenheiros sêniores com média de 10+ anos — em squads com onboarding em 48h quando o cronograma não comporta esperar alocação.
Resumindo a tese: o agente é a parte fácil. A parte difícil tem 20 anos e se chama integração.
Falar com especialista Salesforce → — ou conheça a prática de Salesforce Data Cloud e as soluções de integração enterprise da CCX.
7. Perguntas frequentes
O que é o Agentforce Operations?
É a linha do Agentforce, da Salesforce, voltada a agentes que executam processos de back-office — coordenam etapas, validam dados, checam compliance e perseguem aprovações — em vez de apenas orquestrar ou sugerir. Entrou em disponibilidade geral em julho de 2026.
Os números de 50–70% e –80% são reais?
São os números divulgados pela Salesforce para processos como auditoria e onboarding. Eles pressupõem processos repetitivos, de alto volume, cujo tempo é gasto esperando — e, crucialmente, com todos os sistemas envolvidos acessíveis por API. É esse último pressuposto que costuma não se sustentar no ambiente do cliente.
"Sem rip and replace" quer dizer que não preciso mexer nos meus sistemas?
Não. Quer dizer que você não precisa substituí-los. O agente ainda precisa alcançá-los — por API, evento ou arquivo. Se um sistema do processo não tem superfície de escrita exposta, o agente para nele.
Por onde começar?
Pelo inventário de alcance: para o processo que você quer automatizar, liste cada sistema tocado e responda "isso tem API de escrita?". A lista de "não" é o seu backlog de integração — e ele é o cronograma real do projeto, não a configuração do agente.
E se meu ERP não tem API?
Quase todo ERP tem alguma superfície — OData, RFC, iDoc, banco intermediário, ou uma camada de serviço que pode ser construída na frente dele. O trabalho é expor essa superfície com contrato, idempotência e auditoria, de forma que o agente (e qualquer outro consumidor futuro) possa usá-la com segurança.