Para quem o seu agente está falando?
MCP, A2A, AG-UI e A2UI não competem entre si: cada um cuida de uma conversa diferente do agente. Sigo um único pedido, um plano de estudos para a SAA no AgentCore, e mostro onde cada protocolo entra e por que AG-UI e A2UI não são a mesma coisa.
Series: Agentic AI (1 article)
- 1Para quem o seu agente está falando? This article
"O agente se comunica por MCP" é uma frase comum, e está só um quarto certa. Um agente em produção conversa com pelo menos quatro interlocutores diferentes, e cada conversa tem o seu protocolo.
Vamos seguir um cenário de um pedido só, do começo ao fim e mostrar onde cada um entra.
A pergunta certa
No lugar de decorar siglas vamos fazer a seguinte pergunta: para quem o agente está falando agora?
Se ele está buscando dados ou chamando uma ferramenta, a conversa é com um servidor de ferramentas, usamos o protocolo MCP (Model Context Protocol).
Se ele está delegando uma tarefa para outro agente, que tem as próprias instruções e o próprio modelo, é o A2A (Agent2Agent).
Se ele está avisando o frontend do que está acontecendo, é o AG-UI (Agent-User Interaction Protocol).
E se ele quer que a tela mostre um formulário, uma tabela ou um botão em vez de um parágrafo de texto, entra o A2UI (Agent-to-User Interface).
Quando o Amazon Bedrock AgentCore Runtime passou a suportar AG-UI, em março de 2026, o anúncio posicionou o protocolo como complemento ao suporte a MCP e A2A que o Runtime já tinha: MCP dá ferramentas ao agente, A2A liga agente a agente, AG-UI leva o agente para a aplicação do usuário. O A2UI vem do Google e completa o quadro do lado da interface.
O pedido
Vou usar como exemplo um assistente de estudos para certificação AWS. O usuário digita:
Quero fazer a prova de Solutions Architect Associate em seis semanas. Monta um plano e me dá umas questões para eu saber onde estou.
Parece um pedido só. Por baixo, são quatro conversas.
Conversa 1: o agente com as ferramentas (MCP)
Para montar o plano, o agente precisa saber o que cai na prova e consultar a documentação dos serviços. Ele não tem isso no modelo, ou tem desatualizado. Então chama as ferramentas expostas por um servidor MCP: uma que busca na documentação da AWS e outra que lê o guia do exame.
É o MCP que padroniza essa conversa.
O agente descobre quais ferramentas existem, lê o schema de cada uma e faz a chamada.
Quem implementa o servidor não precisa saber qual framework de agente está do outro lado. No AgentCore, o Gateway transforma APIs e funções Lambda em ferramentas MCP, e o Runtime também hospeda servidores MCP.
Um detalhe costuma passar batido: a ferramenta não decide nada. Ela recebe argumentos e devolve dados. Quem raciocina é o agente.
Conversa 2: o agente com outro agente (A2A)
Gerar questões de simulado boas é outro trabalho. Exige instruções próprias, talvez outro modelo, talvez uma base de questões revisadas. Faz sentido isso ser um agente separado, mantido por outra pessoa ou até outro time.
Aqui o protocolo é o A2A.
O agente principal descobre o agente de simulados pelo Agent Card, um documento que descreve o que ele sabe fazer e como chamá-lo. Depois envia uma tarefa ("10 questões de nível intermediário sobre resiliência e alta disponibilidade") e acompanha o andamento até receber o resultado.
A diferença para o MCP é de natureza, não de formato. Uma ferramenta MCP executa uma função. Um agente A2A recebe um objetivo, decide como cumprir, pode levar minutos e pode devolver resultados parciais. É suportado pelo AgentCore Runtime.
Conversa 3: o agente com o frontend (AG-UI)
Enquanto isso, o usuário está olhando para a tela. Se nada aparecer por 40 segundos, ele acha que travou.
O AG-UI resolve essa conversa.
Ele é um protocolo de eventos: o agente emite uma sequência tipada e o frontend reage.
Uma execução típica fica assim:
1
2
3
4
5
6
7
8
RUN_STARTED
TOOL_CALL_START (buscar_guia_do_exame)
TOOL_CALL_END
STATE_DELTA (progresso: 30%)
TEXT_MESSAGE_START
TEXT_MESSAGE_CONTENT "Separei o conteúdo em quatro domínios..."
TEXT_MESSAGE_END
RUN_FINISHED
Com isso, a interface pode mostrar "consultando o guia do exame", atualizar uma barra de progresso e ir escrevendo a resposta conforme ela chega.
Os eventos trafegam por SSE ou WebSocket, e o AgentCore Runtime cuida da autenticação, do isolamento de sessão e da escala dos servidores AG-UI.
Repare que o AG-UI não diz como a tela deve ser. Ele diz o que aconteceu.
Conversa 4: o que aparece na tela (A2UI)
Daria para entregar o plano de seis semanas como um texto longo.
Fica muito melhor como uma tabela de semanas, com um botão para marcar o que já foi estudado e um seletor de data da prova.
O A2UI permite que o agente descreva essa interface sem mandar HTML nem JavaScript. Ele envia mensagens declarativas, e o app renderiza com os próprios componentes. Sequência básica tem três mensagens (simplifiquei os campos):
1
2
3
4
5
6
{"version": "v0.9", "createSurface": {"surfaceId": "plano", "catalogId": "https://a2ui.org/specification/v0_9/catalogs/basic/catalog.json"}}
{"version": "v0.9", "updateComponents": {"surfaceId": "plano", "components": [
{"id": "root", "component": "Column", "children": ["titulo", "semanas"]},
{"id": "titulo", "component": "Text", "text": {"path": "/titulo"}}
]}}
{"version": "v0.9", "updateDataModel": {"surfaceId": "plano", "path": "/titulo", "value": "Plano SAA: 6 semanas"}}
createSurface abre uma área na tela, updateComponents define a estrutura e updateDataModel preenche os dados. Estrutura e dados ficam separados, então o agente pode atualizar o progresso sem redesenhar a tabela.
Na segurança, o ganho é real: o cliente só renderiza componentes de um catálogo que ele conhece. O agente não consegue injetar um script.
AG-UI e A2UI não são a mesma coisa
Essa é a confusão mais comum, porque os dois falam de "agente e interface".
O AG-UI é o cano. Ele transporta eventos e estado entre o agente e o frontend. O A2UI é uma das coisas que podem passar pelo cano: a descrição de uma interface.
O A2UI não depende de transporte e pode ir sobre A2A, WebSocket, REST ou AG-UI. A CopilotKit, que criou o AG-UI, trabalhou com o time do A2UI para que agentes que já falam AG-UI conseguissem enviar A2UI desde o lançamento da v0.9.
Dá para usar AG-UI sem A2UI (só texto e progresso) e A2UI sem AG-UI (por exemplo, dentro de mensagens A2A). Juntos, um entrega os eventos e o outro diz o que desenhar.
Quando eu não usaria cada um
MCP para tudo que for chamada determinística: consultar, gravar, calcular. Se você está pensando em transformar uma função simples em "agente" só para usar A2A, provavelmente é uma ferramenta MCP.
A2A só quando o outro lado precisa de autonomia de verdade ou pertence a outro time. Ele traz descoberta, tarefas longas e estados intermediários, e isso tem custo de operação. Para dois agentes do mesmo código, um subagente local resolve.
AG-UI quase sempre que houver uma tela, porque streaming e progresso fazem diferença na percepção do usuário desde o primeiro protótipo.
Para um formulário ou uma tabela que se repetem, eu começaria por componentes fixos no frontend e deixaria o A2UI para as telas que mudam conforme o pedido.
Links:
Series: Agentic AI (1 article)
- 1Para quem o seu agente está falando? This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article