O discurso de vendas do agente de IA é sedutor: ele roda seu processo sozinho, de ponta a ponta, sem intervenção humana. O que raramente aparece no slide é a conta. Nos SAP Joule Agents, cada passo que o agente executa é medido e cobrado como consumo de AI Units — a moeda de IA da SAP. E como agentes rodam workflows multi-passo de forma autônoma, um processo que um humano resolveria em uma sessão pode se decompor em dezenas de ações metered. A autonomia que impressiona na demo é exatamente o que faz a fatura crescer.
Não é um argumento contra os Joule Agents — é um argumento sobre como desenhá-los. Quando o agente é bem arquitetado, o ganho é real e mensurável: a própria SAP mostra casos como o Project Billing Price Verification Agent, que promete cortar até 75% do tempo de resolução de divergências de preço e reduzir drasticamente o revenue leakage por cobrança incorreta. Quando é mal desenhado, o mesmo agente "dá voltas", consome AI Units e não resolve mais rápido. Este artigo mostra por que o custo dos Joule Agents é, no fundo, um problema de arquitetura — e o que separa o agente enxuto do agente que queima orçamento.
O que mudou: Joule Agents rodam workflows multi-passo e cada passo é metered
A SAP consolidou os Joule Agents como uma camada de consumo sobre o modelo de AI Units. Na prática, isso significa que a inteligência agêntica deixou de ser um recurso de licença fixa e passou a ser um recurso medido: quanto mais o agente age, mais unidades ele consome. Um agente não é um botão que dispara uma resposta; é um executor que planeja, chama ferramentas, consulta dados, decide o próximo passo e repete o ciclo até concluir a tarefa. Cada uma dessas iterações tem custo.
Essa é uma mudança conceitual importante para quem administra o orçamento de tecnologia. No mundo do software tradicional, o custo é previsível: você paga a licença e usa. No mundo agêntico metered, o custo é função do comportamento do agente — e o comportamento do agente depende de como ele foi desenhado e do que ele consegue enxergar. Dois agentes que entregam o mesmo resultado podem ter faturas radicalmente diferentes, dependendo de quantos passos cada um precisou para chegar lá.
A conta real: um processo humano de uma sessão vira dezenas de ações cobradas
Vale visualizar. Pense em um processo de verificação de divergência de preço em uma fatura. Um analista humano abre o pedido, compara com o contrato, identifica a diferença, checa a política de preço, aplica a correção e registra. Para ele, é uma tarefa, resolvida em uma sessão de trabalho.
Para um agente de IA, essa mesma tarefa se desdobra em uma sequência de ações: consultar o pedido, buscar o contrato, extrair o preço acordado, comparar valores, consultar a regra de precificação, validar a exceção, gerar a correção, gravar o resultado, registrar o log. Cada consulta a um sistema, cada chamada de ferramenta, cada passo de raciocínio é uma ação — e, no modelo metered, uma unidade de consumo. Um processo humano de uma sessão pode virar dez, vinte, trinta ações cobradas.
Se o agente for eficiente — se ele tiver o dado certo na mão e um fluxo bem desenhado — essas ações são poucas e diretas. Se ele for ineficiente — se precisar tentar, errar, buscar em vários lugares, reconsultar porque o dado veio incompleto — o número de passos explode. E é aí que a conta estoura sem o processo ficar mais rápido. O paralelo é direto com o que aconteceu na mensageria: é o mesmo enredo do "custo por token" do WhatsApp, agora dentro do ERP. Quando o recurso cobra por ação, eficiência vira orçamento.
O upside quando dá certo: −75% de tempo e de revenue leakage no billing
Para não pintar só o risco: o lado bom dos Joule Agents é concreto quando a arquitetura acompanha. O Project Billing Price Verification Agent é o exemplo que a SAP coloca na vitrine — a promessa é cortar cerca de 75% do tempo gasto na resolução de divergências de preço e reduzir na mesma ordem o revenue leakage, aquele vazamento de receita que acontece quando cobranças saem incorretas e ninguém pega a tempo.
Repare no que torna esse caso um sucesso: é um agente com escopo claro (verificação de preço), aterrado no dado certo (pedido, contrato, política) e integrado ao sistema de billing. Ele não precisa vagar, porque enxerga o que precisa. Resolve em poucos passos, consome pouca AI Unit por tarefa e ainda recupera receita que estava vazando. O ROI aparece justamente porque o agente foi desenhado para resolver, não para navegar.
A lição para replicar: o retorno de um Joule Agent não vem da autonomia em si. Vem da autonomia bem direcionada — escopo estreito, dado governado e integração que evita o passo desnecessário.
Por que o agente "dá voltas": dado não governado e falta de integração
Quando um Joule Agent consome mais do que deveria, quase sempre a causa é uma só: ele não enxerga o dado certo, na hora certa, no formato certo. E aí ele compensa com passos extras.
Um agente que não tem acesso direto à informação governada precisa procurá-la. Faz consultas a mais, tenta fontes diferentes, recebe dados incompletos ou desatualizados e reprocessa. Cada tentativa de compensar a falta de contexto é um passo — e um passo é AI Unit. Pior: dado ruim gera resultado ruim, o que às vezes exige que o processo recomece. O agente vira um trabalhador diligente preso numa mesa bagunçada: gasta metade do esforço só procurando o que precisava ter à mão.
A falta de integração agrava tudo. Se os sistemas que o agente precisa consultar — ERP, billing, contratos, catálogo — não expõem seus dados de forma consumível e em tempo real, o agente opera às cegas ou com atraso. Ele age sobre uma foto velha da realidade, erra, e o erro custa passos de correção. Governança de dados e integração event-driven não são "boas práticas" abstratas aqui; são o que determina, linha a linha, o tamanho da fatura de AI Units.
Como a CCX desenha Joule Agents enxutos, aterrados e integrados
É exatamente nesse ponto — entre a promessa do agente e a previsibilidade do custo — que a CCX atua. A tese é simples: agente de IA que cobra por passo premia quem desenha o fluxo mais enxuto, e desenhar fluxo enxuto é engenharia de integração e de dados.
Pelo portfólio de Integrações & APIs Enterprise, a CCX conecta os Joule Agents ao dado governado e aos sistemas certos com arquitetura event-driven (Kafka / RabbitMQ, REST, GraphQL, gRPC), incluindo integração SAP ↔ e-commerce e ERP em tempo real — de modo que o agente enxergue pedido, contrato, estoque e preço atualizados sem precisar caçar. Menos caça, menos passos, menos AI Unit queimada. E pelas Squads dedicadas com IA para negócios — engenheiros sêniores com onboarding em 48h — a CCX ajuda a desenhar os workflows de agente com escopo estreito e a governar o consumo, para que o padrão de sucesso do Price Verification Agent seja a regra, não a exceção.
Agente de IA que cobra por passo premia quem desenha o fluxo mais enxuto. A CCX arquiteta seus Joule Agents aterrados no dado governado e integrados aos sistemas certos — menos passos, menos AI Unit queimada, custo previsível. Comece por um assessment de arquitetura de agentes SAP. Integrar SAP ao seu negócio →
FAQ — Perguntas frequentes
Como os SAP Joule Agents são cobrados? Por consumo de AI Units, a moeda de IA da SAP. Os agentes executam workflows multi-passo de forma autônoma e cada passo (consulta, chamada de ferramenta, decisão) conta como ação medida. Quanto mais passos o agente precisa para concluir uma tarefa, maior o consumo.
Por que um agente de IA pode ficar caro no SAP? Porque um processo que um humano resolve em uma sessão pode se decompor em dezenas de ações para o agente. Se ele não enxerga o dado certo e não está bem integrado, "dá voltas" — faz consultas extras, reprocessa dado incompleto e recomeça — e cada volta consome AI Units sem resolver mais rápido.
Qual o exemplo de Joule Agent com ROI comprovado? O Project Billing Price Verification Agent, que a SAP apresenta com potencial de cortar cerca de 75% do tempo de resolução de divergências de preço e reduzir na mesma ordem o revenue leakage. O sucesso vem do escopo estreito, do dado governado e da integração ao billing.
Como controlar o custo de AI Units dos agentes? Desenhando o agente para resolver em menos passos: escopo bem definido, dado governado acessível em tempo real e integração event-driven com os sistemas certos. É arquitetura, não configuração — dois agentes que entregam o mesmo resultado podem ter faturas muito diferentes conforme quantos passos cada um precisa.
Isso é parecido com o custo por token do WhatsApp? Sim. É o mesmo enredo — recurso de IA cobrado por ação — agora dentro do ERP. Em ambos os casos, o ROI depende de arquitetar o fluxo para ser enxuto e integrado, em vez de deixar o agente compensar a falta de contexto com passos extras.