A2UI explicado: o que o protocolo Agent-to-UI faz (e não faz)
A2UI é um protocolo JSON declarativo que permite que agentes de IA descrevam interfaces para um cliente renderizar. Como funciona, quais renderizadores existem e o que não faz.
Ponto principal
A2UI (Agent to UI) é um protocolo JSON aberto e declarativo criado pelo Google. Um agente de IA envia uma descrição de uma interface e um cliente a renderiza com seus próprios componentes nativos em vez de executar o código do agente. É uma maneira de mover a estrutura e os dados da UI através de um limite de confiança, não de um sistema de animação, de uma biblioteca de componentes ou de um renderizador finalizado. ExodeUI não é um renderizador A2UI e não é afiliado ao Google.
O que é A2UI?
A2UI é um protocolo para interfaces controladas por agente. Em vez de retornar uma parede de texto ou executar o código gerado, um agente de IA envia um fluxo de mensagens JSON que descrevem uma UI: qual superfície criar, quais componentes ela contém e quais dados os preenchem. O cliente recebe essas mensagens e renderiza o resultado com componentes nos quais já confia. A2UI foi criado pelo Google e é licenciado pelo Apache 2.0, com contribuições do CopilotKit e da comunidade de código aberto. Em outubro de 2026, a especificação de produção atual era v0.9.1 e v1.0 era uma candidata a lançamento.
O problema que A2UI está tentando resolver
Os agentes são bons em produzir uma resposta útil e ruins em fornecê-la como uma interface. Uma resposta de texto não pode mostrar uma tabela de comparação, um formulário de pedido ou um painel. A geração arbitrária de HTML ou JavaScript resolve o problema de apresentação e cria um problema de segurança, porque o cliente agora está executando um código que não escreveu. A2UI segue um terceiro caminho: o agente descreve a UI em um formato restrito e o cliente decide como renderizá-la. O agente só pode usar componentes aprovados pelo cliente e a saída são dados em vez de código executável.
Como uma superfície A2UI é construída
O protocolo usa um pequeno conjunto de tipos de mensagens. O esquema exato muda entre as versões, portanto verifique a especificação antes de implementar uma, mas a forma é estável.
- createSurface: diz ao renderizador para criar uma nova superfície, que é uma região da interface que o agente pode atualizar
- updateComponents: adiciona ou altera definições de componentes nessa superfície
- updateDataModel: altera os dados exibidos pelos componentes, sem reenviar a estrutura
- deleteSurface: remove uma superfície quando ela não é mais necessária
Renderizadores e transportes
A2UI é independente de transporte. A especificação descreve as mensagens, não como elas viajam. O projeto lista implementações de renderizador para Angular, Flutter, Lit, React e Markdown, e ligações de transporte para AG-UI, A2A e MCP, com WebSockets, SSE e REST também utilizáveis. Essa flexibilidade é o ponto: a mesma resposta do agente pode ser renderizada por um cliente web, um aplicativo móvel ou um aplicativo desktop, cada um usando seu próprio sistema de design.
O que A2UI não faz
A2UI é fácil de ler demais. Ele não vem com uma biblioteca de componentes que você pode inserir em um aplicativo e não renderiza nada por si só: você precisa de um renderizador e de um catálogo de componentes que o cliente controle. Ele não decide como a IU se move. Ele não substitui o MCP, que expõe ferramentas e dados a um modelo, ou AG-UI, que transporta os eventos de interação entre um agente e um frontend. E isso não elimina a necessidade de revisão de engenharia: as interfaces geradas ainda precisam lidar com carregamento, estados vazios e de erro, permissões e acessibilidade.
A2UI vs AG-UI vs MCP
Esses três são frequentemente mencionados juntos porque resolvem diferentes camadas do mesmo problema. Um atalho útil: A2UI descreve a interface, AG-UI realiza a interação e MCP fornece ferramentas e dados ao agente. A própria documentação do A2UI descreve AG-UI como uma ligação de transporte para A2UI, e A2UI também pode viajar por MCP. São padrões complementares e não concorrentes. Se você está escolhendo uma integração, comece pelo que seu cliente pode renderizar e qual transporte ele já suporta, e não pelo protocolo com maior impulso.
Onde a animação e a interação se encaixam
A2UI descreve estrutura e dados. O movimento é uma preocupação do cliente: o renderizador decide se uma superfície aparece instantaneamente, desaparece ou transita de um estado anterior. Isso é uma boa notícia para as equipes de produto, pois mantém o sistema de animação no cliente onde pode respeitar o sistema de design e as configurações de acessibilidade. Isso também significa que uma implementação A2UI não é animada automaticamente. Se uma interface gerada precisar pressionar um botão, uma transição de estado ou uma reação de mascote, o cliente deverá fornecer esse comportamento. ExodeUI pode reproduzir movimento interativo em um cliente e possui um servidor MCP para ferramentas de codificação de IA, mas não é um renderizador A2UI e não deve ser descrito como tal.
Trecho de implementação em produção
// Simplified shape of an A2UI message stream (schema differs by version).
{ "createSurface": { "surfaceId": "cart" } }
{ "updateComponents": { "surfaceId": "cart", "components": [ /* ... */ ] } }
{ "updateDataModel": { "surfaceId": "cart", "data": { /* ... */ } } }
{ "deleteSurface": { "surfaceId": "cart" } }Princípios-chave para lembrar
- A2UI é um protocolo JSON para interfaces descritas por agentes, criado pelo Google e licenciado sob Apache 2.0
- O cliente renderiza com seus próprios componentes; o agente não executa código de UI arbitrário
- Define mensagens e deixa o renderizador, transporte e movimento para o cliente
- Não é um sistema de animação ou uma biblioteca de componentes drop-in
- ExodeUI não é um renderizador A2UI e não tem afiliação com o Google