Generative UI landscape and recommendation for ETS27

Research for the ETS27 site redesign (Energy Thought Summit 2027, Austin, Texas, theme "Free Your Mind"). Prepared 2026-10-13 for Zpryme.

Method. Every statement below about a product, protocol or model was checked against a primary source on 2026-10-13: official documentation, specifications, repositories, release notes, and the npm and GitHub registries. The sources table at the end lists each URL and what it confirmed. Where a primary source could not confirm a claim, the text says so. Version numbers and star counts are readings from that date.

Scope. This document covers the generative UI landscape and the mechanism ETS27 should use. Model selection, prompts, cost and server code for Claude belong to research/claude-wiring.md; the Claude section here stays at the level of mechanism.

Related documents. brief/ETS27-site-brief.md (the idea and the plan), brief/design-direction.md (how components look and arrive), research/claude-wiring.md (models and wiring).

Contents

1. Summary
2. Three ways an agent can express UI
3. The landscape, one by one
4. Comparison table
5. What the owner saw in ChatGPT, and what we will build
6. Recommendation for ETS27
7. Open questions and risks
8. Sources

1. Summary

• The field has converged. The model does not write UI code. It emits a declarative description that names components from an allow-listed catalog, and a trusted renderer turns that description into native interface as it streams. A2UI, json-render, assistant-ui's generative UI, OpenUI Lang and OpenAI's own Intelligent UI all work this way. MCP Apps is the exception: it ships whole HTML apps into sandboxed iframes.
• Versions have moved since the brief was framed. A2UI's production release is v0.9.1, with v1.0 as a release candidate. AG-UI reached a normative 1.0 specification (@ag-ui/core 1.0.0, published 2026-09-17). MCP Apps has a stable spec (2026-01-26) and SDK 2.0. The Vercel AI SDK is on major version 7. Thesys renamed C1 to OpenUI Cloud and Crayon to OpenUI. OpenAI's Apps SDK documentation now lives under "ChatGPT Plugins" and is built on MCP Apps.
• OpenAI's Intelligent UI is ChatGPT-only. Shipped 2026-10-07 with GPT-6 in ChatGPT: the model was trained to compose answers from "a library of native, streamable components" with "a compiler that processes the interface as the model generates it". No developer API exposes it as of 2026-10-13. It is inspiration, not a dependency.
• Open-JSON-UI is a label, not a maintained standard. It is named in CopilotKit and AG-UI documentation and in some third-party projects on GitHub; no OpenAI publication was found, and CopilotKit's Open-JSON-UI page now redirects to its A2UI page.
• Claude gets the same effect through grammar-constrained output. A JSON schema for the whole answer (output_config.format) or per component (strict: true tools) guarantees schema-valid output. One finding shapes the design: on Claude Opus 5.5, Fable 5.1 and (for longer notes) Sonnet 5.5, text the model writes before or between tool calls comes back as progress-update thinking blocks, which are empty by default. The robust adapter is therefore one structured answer, { say, sources, ui[] }, which streams the narration as text and completes each component as a JSON object. That is the shape the site brief already sketches.
• Recommendation. A small custom contract: ten ETS27 components; a flat list of blocks per turn; every fact, image, time, price and link resolved from the site's own data by id; blocks shaped like A2UI component objects; and a wire format that is a subset of AG-UI 1.0 events over server-sent events. Launch stays small, and a later move to AG-UI clients, A2UI renderers or an MCP Apps channel inside ChatGPT and Claude becomes a mapping exercise, not a rewrite.

2. Three ways an agent can express UI

CopilotKit's generative UI guide sorts the field into three patterns, from most control to most freedom. The vocabulary is used throughout this document.

ETS27 sits deliberately between the first two: each turn is a short, flat list of catalog components chosen by the model, rendered by components the site owns.

3. The landscape, one by one

3.1 A2UI (Google)

3.2 AG-UI

3.3 MCP Apps

3.4 Open-JSON-UI

3.5 assistant-ui

3.6 Thesys: C1 is now OpenUI Cloud, Crayon is now OpenUI

3.7 json-render (Vercel Labs)

3.8 Vercel AI SDK

3.9 OpenAI Intelligent UI, and OpenAI's developer surfaces

3.10 Claude: getting the same effect through the API

This section stays at the level of mechanism; research/claude-wiring.md covers model choice, prompts and server code.

• Two grammar-constrained features. JSON outputs (output_config.format with a JSON schema) constrain the whole response; strict tool use (strict: true on a tool) "guarantees Claude's tool inputs match your JSON Schema by constraining the model's token sampling to schema-valid outputs". Both compile the schema into a grammar and are generally available on the Claude API. Grammars apply to the model's direct output, not to its thinking, so the model can still think before answering.
• Adapter A, one structured answer (recommended). The answer is a single JSON document such as { "say": "...", "sources": [...], "ui": [...] }. It arrives as ordinary text deltas, so an incremental parser can forward the say string to the browser character by character and hand over each element of ui the moment its closing brace arrives. Property order follows the schema, with required properties first, so say streams before the components. Because the answer contains no tool calls, the progress-update behavior below does not apply.
• Adapter B, a strict tool per component. Each component is a strict tool whose input_schema is its props. Text streams as text_delta; each component arrives as a tool_use block whose content_block_start names it at once and whose content_block_stop marks a complete object. The tools execute nothing: the client renders them, and the server acknowledges them with tool_result blocks in the next user message. By default the API buffers and validates each tool parameter before streaming it; eager_input_streaming: true streams fragments immediately but "does not buffer or validate", so the client must validate.
• The finding that decides between them. On Claude Opus 5.5 and Fable 5.1, text the model writes between tool calls comes back as progress-update thinking blocks, "at most one before each tool call", empty at the default display; Anthropic's prompting guide treats "a one-line statement of intent before the first tool call" as one of these updates. On Sonnet 5.5, notes "longer than a sentence or two" are converted the same way and shorter remarks stay text. display: "updates" (beta) returns only a summary of each note, not its verbatim text. Narration written in front of component tool calls can therefore disappear on these models. Claude Haiku 5.5 is not on the list of models that emit progress updates. Adapter A sidesteps the question on every model.
• Limits that shape the catalog. Not supported: recursive schemas, numeric and string-length constraints, array constraints beyond minItems of 0 or 1, and additionalProperties other than false. Supported: enum, const, anyOf and allOf (with limits) and internal $ref. Per request: at most 20 strict tools, 24 optional parameters and 16 union-typed parameters across all strict schemas, plus internal limits on compiled grammar size ("Schema is too complex for compilation"). Grammars compile on first use and are cached for 24 hours from last use; changing a schema or the tool set invalidates them, and changing output_config.format invalidates the prompt cache for that conversation.
• Tool choice. Forced tool_choice (any or tool) returns a 400 on Claude Opus 5.5, Sonnet 5.5 and Fable 5.1; the documented replacement is auto with strict tools and prompting, or structured outputs.
• Models. Structured outputs list Claude Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5 among supported models on the Claude API. Claude Haiku 5.5 (claude-haiku-5-5) was released 2026-10-07, is described as "for high-volume, latency-sensitive tasks" and is the fastest model in the current lineup; it is worth a latency trial in the wiring work. Availability of structured outputs differs on some cloud platforms, so use the Claude API directly.

4. Comparison table

5. What the owner saw in ChatGPT, and what we will build

In ChatGPT, the owner saw GPT-6 answer with live interface instead of paragraphs: a bicycle diagram whose systems can be tapped, a roast plan with a guest-count stepper, a bill splitter built on request. OpenAI did this by training the model on its own library of native, streamable components and adding a compiler that renders the interface while the model is still generating. It lives inside ChatGPT, it can invent small tools on the fly, and no developer can call it. ETS27 will reproduce the feeling, not the machinery. A Claude concierge composes each answer from ten ETS27 components (speakers, agenda, sessions, venue, tickets, partners and a few more), our incremental parser plays the role of OpenAI's compiler, every fact inside a component comes from the summit's own data, and the visual language is the ETS27 realm (white, open space, mono notation) rather than a chat skin. The model decides what to show and in what order; it never writes interface code, never invents a speaker or a price, and cannot build arbitrary mini-apps the way ChatGPT can. That narrower scope is the point: a public event site needs answers that are fast, on brand and correct, and every generated view has an ordinary page behind it.

6. Recommendation for ETS27

6.1 Mechanism

A constrained declarative UI built from a fixed catalog.

1. ETS27 owns a catalog of ten components, designed once in the site's design system (brief/design-direction.md section 4.5 describes how each one arrives).
2. Each turn the model returns one structured answer, { say, sources, ui }: a short narration, the pages its facts came from, and zero to four component blocks in display order. Blocks form a flat list with no nesting, which keeps the schema non-recursive and the renderer trivial.
3. The model chooses only what to show: record ids, filters and a short heading. The site supplies every fact, image, time, room, price and link.
4. The answer is grammar-constrained (adapter A in section 3.10), so it is schema-valid by construction; the server still validates every block and drops unknown ids.
5. One engine serves both routes. The interactive route places blocks in the open realm; the standard route's dock renders the same blocks into page slots, with the current page sent as context.

6.2 The catalog

Ten components, reconciled with the eleven in the design direction and the first cut in the site brief. Every prop is required, ids are enums generated from the site's data at build time, and length limits that grammars cannot express are enforced by validation and truncation.

The envelope carries two more fields. say is the narration, rendered with the design direction's TextAnswer styling as plain text. sources is an array of page ids rendered as the mono source line the design direction requires for factual answers, so a source never has to be a model-written URL.

Not in the catalog on purpose: generic layout primitives (Row, Column, Text), free-text cards, images by URL, and forms other than the site's contact form. Candidates for a second phase: Gallery (past-summit photos by collection id), MyAgenda (a personal schedule the visitor confirms and saves), and Countdown.

Budget against Claude's limits (adapter A): one union-typed parameter (the ui item union; limit 16), no optional parameters (limit 24), no recursion. Adapter B would need ten strict tools (limit 20), also with no optional parameters. Large id enums still count toward the internal grammar size limit, which needs a test with the real speaker and session counts (section 7).

Schema sketch for adapter A, showing two of the ten components:

{
  "type": "object",
  "properties": {
    "say": { "type": "string", "description": "One to three conversational sentences. Facts belong in components." },
    "sources": { "type": "array", "items": { "$ref": "#/$defs/PageId" } },
    "ui": {
      "type": "array",
      "description": "Zero to four ETS27 components in display order.",
      "items": { "anyOf": [ { "$ref": "#/$defs/AgendaDay" }, { "$ref": "#/$defs/SpeakerGrid" } ] }
    }
  },
  "required": ["say", "sources", "ui"],
  "additionalProperties": false,
  "$defs": {
    "PageId": { "type": "string", "enum": ["lineup", "agenda", "venue", "partners", "gallery", "about", "contact", "register"] },
    "SpeakerId": { "type": "string", "enum": ["<speaker slugs from the site snapshot>"] },
    "AgendaDay": {
      "type": "object",
      "properties": {
        "component": { "const": "AgendaDay" },
        "day": { "type": "string", "enum": ["<day ids from the site snapshot>"] },
        "trackIds": { "type": "array", "items": { "type": "string", "enum": ["<track ids>"] } },
        "speakerIds": { "type": "array", "items": { "$ref": "#/$defs/SpeakerId" } },
        "heading": { "type": "string" }
      },
      "required": ["component", "day", "trackIds", "speakerIds", "heading"],
      "additionalProperties": false
    },
    "SpeakerGrid": {
      "type": "object",
      "properties": {
        "component": { "const": "SpeakerGrid" },
        "heading": { "type": "string" },
        "speakerIds": { "type": "array", "minItems": 1, "items": { "$ref": "#/$defs/SpeakerId" } },
        "groupBy": { "type": "string", "enum": ["none", "day", "track", "organization"] }
      },
      "required": ["component", "heading", "speakerIds", "groupBy"],
      "additionalProperties": false
    }
  }
}

component comes first in every block, so the parser knows which skeleton to show before the props arrive. The server adds a block id; the model never generates ids for blocks.

6.3 Protocol decision: adopt a standard, or a small custom contract?

The contract:

• Blocks are { "id", "component", ...props }, the A2UI component object without children. One assistant turn is one surface.
• The wire is a subset of AG-UI 1.0 events over SSE: RUN_STARTED; TEXT_MESSAGE_START, TEXT_MESSAGE_CONTENT and TEXT_MESSAGE_END for say; ACTIVITY_SNAPSHOT for each block (activity messages are AG-UI's slot for structured widgets the UI renders, and CopilotKit already carries A2UI surfaces this way); RUN_FINISHED or RUN_ERROR.
• The run input mirrors AG-UI's: threadId, runId, the new user message, and context (the current page and the route). The conversation itself is held server-side.

Migration path:

1. Launch. The custom contract with our own renderer (web components or React islands, whichever the front end uses).
2. A React chat shell later, if wanted. The server already speaks AG-UI event names, so CopilotKit, assistant-ui or an AG-UI client can consume it; adapter B maps directly onto their frontend tools and onto AI SDK tool parts.
3. A2UI export once v1.0 is final. Each turn becomes a surface; each block becomes a child of a root Column under a published symbolic catalog id such as https://energythoughtsummit.com/a2ui/ets27/v1. Any A2UI renderer could then display ETS27 answers.
4. A channel inside ChatGPT and Claude. An ETS27 MCP server (agenda search, speaker lookup, venue facts) whose ui:// views reuse the same renderer bundle, so attendees can ask about ETS27 where they already chat.

6.4 Streaming strategy

Text streams token by token; a component appears as a skeleton when it starts and materializes when its JSON object completes and passes validation.

Example of what the browser receives:

data: {"type":"RUN_STARTED","threadId":"t-42","runId":"r-7"}
data: {"type":"TEXT_MESSAGE_START","messageId":"m-7","role":"assistant"}
data: {"type":"TEXT_MESSAGE_CONTENT","messageId":"m-7","delta":"Day two has three sessions on grid security."}
data: {"type":"TEXT_MESSAGE_END","messageId":"m-7"}
data: {"type":"ACTIVITY_SNAPSHOT","messageId":"b-7-1","activityType":"ets27.AgendaDay","content":{"status":"pending"}}
data: {"type":"ACTIVITY_SNAPSHOT","messageId":"b-7-1","activityType":"ets27.AgendaDay","content":{"status":"ready","block":{"id":"b-7-1","component":"AgendaDay","day":"day-2","trackIds":["security"],"speakerIds":[],"heading":"Grid security, day two"}}}
data: {"type":"RUN_FINISHED","threadId":"t-42","runId":"r-7"}

Rules:

• The server forwards only validated, resolved blocks; the browser never parses model JSON. The browser validates again before rendering, as defense in depth.
• With adapter B the mapping is the same, except that content_block_start of a tool_use block opens the skeleton and content_block_stop completes it. Keep buffered tool streaming (the default) unless a list should fill progressively.
• A turn ends after its blocks; follow-ups come from Choices, so no second model call is needed to add trailing text.

6.5 Safety rules

1. The model emits data, never markup. No HTML, JavaScript, CSS, URLs or image sources from the model. say and headings render as plain text; links, images and HTML in model text are stripped.
2. Allow-list only. Only the ten catalog components can appear; the grammar makes anything else unproducible, and the server drops it if it appears.
3. Ids resolve against the site's own data. Names, bios, titles, portraits, times, rooms, prices and URLs all come from the snapshot; the model chooses ids, filters and short headings. Unknown or stale ids are dropped and logged, never rendered.
4. Enums at build time, validation at run time. Ids are enums generated from the snapshot, and every block is still validated against the catalog schema on the server and in the browser.
5. Bounded output. At most four blocks per turn, headings truncated at 60 characters, at most four chips, a sensible max_tokens, and graceful handling of the refusal and max_tokens stop reasons.
6. No side effects without a click. Registration, calendar export and the contact form are buttons the visitor presses; the model cannot trigger them, and their targets are fixed URLs and endpoints from data.
7. Server-held, append-only history. The browser sends the new message, the page and the route; the server keeps the thread by threadId with a short lifetime. This blocks forged history, keeps the cached prefix stable, and matches Claude's requirement on current models that conversations replayed with thinking blocks stay append-only.
8. Public-endpoint hygiene. No secrets in prompts or state, per-visitor rate limits, bot protection at the edge, no transcripts kept with identifiers, and the contact form posting to the site's own endpoint rather than through the model.
9. Every block has a page behind it. Each component links to its standard-route equivalent, so nothing is reachable only through conversation.

6.6 Accessibility of generated UI

1. Accessibility is designed per component, once. Blocks are real, semantic components from the design system (headings, lists, tables, buttons), not generated markup, so every answer inherits tested structure.
2. Announce outcomes, not tokens. The narration region uses aria-live="polite" with aria-busy="true" while it streams, so screen readers hear the finished sentence rather than every fragment. Each materialized block is announced by a short summary, such as "Showing 3 sessions for day two". Focus never moves on its own; a "skip to latest answer" control is always available.
3. Keyboard first. The fork, the composer, every chip and every block control are reachable and operable by keyboard; Escape closes the dock.
4. Motion and contrast. Materialization animations respect prefers-reduced-motion. The white realm needs contrast checks (4.5:1 for body text); light gray on white is the usual failure.
5. Text alternatives from data. Alt text for portraits and venue images comes from the snapshot, never from the model. The head and clouds are decorative, with a text equivalent for the opening.
6. The standard route is the accessible baseline. Everything in the interactive route also exists as an ordinary server-rendered page, a persistent control switches routes, and visitors without JavaScript or WebGL get the standard route.
7. Headings are the renderer's job. The renderer sets heading levels relative to the container; the model never chooses them.

6.7 Caching and latency

1. Prompt caching. Keep the prefix stable and first: the system prompt with the persona, the catalog description and the site snapshot. The conversation follows. Confirm hits with usage.cache_read_input_tokens. Changing output_config.format or the tool set invalidates the cache for a conversation, so version the schema per deploy.
2. Grammar compilation. The first request with a new schema pays a compile delay; compiled grammars stay cached for 24 hours from last use. Warm them with a throwaway request at deploy, and regenerate schemas only when the snapshot's ids change.
3. One model call per turn. Ground answers in the cached snapshot instead of retrieval tools, and let Choices carry the follow-ups, so a typical turn needs no tool round trip.
4. Perceived latency. Narration streams first; skeletons appear the moment a component name is parsed; components complete one by one.
5. Static data at the edge. The snapshot is served from the CDN and the renderer resolves ids locally, so a block needs no extra fetch; images are pre-sized.
6. A fast path for the opening chips. The first-state chips ("Who's speaking?", "Where is it?", "Tickets") can be answered from precomputed { say, sources, ui } documents with no model call; the model handles the long tail.
7. Model and effort are the wiring document's call. Current Claude models think adaptively, and effort sets how much; keep it low for concierge turns. If Claude Haiku 5.5 is trialed, note that its price steps up for prompts over 100,000 tokens, so keep the cached prefix and conversation under that size.

6.8 One engine, two routes

Both routes call the same endpoint with the same catalog and the same snapshot. The run input's context carries the route and the current page. The interactive route renders blocks into the open realm and keeps earlier blocks as receding history. The standard route's dock renders the same blocks into page slots, scrolls to the related section, and prefers Choices links into the page structure. Only the renderer's placement logic differs.

7. Open questions and risks

1. Progress-update behavior. Documented on Opus 5.5, Fable 5.1 and Sonnet 5.5 for text before or between tool calls. Adapter A avoids it; if adapter B is ever chosen, test on the exact model whether pre-tool narration arrives as text.
2. Grammar size with real id enums. Test the full schema with the real speaker, session and track counts against the "Schema is too complex for compilation" limit. The fallback is plain string ids with server-side resolution and the drop rule.
3. Clean data. The WordPress REST content for speakers carries WPBakery shortcodes inside content.rendered; the snapshot needs stable slugs, days, tracks, rooms and ticket tiers (see the data-model research).
4. ETS27 facts. Dates, tracks and tiers are unknown, so the enums are generated from data and stay empty or placeholder until the lineup exists.
5. Front-end stack. React favors json-render, assistant-ui or AI SDK hooks for the renderer and dock; plain web components keep WordPress-style islands possible. The contract is neutral either way.
6. Standards still moving. A2UI v1.0 has no final date and AG-UI's draft continues past 1.0; the custom contract absorbs both.
7. Intelligent UI may gain an API later. Nothing to wait for; revisit if OpenAI ships one.

8. Sources

All accessed 2026-10-13.

Addendum, 2026-10-20: a one-week refresh, and the question of ecosystems

Checked again on 2026-10-20 against the same kinds of sources (project sites, repositories, package registries, the vendors' own announcements). Nothing in sections 3 to 6 changes.

• By vendor. Google: A2UI, the open protocol (v0.9.1 in production, v1.0 still a release candidate; the project published new a2ui-adk and a2ui-a2a packages on 2026-10-17), plus the closed generative UI inside the Gemini app. OpenAI: Intelligent UI inside ChatGPT (GPT-6, 2026-10-07), still with no developer API; the developer routes remain ChatGPT plugins (MCP Apps iframes) and ChatKit widgets. Anthropic: MCP Apps (the open specification co-authored with OpenAI, stable since 2026-01-26, interactive apps inside Claude's clients) and, on the API, grammar-constrained structured outputs, which is how ETS27 gets a catalog-valid answer from Claude (section 3.10). Vendor-neutral: AG-UI 1.0, json-render, OpenUI and OpenUI Lang, the Vercel AI SDK, assistant-ui.
• Two open-source recreations of Intelligent UI appeared. CopilotKit's OpenIntelligentUI (MIT; Next.js and CopilotKit in front, a Python agent behind, AG-UI as the wire, A2UI for basic tables, its own "Open Generative UI" for charts, diagrams, calculators and maps, and sandboxed HTML streamed into an iframe for bespoke tools; OpenAI models by default) and Thesys's open-intelligent-ui (MIT; the model streams OpenUI Lang 1.0 and a primitive library renders maps, charts, drawings, forms and sandboxed pages; OpenUI Cloud or any OpenAI-compatible endpoint, Node 24). Both are references for the feel ETS27 wants; neither targets Claude out of the box and both carry far more surface than a summit site needs. They confirm the pattern chosen in section 6: a catalog, a declarative stream, a trusted renderer.
• Nothing to adopt yet. The custom contract stands. Re-check when A2UI v1.0 is final, when OpenAI exposes Intelligent UI to developers, or when the build round picks the front-end stack.

2026-10-21: the thesis, as YC framed it

Y Combinator's Summer 2026 request for startups "Dynamic Software Interfaces" (Ankit Gupta) states the same thesis at the scale of all software: before AI every user got the same interface; now "software companies will ship these shared primitives with full intention that users will heavily modify the final interfaces", with each user's coding agent as their own forward-deployed engineer. ETS27 is that idea with the agent on the site's side: the site ships the primitives (the catalog of section 6) and its own mind composes the interface per visitor; the facts stay static, the composition does not. The verbatim text, its provenance (the live YC page has since moved on to the Fall 2026 edition) and the reading for the studio are in design/inspiration/yc-rfs-dynamic-software-interfaces.md.