Chat SDK da Vercel adiciona streaming de UI generativa via json-render

A Vercel documentou, em seu changelog oficial, uma integração entre o Chat SDK (o framework da empresa para construir bots conversacionais) e uma nova biblioteca chamada json-render. Na prática, ela resolve um problema que quem já construiu bot para Slack ou Teams conhece bem: cada plataforma tem seu próprio formato de card (Block Kit de um lado, Adaptive Cards do outro), e manter os dois sincronizados manualmente é trabalho repetido.

Com json-render, o 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 → não escreve Block Kit nem Adaptive Cards diretamente. Ele escreve uma especificação em JSON a partir de um catálogo tipado de componentes (tabelas, gráficos, botões etc.), e a biblioteca converte essa especificação em um card do Chat SDK. Cada adapter de plataforma pega esse card intermediário e o traduz para o formato nativo correspondente.

Catálogo tipado em vez de um adaptador por mensagem

O ponto central da arquitetura é o catálogo: uma definição, feita uma única vez, de quais componentes existem e quais props cada um aceita. É esse catálogo que vira contexto para o modelo (via catalog.prompt()), dizendo a ele exatamente que JSON é válido.

Isso muda o fluxo de trabalho de quem constrói o bot. Em vez de escrever um template de mensagem para cada combinação de "tabela de vendas", "gráfico de uso" ou "botões de aprovação", o time define o catálogo de componentes uma vez e deixa o modelo decidir, mensagem a mensagem, qual combinação usar. O exemplo publicado pela Vercel mostra a estrutura mínima:

import { defineCatalog } from "@json-render/core";
import {
 schema,
 standardComponentDefinitions,
 streamCard,
} from "@json-render/chat";
import { streamText } from "ai";

const catalog = defineCatalog(schema, {
 components: standardComponentDefinitions,
});

bot.onNewMention(async (thread, message) => {
 const result = streamText({
 model: "anthropic/claude-haiku-5.5",
 system: catalog.prompt(),
 prompt: message.text,
 });
 await streamCard(thread, result.textStream);
});

Repare que o pacote ai (o AI SDK da própria Vercel) continua fazendo o trabalho de chamar o modelo com streamText(); o json-render entra depois, pegando esse stream de texto e transformando em UI. É o mesmo padrão de generative UI que a Vercel já popularizou no AI SDK para aplicações web (com streamUI e React↳React37 conteúdos7 erros com React moderno que só aparecem em produção; e como evitarDev (Back & Front) · abr 2026React Native 0.76: o futuro do desenvolvimento mobileDev (Back & Front) · out 2024Simplificando componentes com React HooksDev (Back & Front) · mar 2019Ver tudo em Dev (Back & Front) → Server Components), agora aplicado a superfícies de chat em vez de página renderizada no navegador.

O card nasce incompleto e vai se completando

A função streamCard() não espera o JSON inteiro chegar para postar algo na thread. Ela publica o card assim que o elemento raiz da especificação tem conteúdo, e vai atualizando a mensagem conforme novos elementos chegam no stream do modelo.

Por padrão, as edições saem no máximo uma a cada 500 ms, o mesmo intervalo de streaming que o Chat SDK já usa para texto puro. Quando o stream termina, a mensagem mostra a versão final e validada do card, não mais um JSON parcial. Para quem vem do mundo de generative UI em front-end, é o equivalente a um esqueleto de carregamento que vai ganhando componentes reais até fechar no layout definitivo.

Validação de schema com loop de correção

A função toCard confere cada prop de cada elemento contra o schema do componente correspondente no catálogo. Se o modelo gerar uma especificação inválida, toCard lança um CardSpecError com uma lista legível de problemas, um por elemento.

O detalhe que interessa a quem constrói agentes de verdade é que essa lista de erros pode ser devolvida ao próprio modelo como contexto, pedindo uma especificação corrigida. É um padrão comum em sistemas agentic (validar, falhar, reenviar o erro, deixar o modelo se corrigir), mas aqui ele já vem resolvido pela biblioteca em vez de precisar ser montado à mão a cada projeto.

Os limites que cada plataforma impõe

Slack e Teams não aceitam qualquer coisa num card, e o comportamento padrão dos adapters do Chat SDK é degradar o conteúdo que excede esses limites em vez de rejeitar. O exemplo citado pela Vercel: o adapter do Slack transforma uma segunda tabela, além da primeira permitida, em um bloco de código.

Essa degradação silenciosa pode ser o comportamento certo para um dashboard informativo, mas é arriscada quando o card carrega uma ação (um botão de aprovar, por exemplo) que o usuário espera ver clicável e que vira texto sem função. Para esses casos, o json-render permite passar limites explícitos à validação, fazendo a especificação ser rejeitada (e reenviada ao modelo) em vez de silenciosamente simplificada.

Para quem isso importa e quando não compensa

Em resumo: quem já mantém um bot de produtividade em Slack ou Teams, com múltiplos tipos de card (relatório, alerta, aprovação, status), ganha um único catálogo tipado em vez de um template por formato de mensagem, mais a validação de schema que normalmente teria que escrever na mão.

O trade-off é o mesmo de qualquer generative UI orientada a modelo: cada card custa uma chamada ao modelo (no exemplo, claude-haiku-5.5) e introduz latência e a possibilidade de uma primeira especificação inválida que precisa de uma segunda rodada de correção antes de aparecer na tela. Para bots com um número pequeno e fixo de formatos de mensagem, montar o Block Kit ou o Adaptive Card diretamente, sem um modelo decidindo a estrutura, ainda tende a ser mais previsível e mais barato de rodar.

Vale a pena quando o catálogo de mensagens é grande, muda com frequência, ou quando o próprio agente precisa decidir dinamicamente que tipo de componente a resposta exige, não quando existem dois ou três formatos de card estáveis que já funcionam bem escritos à mão.

Fonte: Vercel Changelog