Até algumas semanas atrás, a pergunta que dominava os comitês de tecnologia era simples de formular: "esse agente resolve?". Você media taxa de contenção, olhava o custo por interação, comparava com o atendimento humano e decidia. A unidade de análise era um agente, isolado, fazendo uma tarefa.
Essa pergunta acabou de ficar velha. Com a Multi-Agent Orchestration do Agentforce em disponibilidade geral desde 15 de junho de 2026, e com a Summer '26 entregando mais de 50 agentes prontos dentro de Slack, Teams e do service desk, os agentes deixaram de trabalhar sozinhos. Eles passaram a se passar o bastão.
E quando existe passagem de bastão, o erro muda de endereço. Ele sai do agente e vai morar na emenda. O ecossistema já batizou o fenômeno: the seam problem — o problema da costura.
1. O que a Multi-Agent Orchestration entrega de fato
O desenho da Salesforce é direto. Um agente orquestrador, apoiado no Atlas Reasoning Engine, avalia a demanda que chegou e a roteia para o agente especialista adequado. Ele faz isso lendo as capacidades declaradas de cada agente disponível — o que, na prática, significa que a descrição textual de cada agente virou um artefato de engenharia, não uma linha de documentação.
O ponto mais relevante para quem opera é o que atravessa a fronteira entre um agente e outro. O handoff não carrega apenas um payload de dados. Ele carrega identidade e contexto de conversa compartilhado. O usuário final enxerga uma interface só, uma conversa só; por trás, N especialistas se revezam sobre o mesmo caso.
Vêm no mesmo pacote:
- IT Service Domain Pack — mais de 50 agentes prontos para operações de TI, embarcados em Slack, Teams e no service desk. Ou seja: agentes chegam por padrão, não por projeto.
- Agentforce Self-Service — Help Agent configurável em até seis cliques, o que reduz drasticamente a barreira para alguém subir um agente sem passar pela arquitetura.
- Tableau MCP — o agente consulta o motor de analytics governado, com o Trust Layer no meio, em vez de inventar número.
Repare no vetor comum: a criação de agentes ficou barata e distribuída, enquanto a coordenação entre eles ficou crítica e centralizada. É desse descompasso que nasce o risco.
2. O "seam problem": por que a confiabilidade migrou do agente para a emenda
Um agente isolado tem uma superfície de falha compreensível: ele acerta ou erra a tarefa. Dá para testar, medir e ajustar. Um time de agentes tem uma superfície de falha combinatória — cada par de agentes que troca bastão é um ponto de junção, e cada junção pode degradar o resultado sem que nenhum dos dois agentes tenha "errado" isoladamente.
A leitura crítica que circulou no ecossistema após o GA é precisa: a confiabilidade do conjunto passou a depender de quão bem cada agente foi descrito (porque é isso que o orquestrador lê para rotear) e de quão íntegro o contexto chega do outro lado.
Traduzindo para linguagem de operação, são quatro costuras. Nenhuma delas costuma aparecer no slide de aprovação do projeto — e todas as quatro aparecem no primeiro incidente.
3. Costura 1 — Identidade: o agente B age em nome de quem?
O agente A recebe a demanda autenticado como o usuário que abriu o chamado. Ele roteia para o agente B, que precisa escrever no CRM. A pergunta que precisa ter resposta antes do go-live: o agente B escreve com a identidade do usuário original, com uma identidade de serviço própria, ou com a identidade do agente A?
As três opções são defensáveis em contextos diferentes. O que não é defensável é não saber qual delas está em vigor. As consequências práticas de não saber:
- Permissão excessiva — se o agente B roda com uma identidade de serviço ampla, ele acabou de contornar o modelo de permissão que você levou anos para desenhar. O usuário que não podia aprovar desconto acima de 15% agora consegue, via agente.
- Trilha de auditoria inútil — se todas as escritas aparecem como "Integration User", a trilha registra que algo aconteceu, mas não quem pediu.
- Compliance quebrado — em cenários com LGPD, a base legal do tratamento depende de quem está agindo e com qual finalidade. "Um agente fez" não é uma resposta que sobrevive a uma auditoria.
O teste é simples: pegue um registro alterado por uma cadeia de agentes e tente reconstruir, só olhando a trilha, quem autorizou aquilo. Se você não consegue, a costura 1 está aberta.
4. Costura 2 — Contexto: fato do sistema de registro versus resumo de conversa
Esta é a costura mais silenciosa e a mais cara. O contexto que atravessa o handoff é composto de duas naturezas muito diferentes de informação, e elas costumam chegar misturadas:
- Fato do sistema de registro — o CPF do cliente, o status do pedido, o saldo do contrato, o limite de crédito. Isso vem do ERP, do CRM, do Data Cloud. É verificável e tem versão.
- Resumo de conversa — "o cliente parece insatisfeito com o prazo", "ele mencionou que já tentou trocar antes". Isso é interpretação gerada por um modelo. Pode estar certo. Pode estar sutilmente errado. Não tem versão.
Quando o agente B recebe as duas coisas no mesmo blob de contexto, ele trata as duas com o mesmo grau de confiança. E aí um resumo impreciso vira premissa de uma ação real sobre o pedido.
O Tableau MCP aponta para o caminho certo justamente aqui: em vez de o agente alucinar um número, ele consulta o motor de analytics governado. Mas isso reforça o pré-requisito em vez de eliminá-lo — o contexto compartilhado só vale o que vale o sistema de registro por trás dele. Se o dado do cliente está fragmentado em quatro bases que não se falam, a orquestração multi-agente não corrige isso. Ela distribui a inconsistência para N agentes simultaneamente.
Como a E-Commerce Brasil resumiu esta semana ao tratar de dados no varejo: aplicar IA sobre dado fragmentado não resolve — escala a inconsistência. Com orquestração multi-agente, ela escala em paralelo.
5. Costura 3 — Estado: dois agentes no mesmo pedido
Aqui a discussão sai da IA e entra em sistemas distribuídos clássicos — que é exatamente por que ela costuma ser esquecida por quem está construindo agentes.
Cenário: o agente de atendimento recebe um pedido de cancelamento e inicia o estorno. Em paralelo, o agente de logística recebe a confirmação de que o pacote já saiu para entrega e atualiza o status para "em rota". Os dois agem sobre o mesmo pedido, em janelas de milissegundos. Quem ganha?
Sem os mecanismos abaixo, a resposta é "depende da latência da rede" — o que é outra forma de dizer que você não tem orquestração, tem corrida:
- Idempotência — a mesma operação executada duas vezes produz o mesmo resultado. Sem isso, um retry de handoff vira um estorno duplicado. Não é hipótese: é o modo de falha mais comum de qualquer integração com retry.
- Chave de correlação — um identificador único que atravessa toda a cadeia de agentes e todos os sistemas tocados. É o que permite responder "o que aconteceu neste caso, em ordem".
- Controle de concorrência — versionamento otimista ou lock explícito sobre o registro. Alguém precisa perder a corrida de forma previsível e tratada, não silenciosamente.
Um detalhe que vale registrar: idempotência e chave de correlação são baratas quando desenhadas antes, e muito caras quando retrofitadas depois de doze agentes em produção.
6. Costura 4 — Trilha: qual agente errou?
O resultado saiu errado. O cliente recebeu a informação errada, ou o registro ficou inconsistente. A pergunta do pós-incidente é objetiva: qual agente da cadeia produziu o desvio?
Responder isso exige que cada handoff seja um evento observável, com pelo menos: agente de origem, agente de destino, timestamp, identidade em vigor, chave de correlação, resumo do contexto transferido e resultado da ação. É tracing distribuído aplicado a agentes — a mesma disciplina que já se aplica a microsserviços, com o agravante de que o payload aqui inclui texto gerado por modelo, que precisa ser amostrado e guardado para ser auditável.
Sem essa trilha, o pós-incidente vira arqueologia: alguém abre quatro consoles diferentes e tenta reconstruir a sequência por aproximação de horário. Com doze agentes em produção — a média que o mercado já reporta — isso deixa de ser viável.
7. Como a CCX ajuda: contexto confiável antes da orquestração
A ordem importa. Orquestrar cinquenta agentes sobre uma base de contexto frágil não é aceleração — é amplificação de um problema que já existia. Na CCX, o trabalho começa pela camada que os agentes vão compartilhar.
No Salesforce Data Cloud, atuamos na unificação de identidade e na ativação de dado do cliente, para que "o cliente" signifique a mesma coisa para todos os agentes da cadeia — e para que o que atravessa o handoff seja fato do sistema de registro, com origem rastreável, e não resumo de conversa promovido a verdade. É a diferença entre um contexto compartilhado e um contexto meramente copiado.
Na camada de Integrações & APIs Enterprise, desenhamos a costura propriamente dita: arquitetura event-driven com Kafka ou RabbitMQ, padrão outbox para garantir que evento e escrita não divirjam, idempotência em cada operação e chave de correlação atravessando toda a cadeia — integrando Salesforce a ERP, a SAP, a Protheus e ao que mais o registro exigir, via REST, GraphQL ou gRPC. E com Observabilidade 360° (Datadog, Grafana, Prometheus, Sentry, tracing com OpenTelemetry) instrumentamos o handoff como um span de primeira classe, para que a pergunta "qual agente errou" tenha resposta em minutos, não em uma força-tarefa.
São 200+ projetos entregues e 50+ especialistas sêniores com média de 10 anos de experiência — gente que já operou integração crítica em produção antes de a palavra "agente" existir no vocabulário do comitê. É essa disciplina, e não o entusiasmo com a plataforma, que sustenta um time de agentes em produção.
Antes de orquestrar 50 agentes, organize o que eles compartilham. Falar com especialista Salesforce → — ou conheça nosso trabalho em Salesforce Data Cloud, a camada de contexto confiável que sustenta a orquestração.
8. Perguntas frequentes
O que é a Multi-Agent Orchestration do Agentforce?
É a capacidade, em disponibilidade geral desde 15 de junho de 2026, de um agente orquestrador rotear uma demanda para agentes especialistas com base nas capacidades declaradas de cada um. O handoff entre eles carrega identidade e contexto de conversa compartilhado, e não apenas um payload de dados.
O que significa "the seam problem" na prática?
Significa que, com múltiplos agentes atuando em sequência sobre o mesmo caso, a confiabilidade do resultado deixa de depender só da qualidade de cada agente e passa a depender da qualidade das junções entre eles: como a identidade é propagada, como o contexto atravessa, como o estado é controlado e como a trilha é registrada.
Preciso de Data Cloud para usar orquestração multi-agente?
Tecnicamente não, mas o problema que o Data Cloud resolve — identidade unificada e dado do cliente na origem — é exatamente o pré-requisito da costura de contexto. Sem uma fonte de verdade única, cada agente da cadeia opera sobre uma versão possivelmente diferente do mesmo cliente.
Por que idempotência importa em orquestração de agentes?
Porque handoffs falham e são repetidos. Sem idempotência, um retry transforma uma operação em duas: dois estornos, dois pedidos, duas notificações. É o modo de falha mais comum e mais caro de qualquer arquitetura distribuída com retry — e agentes multiplicam a quantidade de pontos onde isso pode ocorrer.
Como saber qual agente causou um erro em uma cadeia?
Instrumentando cada handoff como evento observável, com chave de correlação única atravessando toda a cadeia, identidade em vigor registrada e tracing distribuído (OpenTelemetry) aplicado aos agentes da mesma forma que já se aplica a microsserviços.