MCP vs A2A vs AG-UI vs A2UI vs UCP vs AP2: o mapa definitivo dos protocolos de AI Agents em 2026

Se você passou os últimos meses ouvindo “MCP é o padrão de agentes”, “A2A substitui MCP”, “AG-UI é a UI do agente” e “UCP mata checkout”, você não está atrasado — está no meio de uma colisão de vocabulário. Em março de 2026 o Google publicou o Developer’s Guide to AI Agent Protocols exatamente para desfazer essa parede de siglas. A frase que importa não é qual protocolo “vence”. É qual problema cada um recusa a resolver.

Este artigo é o mapa que eu usaria com um CTO, um head de plataforma e um time de segurança na mesma sala. Não é um glossário. É uma arquitetura de camadas: o que o agente precisa falar com tools, com outros agentes, com o checkout, com o arranjo de pagamento e com a interface humana — e onde o Agent Harness (e o EmerAgents) entra como control plane, não como mais um protocolo.

Por que 2026 virou o ano dos protocolos de AI Agents

Até 2024, “agente” era um loop com function calling. Cada time inventava o próprio schema de tool, o próprio handshake entre serviços e o próprio streaming para o browser. Isso escala como integração point-to-point escala: mal. Em 2025–2026 o mercado convergiu para contratos abertos porque o custo de manter adaptadores superou o custo de padronizar.

O timing editorial é este: busca por “MCP vs A2A”, “A2A protocol”, “AI agent protocols”, “A2UI vs AG-UI” e “UCP vs AP2” cresce exatamente quando times enterprise descobrem que o piloto com um servidor MCP local não sobrevive a tenancy, auditoria, pagamento e UI. Confusão técnica + intenção de busca + guia oficial do Google = janela de topical authority.

• Long tails de comparação: MCP vs A2A, MCP vs AG-UI, A2UI vs AG-UI, UCP vs AP2.
• Long tails de definição: A2A protocol, MCP A2A architecture, AI agent protocols.
• Intenção comercial: como plugar isso em SAP, Salesforce, AWS, Azure e no harness — não só no notebook.

O mapa em uma página: seis protocolos, seis problemas

Leia a tabela abaixo como um checklist de responsabilidade. Se o seu desenho usa MCP para “falar com outro agente da empresa parceira”, você está forçando a ferramenta a ser um colega. Se usa A2A para “ler o banco”, está forçando o colega a ser uma API.

• MCP — descoberta e invocação de tools/recursos/prompts; transporte típico stdio ou HTTP; superfície = catálogo de ferramentas.
• A2A — descoberta via Agent Card em /.well-known/agent-card.json; handoff e colaboração entre agentes independentes, inclusive de vendors diferentes.
• UCP — ciclo comercial (descoberta de catálogo, checkout, pós-compra) com schemas tipados; transportes REST, MCP, A2A ou embedded no browser.
• AP2 — mandatos criptográficos de pagamento (IntentMandate, CartMandate, PaymentMandate, Receipt); extensão natural de A2A para transação.
• A2UI — payload declarativo de UI (catálogo fechado de primitivas; sem código arbitrário no cliente).
• AG-UI — barramento de eventos agente→UI (SSE padronizado: texto, tool start/end, estado).

MCP: a USB-C das tools — e o que ela não é

O Model Context Protocol resolve o problema de N×M entre hosts de agentes e servidores de ferramentas. O servidor anuncia tools, resources e prompts; o host descobre e chama. Times que mantêm o sistema (Postgres, Notion, Mailgun, o seu ERP via facade) mantêm o servidor MCP. O agente deixa de acumular wrappers frágeis.

No guia do Google, o exemplo é prosaico e correto: um kitchen manager deixa de alucinar estoque e passa a ler PostgreSQL, Notion e e-mail via MCP. A lição enterprise é a mesma: SAP, Salesforce, data warehouse e filas entram como servidores com contrato — não como “o modelo adivinha o endpoint”.

O que MCP faz bem

1. Normalizar descoberta de tools (nome, descrição, JSON Schema de input).
2. Separar o host (Claude, Cursor, o seu runtime) do servidor (o sistema de verdade).
3. Permitir que o dono do sistema versione a tool sem o agente reescrever adaptador.
4. Expor resources e prompts além de functions — contexto recuperável, não só side effects.

O que MCP não faz — e times confundem o tempo todo

• Não é protocolo de colaboração entre agentes de empresas distintas. Isso é A2A.
• Não autoriza pagamento. Isso é AP2 (e o seu PCI/arranjos).
• Não substitui IAM, Policy Engine nem audit trail. Descrição de tool não é política.
• Não garante que a descrição da tool seja confiável. Tool poisoning vive exatamente aqui — e tem artigo próprio neste cluster.

type McpToolContract = {
  serverId: string;          // allowlist de publisher
  name: string;
  descriptionHash: string;   // mudança de metadata = nova revisão
  inputSchema: object;
  risk: "observe" | "mutate" | "irreversible" | "financial";
  autonomy: "execute" | "require_approval";
};

// O modelo só vê o subset autorizado para a tarefa × tenant × identidade.
function exposeTools(ctx: AgentContext): McpToolContract[] {
  return registry
    .forTenant(ctx.tenantId)
    .filter((t) => policy.allows(ctx.agentId, t));
}

A2A: o protocolo de colaboração e handoff entre agentes independentes

Agent2Agent (A2A) é a camada que o Google posiciona para agentes que não compartilham processo, vendor nem memória. Cada agente publica um Agent Card em um well-known URL descrevendo nome, skills, endpoint e version. O cliente resolve o card e envia mensagens; a resposta é Task (com artifacts) ou Message.

A analogia útil: MCP é “chamar uma função de um sistema”. A2A é “delegar um trabalho a um especialista que você não opera”. Preço de atacado, scoring de crédito, agente de fulfillment de um parceiro, agente jurídico interno — conhecimento que nunca será uma API limpa, mas pode ser uma skill agentic com contrato.

Quando A2A é a escolha certa

• Handoff entre squads ou empresas (o agente de compras fala com o agente do fornecedor).
• Especialistas remotos cujo dado bruto não será exposto via API.
• Topologias multi-agente com ownership claro: cada agente tem card, skill e SLA.
• Coexistência com frameworks diferentes (um lado em ADK, outro em LangGraph, outro no EmerAgents).

MCP vs A2A — a comparação que o Google Search está pedindo

Não escolha “um ou outro”. Escolha a fronteira. Um agente de fábrica pode usar MCP para ler o ERP e A2A para pedir cotação a um agente de fornecedor. Colapsar os dois em MCP cria a ilusão de que o parceiro é uma tool sua — com as credenciais, o blast radius e o threat model errados.

1. Mesmo processo, mesmo tenant, tool determinística → MCP (via registry).
2. Outro runtime, outro vendor, skill negociada → A2A (via Agent Card + política de delegação).
3. Os dois no mesmo fluxo → normal. O harness orquestra; os protocolos transportam.

AG-UI vs A2UI: stream versus payload de interface

A confusão mais cara no frontend agentic é tratar AG-UI e A2UI como sinônimos. Não são. Um move eventos. O outro descreve componentes. Você pode — e em stacks maduras deve — usar os dois.

AG-UI: o fio entre o runtime e a tela

O Agent-User Interaction Protocol (AG-UI), originado no ecossistema CopilotKit e reconhecido no mapa do Google, padroniza o streaming de eventos do agente para o cliente: tokens de texto, início/fim de tool, estado da tarefa. O frontend deixa de acoplar-se ao framework (LangGraph, ADK, Crew, o seu runtime) e passa a consumir um contrato SSE. Se você já sofreu com “cada SDK emite um JSON diferente para o chat”, AG-UI é a resposta a essa dor — não à dor de gerar um formulário seguro.

A2UI: UI declarativa, catálogo fechado, sem JS arbitrário

Agent-to-User Interface (A2UI) ataca outro problema: agentes que precisam montar layout — tabelas, formulários, dashboards — sem enviar HTML/JS executável. O payload é JSON declarativo com primitivas seguras (row, column, text, input). O cliente renderiza no catálogo aprovado (web, Flutter, Lit). A segurança é o ponto: o agente não “executa UI”; ele descreve UI. Em abril de 2026 o Google descreveu A2UI como parte da A2Family, e depois mostrou padrões de A2UI sobre MCP Apps e sobre A2A.

A2UI vs AG-UI — tabela mental

• Pergunta AG-UI: como o frontend fica sabendo, em tempo real, que o agente pensou, chamou tool e terminou?
• Pergunta A2UI: como o agente pede um formulário de aprovação de pedido sem XSS e sem iframe solto?
• Juntos: AG-UI transporta o evento; um dos eventos pode carregar um documento A2UI.
• MCP Apps: superfície para UI custom embutida; A2UI cabe como payload dentro de um renderer isolado — outra combinação, não um substituto.

UCP vs AP2: comércio não é pagamento, pagamento não é catálogo

Aqui a confusão sai da engenharia e entra em produto, risco e financeiro. O Universal Commerce Protocol (UCP) padroniza a jornada comercial para agentes: descobrir merchant, montar checkout, pós-compra. Schemas tipados; transporte irrelevante (REST, MCP, A2A ou embedded). O merchant permanece merchant of record. O Agent Payments Protocol (AP2) padroniza a autorização da transação com credenciais digitais verificáveis — IntentMandate, CartMandate, PaymentMandate, PaymentReceipt.

UCP diz “como o agente faz compras interoperáveis”. AP2 diz “como o dinheiro se move com evidência de intenção”. Um agente pode descobrir e montar carrinho em UCP e só então emitir um PaymentMandate AP2. Tratar UCP como “o protocolo de pagar” é o mesmo erro de tratar um gateway de checkout como um arranjo de cartão.

Por que isso explode agora

O Google posiciona UCP como compatível com A2A, AP2 e MCP. Em setembro de 2026, Visa, Mastercard e Ant International anunciaram colaboração em um framework Know-Your-Agent (KYA) para identificar e verificar agentes que pagam — interoperando sinais de confiança sem cada rede abrir mão do próprio risco. Agentic commerce deixou de ser demo de checkout e passou a ser identidade + mandato + rede.

1. Catálogo e checkout portáveis → UCP.
2. Mandato de pagamento assinável, human-present ou human-absent → AP2.
3. Quem é o agente, quem é o operador, qual o limite → Agent Identity / KYA / o seu IAM.
4. Se o harness não tiver budget, idempotência e HITL, o protocolo só acelera o prejuízo.

Arquitetura de referência: o protocolo stack dentro do Agent Harness

Protocolos não substituem runtime. Eles são os fios. O harness é a caixa. Na prática, um fluxo enterprise da fábrica EmerSoftware parece o diagrama abaixo — e é deliberadamente chato, porque chato é auditável.

1. Request entra com identidade humana, identidade do agente e trace ID.
2. Planner produz intenção estruturada — não texto livre com “por favor chama a tool”.
3. Tool Registry resolve se a capability é MCP local, A2A remoto ou fluxo UCP/AP2.
4. Policy Engine aplica least privilege, budget e HITL antes de qualquer side effect.
5. AG-UI transmite a trajetória; A2UI monta a tela de aprovação quando o risco exige.
6. Observability + evals fecham evidência: o que foi proposto, o que foi autorizado, o que executou.

type CapabilityTransport = "mcp" | "a2a" | "ucp" | "ap2" | "internal";

type ProposedAction = {
  capability: string;
  transport: CapabilityTransport;
  args: unknown;
  risk: "observe" | "mutate" | "financial";
};

type PolicyDecision = "allow" | "deny" | "require_approval" | "modify";

function dispatch(action: ProposedAction, ctx: AgentContext): PolicyDecision {
  if (action.transport === "ap2" && action.risk === "financial") {
    return ctx.autonomy === "autonomous" ? "require_approval" : "require_approval";
  }
  return policy.evaluate(action, ctx);
}

Anti-padrões que eu recuso em revisão de arquitetura

• Um único servidor MCP com 200 tools e descrição livre — o modelo escolhe sozinho, inclusive a tool envenenada.
• A2A para o próprio microserviço do time — você queria uma API; ganhou um agente latente.
• Renderizar Markdown HTML do modelo como UI — se precisa de tela, A2UI + catálogo; se precisa de stream, AG-UI.
• Checkout via tool MCP “charge_card” sem mandato AP2, sem idempotency key, sem Merchant of Record explícito.
• Colocar a API key do provedor no system prompt e chamar isso de “integração MCP”.
• Deixar o Agent Card público sem autenticação mútua e achar que “descoberta” é segurança.

Como escolher o protocolo em 15 minutos (árvore de decisão)

1. O destino é um sistema com API/dados que você opera? → MCP atrás do Tool Registry.
2. O destino é um agente com ownership alheio e skills próprias? → A2A + delegação auditável.
3. O usuário precisa ver o raciocínio e o progresso ao vivo? → AG-UI.
4. O agente precisa montar formulário/dashboard seguro? → A2UI (catálogo fechado).
5. Há jornada de compra interoperável com merchants? → UCP.
6. Há movimento de dinheiro? → AP2 + KYA/identity + HITL. Sem exceção enterprise.
7. Em todos os casos: Policy Engine, budgets, traces. Protocolo sem harness é demo.

O que isso muda na Agentic Enterprise Software Factory

Na fábrica, protocolos são contratos de borda. O valor não está em “adotar MCP porque o mercado adotou”. Está em industrializar o perímetro: cada integração SAP/AWS/Azure vira servidor MCP governado; cada especialista de domínio vira skill A2A com card versionado; o console da operação fala AG-UI; aprovações de risco falam A2UI; comércio e pagamento, quando existirem, falam UCP/AP2 sem inventar gateway paralelo.

EmerAgents é a entidade-produto nesse grafo. A demanda de busca é “AI Agents” e “Agentic AI”. A oferta é um control plane que já assume que o LLM é probabilístico e que o fio (o protocolo) não é a política. Quem ranqueia só o glossário perde o clique seguinte. Quem amarra protocolo → harness → fábrica captura a intenção de quem vai construir de verdade.

Checklist de adoção (para colar no ADR)

• Inventário: quais capabilities são tool (MCP), quais são agente (A2A), quais são UI, quais são dinheiro.
• Allowlist de servidores MCP e de Agent Cards; hash de metadata; re-aprovação em mudança.
• Nenhuma tool financeira sem transporte AP2 (ou equivalente do arranjo) + HITL.
• Frontend consome AG-UI; telas generativas só via A2UI no catálogo aprovado.
• Trace ID atravessa MCP, A2A, UCP e o browser.
• Evals de trajetória incluem “escolheu o transporte certo”, não só “respondeu bonito”.

Conclusão

O mapa definitivo de 2026 não é uma corrida de padrões. É um empilhamento. MCP vs A2A só é dilema se você recusou a fazer a pergunta certa. A2UI vs AG-UI só é dilema se você misturou payload com transporte. UCP vs AP2 só é dilema se você misturou vitrine com liquidação. O Google nomeou as camadas; o mercado de busca está procurando quem traduz isso para produção.

Traduza assim: protocolos movem mensagens; o Agent Harness decide o que pode acontecer no mundo; EmerAgents opera esse harness na fábrica. O próximo artigo deste cluster trata da superfície que o MCP abriu de verdade — Tool Poisoning, Prompt Injection e exfiltração. Porque padronizar a tomada elétrica sem disjuntor não é modernização. É escala do incidente.