Arquitetura para Agentforce: Padrões de integração e como escolher o caminho certo

Construir agentes autônomos no Agentforce esbarra rapidamente em um desafio clássico de arquitetura: como conectar a inteligência nativa do Salesforce aos dados que vivem fora dele. ERPs, plataformas de terceiros e sistemas legados raramente foram desenhados pensando em agentes de IA — e escolher o padrão de integração errado logo no início do projeto não é um detalhe de bastidor. É a diferença exata entre um agente que toma decisões com fluidez e um que trava, sofre com timeouts ou abre brechas de segurança que ninguém previu.

O ecossistema Salesforce oferece caminhos estruturados para plugar o Agentforce ao mundo externo. A decisão de qual utilizar não deve ser guiada pelo que há de mais recente no mercado, mas sim por três pilares fundamentais:

• Tempo de resposta exigido pelo processo
• Confiabilidade do sistema de destino
• Volumetria de transações esperada

Esses três critérios, aplicados com honestidade, já eliminam boa parte das discussões desnecessárias sobre qual tecnologia usar.

APIs Síncronas: a fundação que ainda resolve a maioria dos casos

Para necessidades imediatas, o padrão de APIs tradicionais síncronas continua sendo a base. Utilizando Apex, External Services, Salesforce Flow e Named Credentials, o agente faz uma requisição e aguarda ativamente a resposta. É o padrão obrigatório quando o usuário pergunta "qual o status exato do meu pedido agora?" e precisa da informação dentro da mesma janela de conversa.

O External Services é o grande acelerador aqui: basta importar uma especificação OpenAPI e as ações invocáveis são geradas automaticamente, sem código manual. Elegante e direto.

O limite arquitetural deste modelo é o timeout de 120 segundos para operações síncronas. Se o sistema externo engasgar, o usuário sentirá o impacto na hora. Isso não é um bug — é uma característica do modelo que precisa ser aceita e planejada.

Orientação a Eventos: quando a volumetria escala ou o sistema externo oscila

Prender o agente em uma chamada síncrona quando o sistema de destino é instável é um risco alto demais para aceitar em produção. É aqui que a abordagem assíncrona, baseada em Platform Events ou Change Data Capture (CDC), resolve o problema de forma estrutural.

O agente publica a intenção no Salesforce Event Bus e é liberado imediatamente para continuar a interação. O sistema externo consome o evento no seu próprio tempo, sem bloquear a experiência do usuário. Esse modelo é especialmente adequado para cenários de fan-out: o fechamento de um negócio pelo agente dispara notificações simultâneas para financeiro, estoque e logística, sem que nenhum desses sistemas precise estar disponível no mesmo instante.

A conta que se paga por essa robustez é a complexidade de projetar pensando em consistência eventual de dados. Quem ignora esse detalhe na fase de design vai enfrentar problemas difíceis de depurar em produção.

MuleSoft como camada de mediação: governança quando o volume de sistemas exige

Para orquestrações de grande porte, a integração mediada por MuleSoft entrega a governança que nenhuma conexão ponto a ponto consegue oferecer. O fluxo é direto: APIs desenhadas no Anypoint Code Builder são publicadas e sincronizadas automaticamente com o API Catalog do Salesforce, gerando Named Credentials e External Services nos bastidores.

Esse é o modelo correto quando dezenas de sistemas legados precisam alimentar seus agentes e você não quer transformar a Org em um emaranhado de integrações frágeis e sem observabilidade. MuleSoft, nesse contexto, não é overhead — é o que mantém a arquitetura sustentável à medida que o número de conectores cresce.

MCP e Agent-to-Agent: o destino lógico, com cautela necessária

Os padrões emergentes nativos para IA merecem atenção, mas sem romantismo. O Model Context Protocol (MCP) não devolve apenas um JSON cru: ele retorna um contexto estruturado que a IA consegue analisar nativamente, sem precisar de camadas de transformação intermediária. O MuleSoft já possui recursos para atuar como ponte MCP, o que é uma evolução relevante para quem já opera com a plataforma.

O Agent-to-Agent (A2A) aposta em especialização: um agente delega tarefas para outro agente específico, potencialmente em outra plataforma, sem acumular responsabilidades que não lhe pertencem.

MCP e A2A são o destino lógico das integrações orientadas a IA. Mas "destino lógico" não significa "adotar agora em qualquer projeto".

A recomendação prática é cautela deliberada. Antes de adotar o protocolo mais recente, valide com rigor:

1. A estabilidade real da API de destino em carga de produção
2. Se o requisito de negócio genuinamente exige resposta em tempo real
3. Se a equipe tem maturidade para operar e depurar o modelo escolhido

A regra que não muda

A melhor arquitetura para o Agentforce continuará sendo, invariavelmente, a mais simples e previsível que conseguir atender ao requisito de forma estável — não a que acumula mais camadas, mais protocolos ou mais jargões técnicos no slide de apresentação.

Agentes que funcionam de forma confiável em produção são construídos sobre decisões arquiteturais chatas e bem fundamentadas. Guarde os experimentos com MCP e A2A para contextos onde a maturidade do time e a estabilidade do ambiente justifiquem o risco. No restante, síncrone o que precisa ser síncrono, assincrone o que pode esperar e use MuleSoft quando a governança for inegociável.