What happened
Vercel’s changelog describes an integration between Chat SDK and json-render. An agent writes a JSON specification against a typed catalog of components, and json-render converts that specification into a Chat SDK card. The catalog includes tables, charts, buttons, and other components. Chat SDK adapters then post the card in the destination platform’s native format; Vercel names Block Kit for Slack and Adaptive Cards for Teams as examples.
The integration is designed to stream a card while the model is generating it. The streamCard function posts once the card’s root element has content, then updates the message as additional elements arrive. By default, edits are sent at most once every 500 milliseconds, which Vercel says matches Chat SDK’s streaming interval. When generation ends, the message contains the final validated card.
Vercel’s example defines a catalog with defineCatalog, schema, and standardComponentDefinitions. A Chat SDK bot responds to a new mention by calling streamText; the example uses anthropic/claude-haiku-5.5 as its model, supplies the catalog prompt as the system prompt, and passes the resulting text stream to streamCard. The example illustrates the integration rather than a requirement to use that particular model.
Validation and platform limits are part of the workflow. toCard checks each element’s properties against its component schema and throws a CardSpecError for invalid specifications. Each issue is readable, so a builder can send the list back to the model and ask it to correct its output. Chat platforms also limit what fits in one message. Adapters can degrade content beyond those limits: Vercel’s example is Slack converting a second table into a code block. Builders can pass limits to reject specifications that exceed those constraints instead.
Vercel points developers to the json-render API documentation and a playground to get started. The changelog does not state a price, a release date, or a minimum version requirement for the integration.
What the archive adds
New Runtime’s earlier coverage on Vercel MCP deployment cards described live deployment status, logs, commit details, and project switching in interactive cards. This is a new capability, not a restatement: the earlier note concerned deployment visibility through MCP, while this announcement concerns agents generating and streaming UI cards in chat.
Trend signal
This supports the idea that model answers are becoming task interfaces: the model produces a bounded, typed structure that a product renders as an interface, rather than only returning prose. The changelog demonstrates a concrete chat implementation, but does not establish how broadly teams are adopting this design.
Why now
Vercel’s announcement does not explain the timing. It presents the integration as a way to avoid separately building and maintaining tools for different message shapes, while delivering cards in the native formats used by supported chat platforms.
Why it matters
For a team building a chat agent, a typed catalog creates a narrower contract between model output and the user-facing interface. The model can select and fill supported components, while the application retains control over their schemas and how those components render. That can make generated results more useful than a stream of text when the task calls for a table, chart, or button.
The streaming behavior also changes when users see the result: they can receive a card before the model has finished generating every element. But the final experience depends on platform limits and the adapter’s handling of overflow. A second table that becomes a code block may be technically delivered but no longer serve the intended interaction. Builders therefore need to decide whether degraded content is acceptable or whether exceeding limits should fail validation and trigger correction.
This is an implementation option, not evidence that generated cards are automatically accurate or usable. Teams still need to test model output, component behavior, and the result on each target platform. The value is a defined path for composing interfaces in chat, with validation and an explicit choice about platform constraints.
What happens next
- Builders will use explicit limits where degraded cards would change the meaning of an agent’s answer (6 months, 65%). Watch for: examples or documentation showing strict limits used for multi-component cards.
Limits and uncertainty
Vercel’s announcement documents the API flow and its default streaming interval, but does not quantify latency, adoption, reliability, or the frequency of invalid specifications. It does not publish a price or identify a minimum version. The example names Slack and Teams output formats, but the announcement does not give a complete list of supported platforms or describe how every adapter handles every limit. Independent testing would be needed to establish how well models produce valid, useful cards in real deployments.
Skill to build now
Define a small typed catalog for one chat workflow, then test it with realistic prompts that request a table, chart, and action. Check both the streamed intermediate card and the final validated card. Deliberately exceed the target platform’s limits and decide whether to accept adapter degradation or pass limits so the specification is rejected and corrected.
Reader takeaway
Chat SDK and json-render let agents stream typed, validated UI cards into platform-native chat messages. The important design choice is not only which components to expose, but what should happen when a card exceeds the destination platform’s limits.