A SAP deu ao Joule o que faltava para ele sair de casa: interoperabilidade. Com o Business Data Cloud (com Databricks nativamente embarcado) alimentando os agentes com dado governado e conhecimento de processo, o Joule passou a conectar nativamente ao Microsoft Copilot e a agentes de terceiros via MCP; e o roadmap 2026 adiciona agentes system-triggered, comunicação A2A (agent-to-agent) e lógica de pré/pós-processamento. Traduzindo em uma frase: o agente SAP agora conversa com o agente não-SAP.
É um avanço real — e este artigo não vem minimizá-lo. Vem cravar um recorte que muda a forma de planejar o projeto: A2A é um aperto de mão, não uma reconciliação. Fazer o Joule “cumprimentar” o agente do Copilot ou de um parceiro resolve o transporte da conversa entre agentes. Não resolve o conteúdo: o pedido que o agente não-SAP originou ainda precisa bater com o catálogo, o contrato, o fornecedor e, no Brasil, com o fiscal, dentro do SAP.
1. O que a SAP habilitou: Joule com A2A, MCP e Business Data Cloud (Databricks)
O anúncio tem três camadas que se encaixam. A primeira é o Business Data Cloud: com o Databricks embarcado, ele vira a fundação de dado governado que alimenta os agentes Joule com contexto de negócio — não só tabelas, mas o significado do processo. A segunda é a abertura via MCP: o Joule conecta nativamente ao Microsoft Copilot e a agentes de terceiros. A terceira é o roadmap A2A: agentes que se disparam por evento de sistema (system-triggered), conversam entre si (agent-to-agent) e ganham lógica de pré e pós-processamento.
Juntas, essas camadas tiram o Joule do casulo. Até então, ele era um assistente que operava dentro do universo SAP. Agora ele participa de uma malha multi-agente que cruza suítes e fornecedores. É exatamente o tipo de interoperabilidade que o mercado pediu — e que traz junto uma nova classe de responsabilidade.
Vale registrar o contexto de rollout: a SAP vem ampliando os assistentes Joule por módulo — procurement (Ariba e Fieldglass), finanças, RH — num ritmo que faz o agente SAP tocar cada vez mais o mundo não-SAP. Cada novo assistente é mais uma fronteira onde a conversa entre agentes vai esbarrar na necessidade de reconciliação. Ou seja: o problema que este artigo descreve não é pontual; ele cresce à medida que a malha de agentes se adensa.
2. O que muda: o agente SAP agora conversa com o agente não-SAP
O cenário novo é semântico e operacional ao mesmo tempo. Um agente rodando no Copilot pode iniciar um fluxo que termina no SAP; um agente de um parceiro pode negociar com o Joule via A2A; um evento no ERP pode disparar um agente que aciona um sistema não-SAP. A promessa é sedutora: processos que hoje exigem integrações ponto-a-ponto passariam a fluir por agentes que “se entendem”.
O problema é que entender-se, no vocabulário dos protocolos, significa apenas trocar mensagens no formato certo. Dois agentes podem trocar gentilezas impecáveis e, ainda assim, nenhum pedido fechar — porque o conteúdo da conversa não foi reconciliado com a verdade dos dois sistemas.
3. A2A é transporte, não conteúdo: aperto de mão ≠ reconciliação
Vale a analogia. O A2A é como dois executivos de empresas diferentes que finalmente falam a mesma língua e trocam um aperto de mão firme. Ótimo começo — mas o negócio só fecha quando os contratos batem, os preços conferem, o estoque existe e a nota é emitida. O aperto de mão é o transporte da intenção; a reconciliação é o fechamento da transação.
Na TI, isso tem nome: o A2A (e o MCP) resolvem descoberta, invocação e troca de mensagens entre agentes. Eles não garantem que o pedido originado no lado não-SAP corresponda a um SKU válido no SAP, a um contrato vigente com aquele fornecedor, a um preço aprovado e a um lançamento fiscal correto. Isso é integração de processo — e continua sendo um projeto de engenharia de dados e regras.
A distinção parece óbvia no papel, mas é onde muitos projetos tropeçam. Demonstrações de multi-agente são hipnotizantes: dois agentes negociando, resumindo, decidindo. O que a demo esconde é que, nos bastidores, alguém ainda precisa garantir que o dado por trás de cada fala esteja correto e sincronizado. Quando esse alguém não existe, o piloto encanta e a produção decepciona — não porque os agentes falharam em conversar, mas porque a conversa nunca teve lastro no processo real.
4. Onde a conversa encontra a realidade: catálogo, contrato, fornecedor, gasto
Pense num fluxo concreto de procurement multi-agente. O agente não-SAP propõe uma compra. Para que ela vire uma ordem real no SAP, quatro coisas precisam casar: o catálogo (o item existe e está ativo?), o contrato (há acordo vigente com aquele fornecedor, com aquele preço?), o fornecedor (está cadastrado, habilitado, sem bloqueio?) e o gasto (há orçamento, centro de custo, aprovação?).
Cada um desses é um ponto de reconciliação entre o mundo que originou a intenção e o mundo que executa a transação. Se qualquer um não bate, o agente do Copilot e o Joule podem ter conversado lindamente — e o pedido trava, ou pior, entra errado. A conversa entre agentes não dispensa a costura de dado; ela a torna mais urgente, porque agora a decisão é automática.
E note a assimetria de risco: no modelo antigo, um humano revisava o pedido antes de confirmar. No modelo multi-agente, a intenção pode percorrer três ou quatro agentes e virar ação sem toque humano. O ganho de velocidade é real — mas só é seguro se cada ponto de reconciliação foi resolvido antes, na camada de integração. Automatizar um fluxo não reconciliado é automatizar o erro.
5. O fator Brasil: a transação só fecha se bate com NF-e, SPED e a reforma tributária (IBS/CBS)
No Brasil, a barra sobe. Uma transação só está realmente fechada quando reconcilia com o fiscal: a NF-e emitida corretamente, o SPED alimentado, e — cada vez mais — as regras da reforma tributária (IBS/CBS) aplicadas. Um agente não-SAP que “fecha” um pedido sem que o lançamento fiscal esteja correto não fechou nada — criou um passivo.
É por isso que, no contexto brasileiro, a conversa entre agentes cross-suíte precisa aterrissar numa camada que entende o fiscal. Não basta o dado de negócio reconciliar; ele tem que reconciliar também com a obrigação fiscal. Essa é a diferença entre um piloto bonito e uma operação que sobrevive a uma auditoria.
A reforma tributária agrava o ponto. Com a transição para IBS e CBS, as regras de cálculo e apuração estão em movimento — e um agente que aprendeu a “fechar” pedidos com a regra antiga pode gerar lançamentos incorretos em massa. Quanto mais autônomo o fluxo, maior o custo de um erro fiscal sistemático. A camada de integração precisa ser o lugar onde essa lógica vive e é atualizada, para que o agente herde a regra certa sem que ninguém reescreva o agente.
6. Handoff governado: identidade, escopo e idempotência entre agentes de suítes diferentes
Quando dois agentes de fornecedores diferentes passam um trabalho de um para o outro, esse handoff precisa ser governado. Três controles são inegociáveis: identidade (qual agente, agindo em nome de quem, com que credencial?), escopo (o que ele pode e não pode fazer do outro lado?) e idempotência (se a mensagem se repete, a ação não duplica?).
Sem identidade, você não audita. Sem escopo, um agente de terceiro faz mais do que deveria dentro do SAP. Sem idempotência, um retry — comum quando agentes conversam — vira pedido duplicado, lançamento em dobro, nota repetida. Multi-agente entre suítes só cria valor quando o handoff carrega esses três atributos e o dado dos dois lados é reconciliado.
É tentador achar que o próprio protocolo cuida disso. Não cuida. A2A e MCP definem como a mensagem trafega e como um agente se apresenta — mas a política de quem pode fazer o quê dentro do seu SAP, o mapeamento de identidade entre domínios e a garantia de que uma ação só ocorre uma vez continuam sendo responsabilidade da sua camada de integração. O protocolo abre a possibilidade; a governança a torna segura.
7. A sequência que ancora: reconciliar, costurar, governar — depois soltar o A2A
A ordem importa. Primeiro, reconciliar o dado de negócio (catálogo, fornecedor, gasto) entre SAP e não-SAP. Segundo, costurar a integração técnica (OData, iDoc, RFC, event-driven) que transporta esse dado com garantia de entrega. Terceiro, governar o handoff (identidade, escopo, idempotência, fiscal). Só então soltar os agentes conversando via A2A.
Inverter a ordem — ligar o A2A antes da fundação — produz o pior dos mundos: agentes autônomos tomando ações sobre dado que não bate. A boa notícia é que a fundação não é desperdiço: ela vale para qualquer par de agentes, hoje e amanhã.
8. Como a CCX faz a integração SAP↔não-SAP que vira a conversa em transação
É exatamente essa camada — entre o protocolo e a transação — que a CCX Company constrói. O Joule agora fala A2A e MCP com o não-SAP; mas A2A é o transporte da conversa, não a reconciliação do seu processo. A CCX faz o handoff governado (identidade + escopo + idempotência) e a costura SAP↔não-SAP (OData, iDoc, RFC, event-driven + fiscal NF-e/IBS-CBS) para que a conversa entre agentes vire transação que fecha.
Por baixo, entra o dado reconciliado com Data & BI (fornecedor, gasto e fiscal batendo com o mundo não-SAP) e o mapeamento, via Consultoria em Tecnologia, de onde o A2A cruza processo e fiscal antes de soltar os agentes. A2A e MCP dão o idioma comum; a integração SAP↔não-SAP é que faz a conversa virar transação.
Dois agentes trocando gentilezas não fecham um pedido. Integrar SAP ao seu e-commerce →
9. Perguntas frequentes (People Also Ask)
O que significa o Joule falar A2A e MCP?
Significa que o agente da SAP pode invocar ferramentas e dados via MCP e conversar com outros agentes (Copilot, terceiros) via A2A — interoperabilidade entre suítes e fornecedores.
A2A resolve a integração entre SAP e não-SAP?
Não. O A2A resolve o transporte da conversa entre agentes. A integração de processo — reconciliar catálogo, contrato, fornecedor, gasto e fiscal — continua sendo um projeto de engenharia.
Por que o fiscal brasileiro importa nesse fluxo?
Porque uma transação só está fechada quando reconcilia com NF-e, SPED e as regras da reforma tributária (IBS/CBS). Sem isso, o agente cria um passivo, não um pedido.
O que é um handoff governado entre agentes?
É a passagem de trabalho de um agente para outro com identidade verificada, escopo mínimo e idempotência — para que a conversa entre suítes não gere ações duplicadas ou não-auditadas.