No SAP TechEd (27/10), a SAP fez dois movimentos ao mesmo tempo — e é a combinação que importa. De um lado, abriu: o Joule passou a operar com MCP e Agent2Agent (A2A), reunindo contexto, decidindo e rodando workflows multi-step com serviços de terceiros. De outro, governou: uma nova camada de orquestração faz os assistentes e agentes do cliente invocarem os Joule Agents por um gateway controlado. Nas palavras de um executivo da SAP, "open protocols need governed doors" — protocolos abertos precisam de portas governadas. E, para processos regulados que não podem alucinar, a SAP conecta gatilhos n8n de automação determinística: o agente decide quando invocar; o n8n executa o passo de forma previsível.
A sutileza que decide o seu projeto: abrir o protocolo (MCP/A2A) sem a porta governada é expor a malha — exatamente o risco de tool poisoning e toolchain pivoting que domina a conversa de segurança de agentes. A SAP cobriu essa porta para o SAP↔SAP. Mas é na fronteira com o não-SAP — marketplace, gateway de pagamento, fiscal brasileiro (NF-e), OMS, CRM, legado — que vive o risco real. E é lá que a porta governada, o gateway e o fallback determinístico são o projeto de integração.
O que a SAP anunciou no TechEd
O núcleo do anúncio é o Joule operando com protocolos abertos: MCP para conectar ferramentas e contexto, A2A para coordenar agentes entre si, rodando workflows de múltiplos passos que tocam serviços além da suíte SAP. Em volta disso, a SAP instalou uma camada de orquestração governada — um gateway pelo qual os agentes do cliente invocam os Joule Agents, em vez de falar com eles diretamente. Completam o quadro o Ontology Manager (na Business Data Cloud) e as aquisições de Reltio e Dremio, que reforçam dado multidomínio e federado para alimentar os agentes. A mensagem de arquitetura é explícita: protocolo aberto, sim — mas com porta governada na frente, e determinismo onde o processo não admite improviso.
"Protocolos abertos precisam de portas governadas" — por quê
A frase não é retórica; é uma resposta direta ao risco que o ecossistema de agentes expôs em 2026. Quando você abre MCP e A2A, o agente passa a ler descrições de ferramentas e saídas de outros agentes — e um LLM não separa, por natureza, "isto é um dado que leio" de "isto é uma ordem que cumpro". Sem uma porta que valide o que entra e o que é acionado, a abertura do protocolo vira superfície de ataque: a descrição de uma tool adulterada sequestra o agente (tool poisoning); a saída de uma ferramenta vira comando na próxima (toolchain pivoting). A "porta governada" é justamente a camada que separa a confiança de leitura da de execução e valida cada invocação antes de ela virar ação. A SAP acertou ao instalá-la — e ao avisar que ela é parte inseparável de abrir o protocolo.
A porta cobre o SAP↔SAP; a fronteira não-SAP fica com você
Aqui está o detalhe que define o escopo do seu projeto. A orquestração governada que a SAP entrega cobre o mundo dentro da SAP — Joule Agents invocados por um gateway controlado, agente a agente, dentro da suíte. Mas a operação real de um e-commerce ou de uma indústria não vive só dentro da SAP. Ela toca marketplace, gateway de pagamento, fiscal brasileiro (NF-e, SPED), OMS, CRM e sistemas legados — todos fora do perímetro governado pela SAP. É nessa fronteira SAP↔não-SAP que o agente precisa agir e, portanto, onde a porta governada precisa existir — e não vem pronta. Construí-la é engenharia de integração: um gateway que autentica e valida cada invocação entre o Joule e o seu mundo não-SAP, com escopo mínimo e rastro de cada chamada.
Onde entra o determinismo (n8n) — e por que importa
Nem tudo deve ser deixado a um agente. Processo fiscal e financeiro não pode alucinar: emissão de NF-e, conciliação de pagamento, baixa de estoque, cálculo de imposto. O padrão que a própria SAP adotou — gatilhos n8n determinísticos — é a resposta certa: o agente decide quando um passo deve acontecer, mas quem executa o passo é uma automação previsível, idempotente e auditável, não a improvisação do modelo. Na fronteira não-SAP, isso significa que o agente pode orquestrar o fluxo, mas a emissão fiscal, a conciliação e a baixa rodam por trilhos determinísticos, event-driven, que fazem a mesma coisa toda vez.
Como a CCX constrói a porta governada SAP ↔ não-SAP
Essa porta é trabalho de Integrações & APIs Enterprise e MuleSoft (API-led connectivity, Anypoint): o gateway entre o Joule/SAP e o não-SAP — marketplace, pagamento, fiscal BR/NF-e, OMS, CRM, legado — com autenticação, escopo mínimo e validação de cada invocação, sobre OData/iDocs/RFC do lado SAP e REST/GraphQL/event-driven (Kafka/RabbitMQ) do lado não-SAP. O passo que não pode alucinar roda por fallback determinístico (n8n/event-driven), idempotente. E cada invocação pela porta é observável com Observabilidade 360° — tracing distribuído (OpenTelemetry), Datadog/Grafana/Prometheus/Sentry — para você responder "qual agente invocou o quê, quando e por quê" no instante, não no post-mortem. A SAP deu o padrão; construir essa porta entre o seu ERP e o seu mundo não-SAP continua sendo o projeto.
Perguntas frequentes
O Joule integra com sistemas não-SAP?
Com MCP e A2A, o Joule pode orquestrar workflows que tocam serviços de terceiros. Mas a camada de orquestração governada que a SAP entrega cobre o SAP↔SAP; a porta para a fronteira não-SAP (marketplace, pagamento, fiscal, OMS, CRM, legado) é um projeto de integração que fica a seu cargo.
O que é orquestração governada de agentes?
É uma camada (gateway) pela qual os agentes do cliente invocam os agentes da plataforma, em vez de falar com eles diretamente. Ela separa a confiança de leitura da de execução e valida cada invocação antes de ela virar ação — a "porta governada" que protocolos abertos (MCP/A2A) exigem.
Preciso de n8n para processo fiscal?
Você precisa de determinismo onde o processo não pode alucinar — emissão de NF-e, conciliação, baixa de estoque. n8n (ou outra automação event-driven, idempotente) é um jeito de o agente decidir quando agir enquanto a execução do passo roda de forma previsível e auditável.
Protocolo aberto sem porta governada é superfície de ataque. A SAP governou o SAP↔SAP; a porta entre o Joule e o seu não-SAP (marketplace, pagamento, fiscal BR, OMS) — com fallback determinístico onde não se pode alucinar — é o projeto. A CCX constrói essa porta combinando Integrações & APIs Enterprise, MuleSoft e Observabilidade 360°. Integre o SAP ao seu e-commerce com a CCX →