MCP ou A2A: qual protocolo usar em agentes de IA?

Dois protocolos próximos podem resolver problemas diferentes

Uma empresa conecta um agente comercial ao CRM, ao calendário e ao repositório de propostas. Depois, cria outro agente para validar condições, um terceiro para revisar risco e um coordenador para distribuir trabalho.

Nesse desenho aparecem duas perguntas.

A primeira é como cada agente consulta dados e executa ferramentas. A segunda é como agentes com responsabilidades próprias descobrem capacidades, recebem tarefas e devolvem resultados.

O Model Context Protocol (MCP) atende principalmente a primeira pergunta. O Agent2Agent Protocol (A2A) foi desenhado para a segunda. Eles podem participar da mesma arquitetura, mas não são substitutos automáticos.

Comparar MCP ou A2A apenas por lista de recursos leva a uma decisão ruim. A escolha começa pela fronteira operacional que precisa ser padronizada.

A diferença em uma frase

MCP padroniza a conexão de uma aplicação ou agente com recursos e ferramentas. A2A padroniza a colaboração entre agentes que expõem capacidades e trocam tarefas, mensagens, estados e artefatos.

Um exemplo ajuda.

O agente comercial usa MCP para consultar uma oportunidade no CRM.
O mesmo agente usa MCP para criar uma próxima ação por meio de uma ferramenta delimitada.
Um coordenador usa A2A para pedir a um agente jurídico uma análise de cláusulas.
O agente jurídico devolve estado, perguntas pendentes e um artefato estruturado.
A gravação final no sistema oficial continua acontecendo por uma ferramenta com permissão e confirmação próprias.

A arquitetura pode usar os dois protocolos. Também pode usar apenas um deles ou nenhum, caso uma integração direta e uma automação determinística resolvam o trabalho com menos complexidade.

O que o MCP organiza

MCP cria uma interface comum para disponibilizar contexto e capacidades a aplicações de IA.

Na prática, um servidor MCP pode publicar:

documentos e outros recursos para consulta;
ferramentas para buscar, criar ou atualizar objetos;
instruções e modelos de interação;
metadados sobre as capacidades disponíveis.

O cliente MCP fica na aplicação ou no agente que pretende usar essas capacidades. Ele descobre o que o servidor oferece, envia parâmetros e recebe o resultado.

O guia sobre MCP para empresas detalha escopo, identidade, permissão, testes e observabilidade. Para a comparação deste artigo, o ponto central é simples: MCP aproxima o agente dos sistemas e dados necessários para executar uma responsabilidade.

Exemplo: preparação de reunião

Um servidor comercial pode oferecer ferramentas estreitas:

buscar oportunidade pelo identificador;
listar compromissos recentes;
localizar a proposta vigente;
criar uma tarefa pendente para revisão.

O agente usa essas capacidades sem receber uma função genérica para editar qualquer campo do CRM. O servidor aplica validação, escopo e política antes de chegar ao sistema oficial.

MCP reduz o trabalho de criar conectores diferentes para cada aplicação. Essa reutilização exige inventário. Uma ferramenta fácil de publicar também fica fácil de multiplicar sem dono.

O que o A2A organiza

A2A cria uma forma comum para agentes apresentarem suas capacidades e colaborarem em tarefas.

Em um desenho compatível, um agente pode:

publicar uma descrição de suas capacidades;
receber uma solicitação de outro agente ou aplicação;
negociar ou solicitar informação complementar;
indicar estado de uma tarefa;
devolver mensagens e artefatos;
sustentar trabalho que não termina em uma única resposta imediata.

A documentação oficial do protocolo A2A usa conceitos próprios para descoberta, mensagens, tarefas e artefatos. A utilidade empresarial está em criar um contrato reconhecível entre responsabilidades que podem ter runtimes, fornecedores ou equipes diferentes.

Exemplo: validação de proposta

Um agente comercial prepara um pacote com proposta, cliente, versão, condição solicitada e divergências encontradas. Ele encaminha a tarefa a um agente de validação.

O agente de validação pode:

aceitar a tarefa;
informar que está processando;
pedir o contrato vigente;
devolver um artefato com itens aprovados, bloqueios e pontos para decisão humana;
encerrar a tarefa com estado explícito.

Esse fluxo pede algo além de uma chamada de ferramenta. Existe uma responsabilidade remota com ciclo de vida, interação e entrega própria.

MCP e A2A lado a lado

| Pergunta | MCP | A2A | |---|---|---| | Qual fronteira organiza? | agente com dados e ferramentas | agente com outro agente | | Qual objeto central? | recurso ou chamada de ferramenta | tarefa, mensagem, estado e artefato | | Quem expõe capacidade? | servidor MCP | agente remoto | | Melhor uso | integrar sistemas, fontes e operações delimitadas | delegar trabalho entre responsabilidades autônomas | | Exemplo | consultar CRM, buscar documento, criar tarefa | solicitar análise a outro agente e acompanhar o resultado | | Principal risco | ferramenta ampla, dado excessivo, identidade confusa | delegação circular, perda de contexto, autoridade ambígua | | Evidência necessária | chamada, política, parâmetros e confirmação no destino | trajetória da tarefa, handoffs, estados, artefatos e resultado final |

A tabela ajuda a escolher a camada. Ela não elimina decisões de segurança, dados, processo e responsabilidade.

Quando usar MCP

MCP tende a ser adequado quando várias aplicações de IA precisam acessar capacidades comuns.

Existem ferramentas reutilizáveis

Buscar cliente, consultar política, localizar documento e criar tarefa podem atender agentes diferentes. Uma interface comum reduz integrações duplicadas.

A fonte oficial precisa permanecer protegida

O servidor pode aplicar campos obrigatórios, escopo por usuário, separação entre leitura e escrita, bloqueios e mascaramento antes de tocar no sistema de origem.

A empresa quer trocar aplicações sem reconstruir toda conexão

Uma capacidade publicada por contrato pode ser consumida por clientes compatíveis, dentro das autorizações suportadas. Isso reduz acoplamento, desde que a regra de negócio não fique escondida apenas no cliente.

O trabalho ainda cabe em um agente

Ter várias fontes não obriga a criar vários agentes. Um agente de preparação comercial pode usar CRM, agenda, documentos e e-mail por meio de ferramentas bem delimitadas e continuar com um único dono.

Quando usar A2A

A2A ganha relevância quando existem agentes com responsabilidades independentes que precisam colaborar.

As fronteiras pertencem a domínios diferentes

Comercial, jurídico e financeiro podem operar agentes próprios, com contexto, permissão, dono e ritmo diferentes. A troca deve carregar somente o pacote necessário.

O trabalho possui ciclo de vida próprio

Uma análise pode aguardar documento, mudar de estado, pedir complemento e produzir mais de um artefato. Tratar tudo como uma chamada síncrona aumenta timeout, repetição e ambiguidade.

Os agentes usam plataformas distintas

Um contrato comum ajuda quando componentes foram construídos por times ou fornecedores diferentes. A interoperabilidade só tem valor quando os significados de tarefa, estado e entrega também foram definidos.

A delegação precisa ser descoberta e acompanhada

O coordenador precisa saber qual agente atende determinada responsabilidade, quais entradas exige, que formatos produz e como reporta progresso. Uma descrição vaga da capacidade transforma descoberta em adivinhação automatizada.

Quando usar os dois

Uma arquitetura multiagente pode usar A2A na comunicação entre responsabilidades e MCP no acesso de cada responsabilidade a ferramentas.

Considere um processo de compras.

Um agente de triagem recebe a solicitação.
Ele usa MCP para consultar cadastro e políticas.
O coordenador envia por A2A uma tarefa de análise a um agente de fornecedores.
Esse agente usa MCP para consultar homologações e documentos.
O artefato retorna ao coordenador por A2A.
Uma regra verifica valor e alçada.
A aprovação humana ocorre no sistema oficial.
Uma ferramenta MCP registra a decisão confirmada.

O protocolo entre agentes não deveria conceder automaticamente acesso às ferramentas do agente seguinte. Cada domínio preserva identidade, escopo e política.

A arquitetura multiagente para empresas explica quando a divisão do trabalho se justifica. Protocolos tornam a fronteira executável. Eles não justificam a fronteira por conta própria.

Quando evitar ambos

Padronização também possui custo.

Uma integração direta resolve o caso

Se existe um agente, uma API e uma operação estreita, um adaptador simples pode ser mais legível. Introduzir protocolo, catálogo e infraestrutura adicional sem perspectiva de reutilização aumenta manutenção.

A rota é determinística

Quando regras estáveis distribuem tarefas, um workflow pode encaminhar eventos sem um agente coordenador. Status, fila e retries continuam necessários, mas a decisão não exige interpretação aberta.

Os papéis ainda estão confusos

Se a empresa não sabe quem decide, qual fonte possui autoridade ou que resultado encerra o trabalho, a interoperabilidade acelera a circulação da ambiguidade.

O volume ainda não provou a divisão

Dois agentes podem parecer mais sofisticados que um fluxo único. Compare com uma versão simples antes de sustentar custo de descoberta, handoff, monitoramento e suporte.

O erro mais comum: tratar protocolo como governança

Um contrato técnico informa como componentes conversam. Governança define o que podem fazer, em nome de quem, com quais dados e sob qual responsabilidade.

Mesmo com MCP ou A2A, a empresa precisa decidir:

fonte da verdade por objeto;
identidade do usuário, processo e agente;
permissões por ferramenta e campo;
dados permitidos em cada passagem;
ações que exigem aprovação;
prazo e validade da tarefa;
tratamento de conflito e ausência de contexto;
custo e quantidade máxima de delegações;
evidência de conclusão;
contingência e interrupção;
dono humano de cada responsabilidade;
dono do fluxo completo.

O artigo sobre fonte da verdade para agentes ajuda a impedir que um agente trate a síntese recebida de outro como autoridade superior ao sistema oficial.

Contratos que precisam existir antes da integração

Contrato de capacidade

Descreve o que o servidor ou agente oferece, quais entradas exige, que limites possui e quais resultados pode produzir.

Contrato de dados

Define campos, significado, classificação, origem, versão, validade e regras para atravessar fronteiras. O contrato de dados para agentes reduz incompatibilidades silenciosas.

Contrato de autoridade

Informa quem pode solicitar, delegar, aprovar, alterar e cancelar. Um agente remoto não deve ampliar a autorização recebida apenas porque possui mais ferramentas.

Contrato de execução

Define estados, timeout, cancelamento, retentativas, idempotência, atualização de progresso e destino de erros.

Contrato de resultado

Declara schema, critérios de qualidade, evidências, artefatos, confirmação no sistema oficial e condição de encerramento.

Sem esses contratos, a compatibilidade de protocolo pode esconder incompatibilidade operacional.

Como evitar delegação descontrolada

Sistemas entre agentes precisam de limites explícitos.

profundidade máxima de delegação;
número máximo de agentes por tarefa;
orçamento de tempo e custo;
lista de capacidades autorizadas;
proibição de delegar dados acima da classificação permitida;
detecção de ciclo entre agentes;
prazo de validade do pedido;
cancelamento propagado;
regra para respostas conflitantes;
aprovação para efeitos relevantes.

Um agente A envia para B, B envia para C e C devolve para A. Sem identificador da trajetória e detecção de ciclo, a arquitetura pode consumir recursos sem avançar o trabalho.

O controle de custos por tarefa e o tracing do fluxo completo precisam incluir delegações, chamadas de ferramenta e revisões humanas. Medir apenas tokens de um componente deixa parte da economia invisível.

Testes mínimos para MCP e A2A

Testes da camada MCP

ferramenta inexistente ou removida;
parâmetro fora do schema;
identidade sem permissão;
fonte indisponível ou vencida;
ação executada com confirmação perdida;
tentativa repetida;
dado de outro cliente;
conteúdo malicioso dentro de recurso consultado.

Testes da camada A2A

agente indisponível;
capacidade anunciada e não suportada;
tarefa recusada;
pedido de informação adicional;
estado parado além do prazo;
cancelamento durante execução;
artefato incompatível;
delegação circular;
resposta conflitante entre agentes;
reinício sem duplicar consequência.

Testes do fluxo completo

a tarefa termina no sistema oficial;
a identidade permanece atribuível;
o contexto não atravessa domínios indevidos;
cancelamento chega às subtarefas;
erro parcial preserva estado;
custo e prazo respeitam limites;
uma pessoa recebe contexto suficiente quando precisa decidir;
logs permitem reconstruir a trajetória.

Os testes de contrato para ferramentas de agentes cobrem a estabilidade da interface executável. Em fluxos A2A, estenda a mesma disciplina aos estados e artefatos trocados entre responsabilidades.

Uma sequência segura de adoção

1. Desenhe a unidade de trabalho

Escolha pedido, oportunidade, chamado, documento ou outra unidade com início, estado e conclusão reconhecíveis.

2. Mapeie as fronteiras reais

Separe sistema, ferramenta, agente, domínio e pessoa. Não transforme cada etapa em agente.

3. Comece com integrações estreitas

Publique leitura e operações reversíveis. Confirme identidade, logs e fonte oficial.

4. Prove um único agente

Meça qualidade, tempo, custo e revisão antes de dividir a responsabilidade.

5. Separe um domínio que justifique autonomia

Escolha uma fronteira com permissão, contexto, equipe, SLA ou manutenção próprios.

6. Defina o handoff

Use campos, estados, evidências e critérios de encerramento explícitos.

7. Teste falhas e cancelamento

Inclua indisponibilidade, repetição, delegação circular, estado incerto e perda de confirmação.

8. Observe em escopo limitado

Execute com casos reais sob leitura, sugestão ou aprovação. Compare com a linha de base.

9. Amplie por evidência

Adicione capacidades e agentes quando a fronteira reduzir retrabalho, risco, espera ou acoplamento de forma mensurável.

Checklist de decisão

O problema está entre agente e ferramenta ou entre agentes?
Uma integração direta resolveria com menos componentes?
Um único agente já foi testado?
Cada agente possui responsabilidade e dono próprios?
As capacidades têm entradas e saídas verificáveis?
Identidade e autorização atravessam o fluxo sem ampliação?
Dados enviados entre agentes seguem classificação e finalidade?
Tarefas possuem estado, prazo e cancelamento?
Delegações têm limites de profundidade, custo e tempo?
Ferramentas confirmam o efeito no sistema oficial?
O fluxo resiste a repetição e falha parcial?
Existe tracing entre tarefa, agente, ferramenta e consequência?
A equipe consegue substituir um componente sem perder o processo?
O ganho operacional justifica a camada adicional?

Escolha o protocolo depois de escolher a fronteira

MCP é útil para organizar como aplicações e agentes acessam dados e ferramentas. A2A é útil para organizar como agentes com responsabilidades próprias trocam trabalho e acompanham tarefas.

A empresa pode combinar os dois. O desenho maduro preserva a diferença entre comunicação, autorização e resultado. Um agente descobrir outro não concede acesso. Uma ferramenta estar disponível não significa que pode ser usada em qualquer tarefa. Uma resposta recebida não prova que o efeito chegou ao sistema oficial.

Comece pelo processo, pela unidade de trabalho e pelas fontes de autoridade. Depois escolha a camada de protocolo que reduz acoplamento sem esconder responsabilidade. Interoperabilidade boa deixa a operação mais legível. Se ela apenas multiplica componentes, o diagrama ficou moderno e o problema permaneceu antigo.