A2UI do Google e CopilotKit trazem UI generativa para agentes em TypeScript

Da lista de textos à interface que o agente desenha

Até pouco tempo atrás, pedir pra um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → montar uma viagem significava receber um bloco de texto corrido: seis pacotes para Bali em março, cada um com data, hotel, voo e preço, tudo em prosa. Você escolhia um, o agente mandava um link, e a reserva de fato acontecia em outro lugar.

O problema não era o agente não saber planejar. Era a falta de um jeito padrão de ele desenhar, dentro da própria conversa, uma lista selecionável, um mapa do destino ou um seletor de data que levasse o usuário até o fim do fluxo.

Em 29 de outubro de 2026, a equipe do Google publicou, em conjunto com Atai Barkai, CEO da CopilotKit, um guia mostrando como fechar essa lacuna com dois componentes: o A2UI (Agent-to-UI), padrão aberto do Google para descrever interfaces geradas por agente, e o CopilotKit, camada de integração que liga esse padrão a frameworks como LangChain, Google ADK, AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → Strands e Mastra. Neste tutorial, sigo o caminho que os dois times documentaram, do backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → em Python até o catálogo de componentes no frontend em TypeScript.

O que exatamente é o A2UI

A2UI resolve um espectro de problema, não um só ponto. Numa ponta, você define cada componente de antemão e o agente só escolhe qual usar e com quais dados: é seguro para a marca, mas não personaliza de verdade. Na outra ponta, o agente devolve um programa de UI inteiro em HTML, JavaScript ou Dart, executado num iframe isolado: cobre qualquer caso não previsto, ao custo de fugir do seu design system↳Design system5 conteúdosComo desenvolvemos o novo Design System do AsaasProduto & UX · jul 2024UX e Código: Por que designers que conhecem programação têm uma vantagem estratégicaProduto & UX · abr 2025A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → e rodar código que um modelo escreveu.

O modo declarativo, o mais usado na prática, fica no meio: o agente monta a tela a partir de componentes pré-declarados, numa linguagem comum que qualquer renderizador entende. Três características sustentam esse modo:

• Segurança por padrão: A2UI é dado declarativo, não código executável. O cliente mantém um catálogo de componentes confiáveis, e qualquer coisa que o agente inventar fora dele é barrada antes de chegar na tela.
• Streaming amigável para LLM: a resposta é uma lista plana de mensagens JSON pequenas que se referenciam por ID, então o agente emite aos poucos e o cliente renderiza os componentes conforme chegam.
• Portabilidade real: a mesma resposta roda em React, Lit, Angular, SwiftUI, Jetpack Compose e Flutter, além de renderizadores da comunidade para Vue e até terminal.

O catálogo básico do A2UI traz 18 primitivos de layout, exibição, input e contêiner. Na prática, a maioria dos projetos de produção define o próprio catálogo customizado, porque 18 blocos genéricos raramente bastam para um FlightCard ou um mapa com rota desenhada em tempo real.

O papel do CopilotKit e do AG-UI nisso tudo

A2UI é o formato. CopilotKit é quem conecta esse formato ao seu agente e à sua interface. Ele é construído sobre o AG-UI (Agent-User Interaction Protocol), que já tem SDKs para vários backends agênticos e sabe carregar payloads A2UI como eventos tipados.

Isso sustenta o ângulo cross-framework da proposta: como LangChain, Google ADK, AWS Strands e Mastra são todos compatíveis com AG-UI, a configuração do lado do CopilotKit fica idêntica não importa qual framework roda o agente por trás. Trocar de LangChain para Strands não deveria exigir reescrever a parte de UI.

Colocando o agente no ar

O guia usa Google ADK como exemplo de backend. O pacote ag_ui_adk embrulha qualquer agente ADK e expõe um endpoint AG-UI via FastAPI:

from fastapi import FastAPI
from google.adk.agents import LlmAgent
from ag_ui_adk import ADKAgent, add_adk_fastapi_endpoint

root_agent = LlmAgent(
    name="flight_agent",
    model="gemini-3.8-flash",
    instruction="Help users find and book flights. Call generate_a2ui to show results.",
)

adk_agent = ADKAgent(
    adk_agent=root_agent,
    app_name="flights",
    user_id="demo_user",
    use_in_memory_services=True,
)

app = FastAPI()
add_adk_fastapi_endpoint(app, adk_agent, path="/")

Repare que o agente chama generate_a2ui sem que essa função tenha sido definida no backend. Isso acontece porque, nesse exemplo, o catálogo A2UI é configurado dinamicamente pelo cliente e enviado junto com a requisição, em vez de ficar fixo no servidor. A2UI suporta os dois modelos, fixo ou dinâmico, e a escolha muda onde fica a fonte da verdade do catálogo.

Do lado da aplicação, você registra esse endpoint no runtime do CopilotKit em /api/copilotkit. É configuração padrão, sem nada específico de A2UI, coberta no quickstart do Google ADK.

Definindo o que o agente pode desenhar

A parte que de fato liga o A2UI à sua interface acontece no cliente, onde seus componentes já existem. Você declara o que o agente pode desenhar, mapeia cada definição a um renderer, e passa esse catálogo para o provider do CopilotKit:

import { CopilotKit, CopilotChat } from '@copilotkit/react-core/v2';
import {
  createCatalog,
  type CatalogDefinitions,
  type CatalogRenderers,
} from '@copilotkit/a2ui-renderer';
import { z } from 'zod';

const catalogDefinitions = {
  FlightCard: {
    description: 'A flight result with airline, times, and stops.',
    props: z.object({
      airline: z.string(),
      departs: z.string(),
      arrives: z.string(),
      stops: z.number(),
    }),
  },
} satisfies CatalogDefinitions;

const catalogRenderers = {
  FlightCard: MyFlightCard, // seu componente React já existente
} satisfies CatalogRenderers<typeof catalogDefinitions>;

const catalog = createCatalog(catalogDefinitions, catalogRenderers, {
  catalogId: 'flight-catalog',
  includeBasicCatalog: true,
});

<CopilotKit runtimeUrl="/api/copilotkit" a2ui={{ catalog }}>
  <CopilotChat />
</CopilotKit>

A description de cada componente vai para o prompt do agente, então é ela que ensina o modelo a escolher FlightCard em vez de um card genérico quando a resposta é um voo. O schema Zod valida as props que voltam: se o agente mandar stops como string, a validação pega antes de o componente quebrar na tela. Essa dupla função, descrição como instrução e schema como contrato, é o ponto onde vale investir tempo revisando: um description vago gera escolha de componente errada com a mesma frequência que um prompt vago gera resposta ruim.

Quando o usuário também fala com o agente pela interface

A maior parte das UIs geradas por agente, até aqui no mercado, é de mão única: o agente desenha, você lê, e a tela fica obsoleta assim que algo muda. O diferencial do A2UI sobre AG-UI é que as superfícies são bidirecionais e os componentes reativos, o que viabiliza fluxos de vários passos dentro da mesma tela.

Dois elementos fazem essa ida e volta funcionar: inputs amarrados a um caminho de dado (path), e um botão que carrega uma ação nomeando quais caminhos enviar de volta:

{
  "id": "cabin",
  "component": "ChoicePicker",
  "variant": "mutuallyExclusive",
  "options": [
    { "label": "Economy", "value": "eco" },
    { "label": "Business", "value": "biz" }
  ],
  "value": { "path": "/booking/cabin" }
},
{
  "id": "confirm",
  "component": "Button",
  "child": "confirm_label",
  "action": {
    "event": {
      "name": "confirmBooking",
      "context": {
        "cabin": { "path": "/booking/cabin" },
        "email": { "path": "/booking/email" }
      }
    }
  }
}

A validação roda no cliente: um e-mail mal formatado mostra erro inline sem gastar uma chamada ao modelo. Nada chega ao agente até o botão disparar. Quando dispara, o cliente manda os valores amarrados e o agente reemite a superfície contra o mesmo surfaceId, de forma que busca de voo, resultados, dados do passageiro e confirmação moram todos na mesma tela, sem trocar de componente a cada etapa.

O que você ganha de graça rodando sobre AG-UI

Como A2UI roda em cima do AG-UI, algumas garantias vêm embutidas em vez de serem trabalho seu:

• Setup mínimo no servidor: o catálogo chega ao agente na configuração; registrar no cliente já é suficiente.
• Geração num sub-agente dedicado: o catálogo e as regras do protocolo ficam fora do contexto do agente principal, e a superfície chega ao cliente conforme o sub-agente a produz.
• Correção automática: gerações inválidas são capturadas e o erro específico volta para o modelo corrigir, então nada quebrado chega na tela.
• Falha graciosa: esgotadas as tentativas de correção, a superfície resolve numa mensagem curta e a conversa segue em vez de travar num estado de erro.

Para rodar na sua máquina agora

O ponto de entrada mais rápido é o gerador oficial:

npx copilotkit@latest create --name my-app --framework a2ui

Ele sobe uma aplicação A2UI completa já integrada com um agente via CopilotKit. O CopilotKit Dojo tem demos executáveis: um schema fixo definido no servidor, um schema dinâmico contra um catálogo customizado, e um exemplo de recuperação de erro em que uma primeira geração inválida se corrige sozinha.

O que ainda fica por sua conta

O material do Google e da CopilotKit resolve o transporte e a validação, mas não resolve design. Definir um catálogo customizado bom, com descrições que o modelo interprete sem ambiguidade, ainda é trabalho de UX tanto quanto de engenharia: o catálogo básico de 18 primitivos deliberadamente não serve para produção.

Vale notar também que adotar A2UI via CopilotKit amarra o front ao protocolo AG-UI como camada de transporte. Isso não é um problema em si, é justamente o que permite trocar de LangChain para Strands sem reescrever a UI, mas é uma decisão de arquitetura, não um detalhe de implementação, e compensa avaliar antes de colocar em produção com tráfego real.

Fonte: Google Developers Blog