Até pouco tempo, o SAP Joule era "um assistente" — uma caixa de conversa que ajudava o usuário a navegar uma tela. O guia de integração publicado pela SAP em 4 de agosto de 2026 deixa claro que essa fase acabou. O Joule virou uma camada de agentes distribuída por módulo: uma única assinatura integrada a SuccessFactors, S/4HANA (Public e Private Edition) e Build Work Zone, com agentes-tarefa espalhados pelo financial closing cockpit, por compras, por consultas de estoque, pelo self-service de RH e por checagens de compliance.
E o Gartner colocou o cronômetro na mesa: 40% dos aplicativos enterprise terão agentes task-específicos embutidos até o fim de 2026, contra menos de 5% em 2025. A pergunta de quem planeja arquitetura deixou de ser "vou ter um assistente?" e passou a ser "vou ter um agente em cada módulo — como alimento tudo isso ao mesmo tempo?". A resposta é desconfortável: quando você multiplica agentes, você multiplica a superfície de integração. O gargalo deixa de ser um cano e vira uma malha.
O que mudou: o Joule deixou de ser um assistente e virou agente por módulo
O guia da SAP descreve um único Joule atravessando os três pilares da suíte: pessoas (SuccessFactors), core ERP (S/4HANA) e produtividade (Build Work Zone). Dentro disso, agentes-tarefa operam em domínios específicos — um agente que ajuda a fechar o mês no financial closing cockpit, um que roda consultas de compras, um que responde sobre estoque, um que resolve self-service de RH, um que faz checagens de compliance.
A diferença é qualitativa, não só quantitativa. Um assistente responde sobre a tela que você está olhando. Um agente-tarefa age sobre um domínio: ele quer ler o número certo, decidir e executar. E "agir" sobre receita, custo, estoque, pessoas e contratos exige que cada agente enxergue dados que quase nunca moram só dentro do módulo dele.
O prazo do Gartner: 40% dos apps com agente até o fim de 2026
O número do Gartner não é uma curiosidade — é um forçador de estrutura. Sair de menos de 5% para 40% dos aplicativos enterprise com agentes embutidos em um ano significa que a maioria dos módulos que a sua empresa opera vai ganhar, em breve, algum grau de autonomia embutida por padrão. Você não vai "decidir" ativar agentes um a um com calma; eles vão chegar como recurso do produto.
Isso muda o timing da conversa de arquitetura. Se o agente vem embutido, a pergunta relevante não é "quero um agente?", e sim "quando o agente do módulo X for ligado, ele vai agir sobre um número correto?". Quem trata isso reativamente vai ligar autonomia sobre uma base que não foi preparada para ela.
De um cano para uma malha: por que multiplicar agentes multiplica a integração
Aqui está a conta escondida. Quando você tinha um assistente, precisava de uma boa integração — normalmente a clássica SAP ↔ e-commerce. Quando você tem um agente por módulo, cada um querendo agir sobre um domínio diferente, a integração deixa de ser um cano ponto a ponto e vira uma malha: muitos consumidores, muitas fontes, muitos eventos cruzando ao mesmo tempo.
Um agente de compras precisa do custo real. Um agente de estoque precisa da posição real, que cruza o WMS e o e-commerce. Um agente de fechamento precisa do recebível, do imposto e do faturamento. Cada agente-tarefa só é confiável se enxerga o número certo na hora certa — e "na hora certa" implica arquitetura event-driven, não batch noturno. Cinco agentes agindo sobre cinco domínios é uma malha de dependências, não cinco integrações isoladas.
Onde mora o número certo de cada módulo (e por que quase nunca é só o S/4HANA)
O erro conceitual mais comum é assumir que "está tudo no SAP". Na prática, o número que cada agente precisa está espalhado:
O estoque real raramente vive só no S/4HANA — ele cruza o WMS e a vitrine do e-commerce, que vende em tempo real. O custo frequentemente vem de um sistema não-SAP (um TMS, uma planilha de rateio, um sistema legado de manufatura). O recebível mora no banco e nas conciliações financeiras. O imposto está na NF-e e no seu integrador fiscal. O contrato pode estar num CLM jurídico fora do ERP.
Ou seja: para o agente de cada módulo agir com confiança, ele depende de uma cadeia source-to-record que atravessa o SAP e o não-SAP. Sem essa cadeia integrada e reconciliada, o agente age sobre a fração do número que ele enxerga — e assume que é o todo.
O risco multiplicado: automatizar erro em escala, agora em cinco módulos
Multiplicar agentes sem multiplicar a fundação de integração e dado reconciliado não multiplica só a conveniência — multiplica o risco. Um agente que lê um dado desatualizado upstream e age sobre ele não trava com um erro visível; ele executa, confiante, sobre o número errado. E faz isso em escala, silenciosamente.
Com um assistente, um erro desses era pontual e óbvio. Com um agente por módulo, você tem cinco superfícies simultâneas onde um dado furado pode virar uma decisão automatizada: uma compra sobre custo errado, um fechamento sobre recebível incompleto, uma reposição sobre estoque fantasma. A autonomia sem fundação não acelera a operação — acelera a propagação do erro.
A fundação: malha source-to-record SAP ↔ não-SAP + dado reconciliado
A tese, no nível do problema, é simples: agente por módulo é consequência de uma malha de integração governada mais dado confiável — não de uma assinatura de Joule. Antes de ligar autonomia em cinco módulos, você precisa da cadeia que alimenta cada um com o número certo.
Isso significa integração source-to-record entre SAP e não-SAP usando os protocolos certos (OData, iDocs, RFC) e uma espinha event-driven (Kafka, RabbitMQ) para que o dado chegue na hora certa, não no batch da madrugada. E significa dado reconciliado: uma versão da verdade que todos os agentes, de todos os módulos, consomem — em vez de cada agente ler uma fonte diferente e chegar a um número diferente.
Como a CCX monta a malha
É exatamente esse encanamento que a CCX constrói. Com Integrações & APIs Enterprise, montamos a malha source-to-record SAP ↔ não-SAP — OData, iDocs, RFC e arquitetura event-driven com Kafka e RabbitMQ — que alimenta cada agente-módulo com o número certo na hora certa. Com Data & BI, entregamos o dado reconciliado e a versão única da verdade que os agentes de todos os módulos consomem. Com Consultoria em Tecnologia, mapeamos a arquitetura-alvo da malha antes de você ligar agentes em cinco módulos ao mesmo tempo. E com Squads dedicadas (engenheiros SAP e de integração, onboarding em 48h), montamos a base sem parar a operação.
O Joule virou uma camada de agentes por módulo — e cada agente só age certo sobre o número que enxerga. Integração e dado governado primeiro; agente em cada módulo depois.
Perguntas frequentes (People Also Ask)
O que mudou no SAP Joule em 2026? O Joule deixou de ser um assistente único e virou uma camada de agentes-tarefa por módulo, integrada a SuccessFactors, S/4HANA e Build Work Zone, com agentes em compras, estoque, fechamento financeiro, RH e compliance.
O que diz a previsão do Gartner sobre agentes enterprise? O Gartner projeta que 40% dos aplicativos enterprise terão agentes task-específicos embutidos até o fim de 2026, contra menos de 5% em 2025.
Por que agente por módulo é um problema de integração? Porque cada agente precisa do número certo do seu domínio, e esse número quase nunca mora só no S/4HANA — cruza WMS, e-commerce, banco, NF-e e sistemas não-SAP. Multiplicar agentes multiplica a superfície de integração.
Como preparar o SAP para agentes em vários módulos? Montando uma malha source-to-record SAP ↔ não-SAP (OData, iDocs, RFC, event-driven) e um dado reconciliado — uma versão da verdade — antes de ativar a autonomia em cada módulo.