O frontend costumava ser algo fixo. Designers desenhavam. Engenheiros construíam. Os usuários recebiam o que saía.
Isso acabou.
As interfaces que serão lançadas em 2026 são desenhadas, em parte, pelo próprio agente, em tempo real, a partir do que o usuário realmente pediu. Peça uma tabela, receba uma tabela. Não um parágrafo descrevendo uma.
Generative UI é a camada que permite que agentes parem de descrever e comecem a mostrar. Três padrões surgiram para construir isso, e as diferenças entre eles importam mais do que a maioria dos times imagina.
Mas não existe apenas uma maneira de construir isso. Existem três. E a maioria dos times escolhe um sem saber que fez uma escolha.
A pilha de protocolos
Três protocolos. Cada um faz um trabalho.
MCP conecta agentes a ferramentas. A2A conecta agentes entre si. AG-UI conecta agentes a usuários.
AG-UI é a camada de streaming que carrega tudo o que você verá abaixo: chamadas de ferramentas, esquemas A2UI, eventos MCP App, deltas de estado. Roda sobre SSE. O estado flui em ambos os sentidos no mesmo stream. O usuário edita, o agente vê. O agente modifica, o usuário vê.
A2UI é a especificação do Google para agentes emitirem UI como esquema. Roda sobre AG-UI. O CopilotKit entrega isso em produção.
Você não escreve um parser para nada disso. O CopilotKit é um cliente AG-UI e decodifica o stream para você.
Os três padrões que a maioria dos times confunde
Pergunte a dez desenvolvedores o que é Generative UI. Você recebe dez respostas. A maioria delas está descrevendo o padrão que o framework atual deles entrega.
Existem apenas três. O espectro vai de mais controle a mais flexibilidade.
- Controlado: Você pré-constrói os componentes. O agente escolhe qual renderizar.
- Declarativo: O agente emite um esquema. Seu app mapeia para componentes.
- Aberto: O agente escreve HTML puro. Seu app renderiza em uma sandbox.
Todo framework Gen UI em 2026 está em algum lugar nesta linha. As diferenças são arquiteturais, não cosméticas. Cada padrão quebra seu aplicativo de uma forma diferente em escala.
Eu testei diferentes stacks. A maioria cobre bem um padrão. Me estabeleci no CopilotKit porque ele suporta todos os três no mesmo runtime, rodando AG-UI. Essa é a stack na qual tudo abaixo roda.
Padrão 1: Controlado, frontend possui a UI
É aqui que a maioria dos times começa. É também onde a maioria dos times fica presa.
Você pré-constrói um componente React. Você o vincula a um nome de ferramenta. O agente escolhe essa ferramenta e o componente renderiza inline no chat com os argumentos do agente como props.
Um hook no frontend. Zero código de agente. É isso.
1"use client";2import { z } from "zod";3import { useComponent } from "@copilotkit/react-core/v2";45const expenseChartSchema = z.object({6 title: z.string(),7 data: z.array(z.object({ label: z.string(), value: z.number() })),8});910function ExpenseChart({ title, data }: z.infer<typeof expenseChartSchema>) {11 return (12 <section className="rounded-xl border p-4">13 <h3 className="text-sm font-medium">{title}</h3>14 <ul className="mt-2 grid gap-1">15 {data.map((d) => (16 <li key={d.label} className="flex justify-between text-sm">17 <span>{d.label}</span>18 <span>${d.value}</span>19 </li>20 ))}21 </ul>22 </section>23 );24}2526export function ExpensesCopilot() {27 useComponent({28 name: "showExpenseChart",29 description: "Renderize uma divisão de despesas por categoria.",30 parameters: expenseChartSchema,31 render: ExpenseChart,32 });3334 return null;35}
O hook registra a ferramenta com o runtime do CopilotKit. O runtime a anuncia para o agente via AG-UI. Quando o agente a chama, os argumentos chegam via stream e seu componente renderiza inline. Nenhuma ferramenta Python para escrever, nenhum esquema para conectar, nenhuma rota de API para adicionar.
Seu sistema de design continua no comando.
Aquele gráfico de despesas não é um mockup. O AI Financial Coach Agent renderiza cards exatamente como este para orçamentos reais, planos de economia e pagamento de dívidas.
Quer o hook básico primeiro? É o 'use-generative-ui-examples.tsx' no Projeto Inicial Generative UI.
O imposto de tokens
Cada componente que você registra fica na janela de contexto do agente antes que o usuário tenha dito algo. Uma descrição de ferramenta típica com seu esquema JSON consome cerca de 400 tokens. 25 componentes são 10.000 tokens a cada turno. Você paga esse imposto por requisição.
O agente também escolhe o componente errado. Muitos parecem semelhantes. Gráfico de pizza e gráfico de rosca ambos "mostram proporções". Ele adivinha.
Quando adicionar estado do lado do agente
Estado compartilhado é o único caso onde escrever uma ferramenta Python vale a pena. O agente escreve no estado da sessão. Outras partes da UI se inscrevem e re-renderizam sem uma segunda chamada de LLM. Fixe uma métrica, o dashboard atualiza. Adicione uma linha, a tabela redesenhada.
1from google.adk.agents import LlmAgent2from google.adk.tools import ToolContext34def pin_metric(tool_context: ToolContext, label: str, value: float) -> dict:5 """Fixar uma métrica no dashboard do usuário."""6 pinned = tool_context.state.get("pinnedMetrics", [])7 tool_context.state["pinnedMetrics"] = pinned + [{"label": label, "value": value}]8 return {"status": "pinned"}910agent = LlmAgent(name="dashboard_agent", model="gemini-3.5-flash", tools=[pin_metric])
O frontend lê as métricas fixadas através do hook de estado compartilhado do CopilotKit. O componente de chat ainda renderiza inline porque o mesmo nome de ferramenta está conectado com o hook do frontend.
Fixe uma métrica no chat. O painel redesenhado sem uma segunda chamada de modelo. Esse é o AI Dashboard Canvas Agent.
O AI Deep Research Agent vai além. O plano, cada pesquisa, cada escrita de arquivo, tudo isso chega via stream como cards ao vivo. Para todo o resto, o hook do frontend é a história completa.
Quando usar Controlado: Dez ou menos fluxos de alto valor. A precisão do design importa. Você sabe exatamente quais UIs precisa.
Quando não usar: Sua base de código cresce linearmente com os casos de uso. 25 componentes significam 25 definições de ferramenta em cada turno do agente.
O que quebra: O agente escolhe o componente errado. Duas descrições de ferramenta se sobrepõem semanticamente. Acima de 15 ferramentas, provavelmente duas delas soam como "exibe dados". Correção: reescreva as descrições para nomear a intenção do usuário, não o visual. "Use quando o usuário pedir para comparar proporções de um todo" vence "renderiza um gráfico de pizza".
Padrão 2: Declarativo (A2UI), agente emite esquema
Este é o padrão que a maioria dos aplicativos de agente em produção acaba precisando.
O agente emite um esquema JSON descrevendo a UI. Seu app tem um catálogo de componentes que mapeia nós do esquema para React (ou Svelte, Flutter, qualquer coisa). Uma ferramenta. Muitas UIs.
A2UI é a especificação padrão. O CopilotKit entrega o runtime. O ADK executa o agente. AG-UI é o fio.
A ferramenta do agente retorna três operações em ordem: criar uma superfície, enviar a árvore de componentes, enviar os dados.
1def search_flights(flights: list[Flight]) -> dict[str, Any]:2 """Pesquisar voos e exibi-los como cards ricos."""3 return {4 "a2ui_operations": [5 {"type": "create_surface", "surfaceId": SURFACE_ID, "catalogId": CATALOG_ID},6 {"type": "update_components", "surfaceId": SURFACE_ID, "components": FLIGHT_SCHEMA},7 {"type": "update_data_model", "surfaceId": SURFACE_ID, "data": {"flights": flights}},8 ]9 }
Esta é a função real, não pseudocódigo. O middleware do runtime vê o contêiner a2ui_operations no resultado da ferramenta e encaminha as superfícies para o frontend. Adicionando hotéis? Novo arquivo de esquema. Mais uma função com um surfaceId diferente. Zero trabalho extra no frontend.
Esquema fixo vs esquema dinâmico
A árvore de componentes acima está em flights.json. Você a escreveu. O agente apenas preenche os dados. Isso é um esquema fixo.
Esquema dinâmico inverte isso: um LLM secundário escreve a árvore de componentes por turno a partir do contexto da conversa. O mesmo contêiner a2ui_operations no final. O showcase do Google ADK entrega ambos.
O catálogo é o contrato
As definições listam os componentes que o agente pode emitir, com esquemas Zod para as props. Os renderizadores preenchem o React. Erros de digitação se tornam erros de compilação em vez de telas em branco.
1const renderers: CatalogRenderers<TravelDefinitions> = {2 FlightCard: ({ props }) => (3 <article className="rounded-xl border p-4">4 <header className="flex justify-between">5 <span>{(props as any).airline}</span>6 <span>{(props as any).price}</span>7 </header>8 <div className="text-sm text-muted-foreground">9 {(props as any).origin} → {(props as any).destination} · {(props as any).departureTime}10 </div>11 </article>12 ),13};1415export const travelCatalog = createCatalog(travelDefinitions, renderers, {16 catalogId: "copilotkit://travel-catalog",17 includeBasicCatalog: true,18});
Ambas as metades estão no Projeto Inicial Generative UI, conectados e correspondidos. search_flights em 'a2ui_fixed_schema.py', o catálogo FlightCard em 'renderers.tsx'. Peça voos. Veja os cards chegarem via stream no chat.
Botões e outros componentes interativos carregam uma ação no esquema. O catálogo básico a conecta ao onClick. O clique dispara um evento de volta para o agente via AG-UI. O agente decide o que renderizar a seguir. Zero manipuladores de clique.
A matemática dos tokens
50 tipos de card ou 500, o agente vê uma função. Tokens por turno permanecem estáveis à medida que sua biblioteca de componentes cresce.
Extensível para qualquer framework de renderização porque é apenas JSON. Qualquer agente que já fale AG-UI pode conduzir A2UI no dia zero. Você não toca no código do agente para conectar isso.
Compensação: O LLM possui o layout. A saída varia de execução para execução dentro do seu catálogo. Se você está enviando divulgações legais, superfícies de marketing ou qualquer coisa onde o posicionamento exato de pixels importa, este não é seu balde.
Declarativo é o padrão construído para a cauda longa. Dashboards, resultados, formulários, cards, widgets.
Quando usar Declarativo: Você tem mais casos de uso do que tempo para pré-construir. Você se importa com a economia de tokens após o estágio de protótipo.
O que quebra: Construiu um FlightCard personalizado. Cada voo renderiza como o card genérico do catálogo básico. Nenhum erro no console. O CATALOG_ID no agente e catalogId no createCatalog no frontend não correspondem. O frontend não reconhece o catálogo que o agente está segmentando, caindo para o básico. Corresponda exatamente as strings em ambos os lados.
Padrão 3: Aberto, sem catálogo, sem regras
O terceiro padrão é o extremo oposto. Sem catálogo. Sem esquema. Apenas uma tela em branco.
Dois subpadrões vivem neste balde.
MCP Apps
Um servidor MCP expõe superfícies de UI que o agente conduz. Excalidraw é o exemplo que ficou comigo. O agente obtém controle total da tela. Desenha diagramas a partir do seu contexto. Possui cada pixel no quadro.
Implementar o protocolo do cliente do zero é doloroso, então o CopilotKit envia um MCPAppsMiddleware . Anexe-o ao seu agente e aponte para qualquer servidor MCP Apps.
1const agent = new BuiltInAgent({2 model: "openai/gpt-5.5",3 prompt: "Você é um assistente útil.",4}).use(5 new MCPAppsMiddleware({6 mcpServers: [{ type: "http", url: "https://mcp.excalidraw.com/mcp", serverId: "my-server" }],7 }),8);
Inicie o MCP Apps Showcase e você estará reservando voos e hotéis dentro da janela de chat. Mesmo middleware, servidores MCP reais. Ou vá além.
O AI MCP App Builder permite que o agente escreva um aplicativo novo em uma sandbox E2B e depois o renderize ao vivo.
0:45
HTML em sandbox
O agente escreve HTML puro. Seu app renderiza dentro de um iframe com sandbox para que não possa sequestrar a sessão.
O runtime registra uma ferramenta de renderização HTML e a envia para o agente via AG-UI. O agente a chama com qualquer marcação que desejar. Não há ferramenta HTML para definir no lado do agente. O runtime a injeta.
A instrução do lado do agente está fazendo trabalho real:
1canvas_agent = LlmAgent(2 name="canvas_agent",3 model="gemini-3.5-flash",4 instruction=(5 "Você é um assistente de visualização. Quando o usuário pedir para ver, "6 "desenhar ou visualizar qualquer coisa, gere uma UI HTML interativa. "7 "Use apenas classes Tailwind. Sem fontes externas. Use cores neutras "8 "a menos que o usuário nomeie uma."9 ),10)
Sem essas regras de estilo, o modelo padroniza para a estética que era mais alta em seus dados de treinamento naquela semana. Com elas, você obtém algo próximo à sua marca na maioria das vezes. Nem sempre.
O problema da inconsistência de marca
Tentei enviar Aberto como a UI principal para um agente. Desisti em uma semana.
"Neo-brutalista" na terça. "Clone do iOS 4" na quarta. Regras de estilo no prompt empurram o agente em direção à sua marca. Elas não a garantem. A marca continuava mudando. O produto parecia não ser sério.
Aberto não é inútil. É mal aplicado.
Escolha certa para uma coisa: interações descartáveis onde o usuário não se importa com a aparência da interface e nunca a verá novamente. "Me mostre como os elétrons funcionam." "Me dê um gráfico de barras estranho das minhas últimas 10 consultas." "Visualize esta resposta de API." O tipo de coisa que você vê nas visões gerais do Google AI.
Quando usar Aberto: Consultas únicas. Visualizações descartáveis. Experimentos em sandbox. Nunca como a superfície principal.
O que quebra: O iframe renderiza. Botões não clicam. Formulários não enviam. As flags de sandbox são muito restritivas, ou muito permissivas de uma forma que o navegador recusa. Defina a sandbox do iframe para permitir scripts e permitir formulários. Nada mais. Nunca allow-same-origin.
Como escolher
Execute a árvore de decisão antes de escrever código.
O designer tem mockups pixel-perfect para este fluxo? Controlado.
Dezenas de tipos de card ou widgets para enviar? Declarativo.
Visualização descartável única que o usuário nunca verá duas vezes? Aberto.
Não consegue decidir? Padrão para Declarativo. Atualize para Controlado para os 3 principais fluxos. Nunca Aberto como padrão.
Se você já está enviando e não tem certeza onde caiu, conte as ferramentas de renderização. Acima de 15, você está em Controlado e o muro está próximo. Comece a configurar A2UI esta semana.
Três padrões. Três apostas.
Controlado aposta em você. Componentes pré-construídos, pixel-perfect. Caro acima de 25 deles.
Declarativo aposta no esquema. O esquema é o contrato. O agente o preenche. Escala horizontalmente.
Aberto aposta no modelo. Sem catálogo, sem esquema, HTML puro. Bom para descartáveis. Frágil para qualquer coisa que seja enviada duas vezes.
O erro não é escolher o padrão errado. É não saber que você escolheu um.
A maioria dos times padroniza para Controlado porque o framework padroniza para Controlado. Eles batem no muro aos 25 componentes e recorrem ao Aberto porque parece convincente em demonstrações. Nenhuma das duas foi uma decisão. Ambas foram deriva.
Escolha de propósito. Corresponda o padrão ao problema. Controlado para os fluxos que precisam ser exatos. Declarativo para a cauda longa. Aberto para o descartável.
Modelos de Agente Generative UI de Código Aberto
A referência para todos os três está na nova seção Generative UI Agents do awesome-llm-apps. Clone o que precisar. Remova o que não precisar.
Publicarei mais sobre como enviar agentes em produção, AG-UI e os padrões que escalam. Siga-me @Saboo_Shubham_ para ficar ligado.
