Contextual Generative Experience

In November 2025, Anthropic and OpenAI put an interactive user interface extension into the Model Context Protocol. A month later, on December 15, Google open sourced A2UI, a protocol whose entire purpose is to let an agent describe a user interface that a client then renders natively. Two of the three largest model providers, plus the protocol layer sitting between all of them, arrived at the same conclusion within thirty days of each other: text is not enough. The model has to be able to hand back structure.

That convergence is the tell. When separate teams with different incentives ship the same primitive in the same quarter, they are not copying each other. They are all hitting the same wall.

The wall is this. We spent thirty years teaching software to render screens that a product team drew in advance, and then we handed those screens an intelligence layer whose defining property is that it can respond to situations nobody drew in advance. The mismatch is not cosmetic. It is structural, and it shows up as the thing every AI product person has quietly noticed: the model is smarter than the interface it is trapped in.

I want to give the way out a name, because naming it makes it possible to argue about. Contextual Generative Experience, or CGX, is the idea that the interface should be generated for the moment, assembled from structured building blocks, grounded in real data, and rendered as a coherent visual experience, rather than selected from a catalog of fixed screens.

CGX is not the model drawing a random page. It is a disciplined architecture: the model expresses intent as a stream of typed components, and the client renders those components with a design system it owns.

This piece is the long version of that argument: why fixed UI breaks down, what CGX actually is, how the architecture fits together, where the industry already is, and which parts are still genuinely unsolved.

Traditional product UI assumes a bounded task graph. There is a home, a list, a detail, a form. Navigation is a tree. Features ship as new branches on that tree. This model works, and works well, when the problem space is fixed. A settings page, a checkout flow, a dashboard of known metrics. Product teams design the screens, engineers implement them, designers polish them, and users learn where everything lives. The learning is a one-time cost that pays off across thousands of repetitions.

Knowledge work is not a tree. It is a graph of situations, and the difference matters in four specific ways.

Different roles read the same data differently. One customer conversation can mean churn risk to customer success, a buying signal to sales, and product feedback to engineering. A single static account page cannot be equally right for all three without degenerating into a dump of every field, which is what most account pages actually are.

Different moments demand different structure from the same role. Monday morning prioritization looks nothing like Friday's deal desk package. The same person needs a different shape depending on time pressure, audience, and goal. The product has one page for both.

The useful layouts are combinatorial, not enumerable. Metrics, risks, stakeholders, history, recommended next steps, comparison matrices, charts, timelines. These are not a fixed set of screens. They are compositions, and the number of good compositions grows multiplicatively while the number of screens a team can ship grows linearly.

Context has a shelf life. By the time a user has clicked through six tabs to assemble the picture, the meeting has started. The interface that wins is not the one with the most features. It is the one that arrives already composed.

A sales leader does not open an app to use a feature. They open it because a deal is wobbling, a champion left, a renewal is six weeks out, or an executive needs a brief in twenty minutes. The shape of the useful answer depends on the account, the moment, the role of the person asking, and what happened yesterday. No product team can pre-draw every useful combination of those variables. Trying produces one of two failure modes: sprawling menus, or shallow templates that ignore the actual situation.

Static UI optimizes for predictability and QA. Contextual work optimizes for something else entirely, which I would call relevance density: the highest-signal layout for this user, this question, this data, right now.

Markdown chat was a step sideways, not forward. Dumping paragraphs into a chat panel is flexible, but flexibility is not the same as a product experience. Users still have to parse prose, hunt for the number that matters, and copy fragments into slides. Generative text without generative structure just relocates the cognitive load onto the human and calls it a feature. CGX closes that gap: the model produces structure, the product produces craft.

CGX is a protocol between intelligence and presentation.

An AI system, whether that is a chat surface, an agent, a skill, or a batch job, does not emit free-form HTML or a wall of markdown. It emits a stream of typed components: cards, KPIs, tables, timelines, charts, graphs, sections, tabs, actions, as structured data. The application owns a component registry and a design system. It maps each typed token into a real, interactive, visually consistent element.

Three layers, with a clean ownership line between each:

The ownership line is the whole design. Everything that is judgment sits above it. Everything that is craft sits below it. The model never touches a pixel, and the design system never has to guess what matters.

Four things CGX is deliberately not:

• Not unconstrained HTML generation. Letting a model invent CSS and DOM at runtime is brittle, insecure, and visually chaotic. CGX constrains output to known primitives so every surface is reviewable, themeable, and accessible. This is the single most important constraint, and it is the one people are most tempted to relax.
• Not a replacement for all product UI. Settings, auth, admin, and durable workflows still deserve handcrafted screens. CGX earns its keep where content and layout are situational, and nowhere else.
• Not personalization of chrome. Changing a color based on a preference is theming. Rebuilding the flow and composition of a working view is CGX. The two get conflated constantly, usually by people selling the former.
• Not a design-time mock. Generation is runtime, streaming, and data-bound. An AI that designed a page once, which then froze into a static template, is a productivity tool for designers. That is valuable, and it is a different thing.

The case for CGX is not aesthetic. It is a set of specific jobs that fixed UI does badly and generated UI does well.

Flows assemble around the work. People do not follow product tours, they follow problems. One session might need a four-KPI health strip, a qualification matrix, a timeline of the last five events, and two recommended actions with stated causes. The next session might need a stakeholder graph and a short deck for an executive. CGX lets the flow assemble itself around the task instead of forcing the task into a generic wizard.

Context is multi-dimensional, and generation can condition on all of it. Role and function, because what healthy means differs by team vocabulary. Entity focus, because this account is not that account. Temporal urgency, because a renewal in six weeks is not early discovery. Channel of entry, because a natural-language question, a saved lens, an agent push, and a scheduled brief are four different postures. Evidence available, because missing data should render as an honest gap, not as silence. A CGX system conditions on all of these, so two users never see the same generic shell filled with slightly different numbers.

Generated does not have to mean ugly. This is the objection I hear most, and it is a reasonable prior given what unconstrained generation looks like. But because the client renders known components, CGX inherits consistent typography and spacing, color semantics for pass and partial and fail, motion and progressive reveal as tokens stream in, responsive grids and tabs and expandable sections, real interactive controls, and accessibility baselines that free-form HTML generation almost never meets. The model chooses which components and what content. The design system decides how good those components look and feel. Those are separable problems, and separating them is what makes quality achievable.

Density without overload. A well-composed CGX view uses hierarchy deliberately: a title, section headers, a grid of metrics for orientation, then depth in the form of comparison tables, timelines, quotes. Users scan the structure the way they scan a well-designed dashboard. The only difference is that the composition was not hardcoded for this exact report three sprints ago.

Surfaces that act, not summaries that sit there. Static AI summaries end at text. CGX components can carry actions: draft the outreach, open the comparison brief, activate the champion play. Each action can carry a specific cause string, so the user and the audit trail both know why the button appeared. That single detail changes the character of the thing. Generation stops being a monologue and becomes a working surface.

Iteration speed. Shipping a new deal room, QBR pack, or risk inbox traditionally means design, frontend, API contracts, and edge cases. Under CGX, many of those experiences become prompt, skill, and component vocabulary work. The durable investment is the component library and the schema. The long tail of situational UI is generated.

Trust is a structural property. Users trust interfaces that look intentional and that show evidence. Typed components push toward explicit KPIs instead of buried numbers, status-coded cells instead of vague adjectives, verbatim quotes instead of paraphrased vibes, and honest empty states when data is missing. Structure is not only an aesthetic feature. It is a trust feature.

It would be easy to read all of the above as a thought experiment. It is not. The plumbing is being laid right now, by the people with the most to gain from owning it, and the shape of what they are shipping validates the architecture more than any argument I could make.

Four data points from the last eighteen months:

• MCP Apps (SEP-1865). Proposed in November 2025 by Anthropic and OpenAI together, and landed as an official MCP extension with a specification dated January 26, 2026. The approach is web-centric: interactive UI delivered through sandboxed iframes with restricted permissions. Notably, it is a joint proposal from two companies that compete on almost everything else.
• Google A2UI. Open sourced December 15, 2025. Explicitly described as a declarative data format, not executable code. Agents send a component tree and its data model, and clients map that to native widgets across Flutter, React, Web Components, and SwiftUI. The payload is a flat list of components with ID references, chosen specifically because that shape is easy for a model to generate incrementally, which enables progressive rendering. Streaming happens as JSONL.
• AG-UI. An event-based protocol out of CopilotKit's work with LangGraph and CrewAI, standardizing the connection between agent backends and user-facing applications: token streaming, tool calls, state synchronization, human-in-the-loop interrupts, cancel and resume. A2UI shipped with day-zero AG-UI compatibility, and AWS has documented running AG-UI generative interfaces on Bedrock AgentCore.
• The product layer. Vercel shipped generative UI in AI SDK 3.0, streaming React components from model output. Thesys launched C1 in April 2025 as a generative UI API. Microsoft has been shipping Adaptive Cards, a declarative JSON UI schema rendered natively per host, since well before any of this. That last one matters most: Adaptive Cards proves the core pattern is not novel. What is novel is having a generator smart enough to compose them well.

Read those together and the architecture is not in dispute. Every one of these systems separates a declarative, typed description of the interface from a client-side renderer that owns the pixels. Every one of them streams incrementally so the surface can paint before the payload is complete. Every one of them refuses to let the model ship executable code, either by sandboxing it or by forbidding it outright.

What is in dispute is the boundary. Google's bet is native-first, which travels to mobile and desktop and web at once. The Anthropic and OpenAI bet is web-first through a sandbox, which is simpler and meets most agents where they already live. That disagreement is a genuine architectural fork, and it will get resolved the way these things always get resolved, which is by whichever side accumulates more surfaces.

The protocols are converging on the transport and diverging on the boundary. That is exactly what the early phase of a standards war looks like.

None of these protocols solve the thing I actually care about, which is the layer above them. A wire format tells you how to send a card. It does not tell you which cards a churn-risk review needs, in what order, with what evidence, for a customer success manager on a Monday. That judgment is the product. The protocols are the road, and roads are necessary, but nobody has ever been moved by a road.

Constrain the output surface. The model should not invent new widget types on the fly. A finite, versioned vocabulary of primitives keeps rendering safe and quality high. Expand the vocabulary deliberately, when a new interaction pattern has proven itself, and never as a workaround for a prompt that will not behave.

Stream early, complete late. Newline-delimited JSON, one object per line, lets the UI paint as tokens arrive. Users see a title and a first KPI within a second, and the denser sections fill in behind it. Waiting for a complete multi-kilobyte document before first paint feels like a black box, and users treat black boxes as broken. This is not a performance optimization. It is a trust mechanism.

Separate containers from leaves. Containers establish layout: report, section, grid, tabs. Leaves present content: KPI, card, list, table, chart, graph, alert, quote, progress. Rich primitives package complex, purpose-built layouts such as a brief, a comparison, or a deck as a single high-value token, once the pattern is well understood. Explicit open and close tokens keep nesting parseable under partial streams, which matters more than it sounds like it should.

Prefer composition over mega-widgets. A grid of KPIs plus a card plus an accordion list is more flexible than one opaque smart panel that only the model knows how to fill correctly. Composition also maps cleanly onto how design systems are already built.

Ground every claim. Numbers, quotes, and statuses come from retrieved context, not from model invention. Prompts and runtime checks should treat fabrication as a defect with a severity, not as a known limitation to be disclaimed. Citations and cause strings make provenance a first-class part of the payload.

Design for progressive disclosure. Tabs, accordions, and sections keep a generated view scannable at the top and deep on demand. The default failure of generation is flattening everything into one endless scroll, because a model has no natural sense of when to stop.

Make failure modes first-class. Malformed lines, unknown types, and partial closes will happen. The runtime skips or degrades gracefully and never crashes the shell. Observability on parse errors is part of the product, not part of the backlog.

Keep humans in the loop for side effects. Generated views can be automatic. Generated writes and external actions should still require explicit intent or approval when the stakes are real. CGX is a presentation and decision surface. It is not a license for silent mutation.

At a high level, CGX is a pipeline with six stages.

user intent, role, entity
        |
        v
context assembly
memory, retrieval, tools
        |
        v
generation
model or skill, emits tokens
        |
        v
stream parse and validate
        |
        v
component registry
plus design system
        |
        v
interactive UI, with actions

Context assembly

Before generation, the system gathers what the model is allowed to know: entity payloads for the account or deal or ticket or project, role and lens instructions that carry the vocabulary and the definition of good, retrieved episodes and signals and metrics and citations, user preferences and session state, and tool results from the CRM, calendar, mail, or analytics.

Context quality bounds UI quality, and there is no prompt that fixes a missing input. CGX cannot invent a trustworthy stakeholder map without relationship data. It can only invent an untrustworthy one, which is worse than rendering nothing.

Generation policy

A skill or system prompt specifies that output must be CGX tokens rather than markdown or HTML, which components are preferred for this task, the grounding rules, the length and density budgets, and the action schemas when buttons are allowed at all. The model is a layout planner and a content filler. It is not a free-form designer, and the prompt should make that unmistakable.

Wire format

A practical CGX line is a JSON object with a type field, commonly t:

{"t":"kpi","v":"$1.8M","l":"ARR at stake",
 "trend":"down"}
{"t":"card","title":"Top risk",
 "badge":"red:Urgent",
 "body":"Champion left Apr 2. No internal
 advocate identified."}

Containers nest with explicit closers, which is what makes a half-arrived stream parseable:

{"t":"section","title":"Deal health"}
{"t":"grid","cols":3}
{"t":"kpi","v":"$1.8M","l":"ARR at stake"}
{"t":"kpi","v":"6 wk","l":"To renewal",
 "trend":"down"}
{"t":"kpi","v":"67","l":"Health score",
 "trend":"down"}
{"t":"/grid"}
{"t":"/section"}

Rich primitives compress complex layouts into a single validated object once the pattern is stable: a full narrative brief, a comparison matrix, a chart, a relationship graph, a slide deck.

Stream parser and schema validation

The client, or a backend-for-frontend, maintains a stack of open containers and validates each line against the schema for its type. Valid leaves append to the current container. Open and close tokens push and pop layout frames. Unknown types and invalid JSON get recorded as metrics rather than swallowed. Trivial repairs, such as a trailing comma or a known alias, can be applied carefully, or rejected on principle, but that is a decision to make explicitly rather than discover in production.

Validation is the difference between a production system and a demo. It is also the least interesting part to build, which is why it is usually the part that is missing.

Component registry

Each type value maps to a React component, or the equivalent, with typed props, visual variants for status and size and badges, empty and loading substates, accessibility roles and keyboard behavior, and optional action handlers. Unknown types render as a safe fallback or are omitted entirely. Raw JSON never reaches the screen on the happy path.

Design system coupling

CGX is only ever as good as the primitives underneath it. Spacing scales, type ramps, semantic colors, elevation, and motion tokens live in the design system, not in model output. The model may say the badge is urgent and red. The design system decides what urgent red means in light theme and in dark.

Action bus

When a component carries actions, clicks go through a controlled path. The user confirms or clicks. The action id, the cause, and the target are logged. Downstream handlers, whether that is drafting an email, creating a task, or opening a nested generation, run with full auditability. This keeps generative UI wired into product workflows without ever giving the model direct write access to external systems.

Observability and evaluation

Production CGX needs parse success rates with an error taxonomy, time to first component and time to complete, human preference ratings against a markdown baseline, grounding checks on entity IDs and numeric consistency, and per-persona template audits that answer whether each role is actually getting useful compositions. Without evaluation, generative UI drifts into pretty nonsense, and pretty nonsense is harder to detect than ugly nonsense.

Take a question a real person actually asks: what is going on with this renewal, and what should I do this week?

Context assembly pulls ARR, the renewal date, recent calls, stakeholder changes, and qualification gaps.

Generation then streams, roughly in this order:

• A report shell with a title and a subtitle carrying the last-updated time.
• A deal health section: a three-column grid of KPIs covering ARR at stake, weeks to renewal, and health score.
• A comparison matrix of qualification dimensions with pass, partial, and fail statuses, each cell carrying a short piece of evidence rather than an adjective.
• A timeline of recent material events.
• An accordion of risks, each with a summary, a body, and an action button whose cause names the specific trigger, for example that the champion left on April 2 and adoption dropped eighteen percent.

As lines arrive, the view grows from skeleton, to orientation metrics, to depth, to decisions. The user never navigated a settings menu to enable a deal room. The deal room appeared because the situation called for it.

Situational software density, without situational software engineering for every case.

Certain compositions recur often enough to deserve names, because a named pattern is a thing a prompt can ask for.

Prompts should name the pattern. Models do measurably better when asked for a three-column health grid followed by a top risk card than when asked for a nice UI. Vague instructions produce vague layouts, which is the same failure mode as vague instructions producing vague prose, and we already learned that lesson once.

I would not write any of this if I thought it were solved. It is not, and the unsolved parts are worth stating plainly.

Latency against completeness. Streaming helps, but a large nested report still takes real time. The mitigation is to be deliberate about order: paint the frame and the KPIs first, let the heavy charts land later. That is a generation-policy decision, not a rendering one.

Consistency against novelty. Too much freedom and every view feels random, which destroys the muscle memory that makes software fast to use. Too little and you are back to templates with extra steps. Versioned component vocabularies and skill-level layout recipes are the tool for striking that balance, and getting it right is closer to editorial judgment than to engineering.

Hallucinated structure. This is the one that should keep people up at night. A model can invent a metric that looks entirely real inside a KPI chip, and a KPI chip is a high-credibility container. The mitigations are retrieval-first context, schema constraints, post-validation against source data, and visual treatment that distinguishes cited content from inferred content. A confident number in a beautiful component is more dangerous than the same number in a paragraph, precisely because the component earned trust the number did not.

Accessibility and internationalization. Registry components have to own accessibility, because generation will not. Visual-only meaning without a text equivalent is an easy thing for a model to emit. Locale-aware formatting belongs in the client rather than in model-emitted strings, wherever that is achievable.

Security. Never execute model-produced scripts. Treat CGX as data, sanitize strings, and scope every action server-side. Note that this is exactly the boundary MCP Apps enforces with sandboxed iframes and A2UI enforces by refusing to carry executable code at all. When two competing protocols independently draw the same line, the line is load-bearing.

QA surface area. You cannot screenshot every possible composition, which means the traditional visual QA process does not survive contact with this architecture. What replaces it is component-level visual tests, schema fuzzing, golden fixtures of recorded streams, and persona-based audit suites. That is a real investment, and it is the investment most teams will underfund.

When not to use CGX at all. High-frequency, muscle-memory workflows, such as inbox triage with hotkeys or pure data entry, want stable chrome and should keep it. Use CGX where the value of composition exceeds the cost of navigation. That is a narrower set of surfaces than the enthusiasm around generative UI would suggest, and being honest about the boundary is what makes the claim credible everywhere else.

The architectural argument has an organizational consequence, and I think the organizational consequence is the more interesting half.

Designers shift from drawing every screen to defining the primitive language and the quality bar: what a KPI means, how status colors behave, how dense a card is allowed to be, how an action presents itself. This is a move from artifact production to system authorship, and it is a promotion, though it will not feel like one on the first day.

Engineers shift from an ever-growing set of page routes to a renderer, a schema, and an action bus that have to be genuinely excellent, plus the instrumentation to know when they are not. Fewer surfaces, much higher stakes per surface.

Domain experts and prompt authors become layout authors. They encode how a particular function thinks into skills that emit CGX for that function's moments. This is a new role, and most organizations do not have a name for it yet.

Users stop learning a sprawling information architecture and start asking for outcomes. The interface meets them halfway.

That division of labor is the actual unlock. Static product teams cannot staff every situational UI, and no amount of headcount changes that, because the situations grow combinatorially and the team grows linearly. CGX converts situational UI from an engineering problem into a content and intelligence problem sitting on top of a stable presentation kernel. The kernel is finite and can be made excellent. The content on top of it is unbounded and does not need to be engineered.

The durable investment is the vocabulary. Everything above it is generated, and everything generated is cheap.

CGX is early, and the direction of travel is legible enough to name:

• Tighter grounding loops. Components that refuse to render an uncited claim, rather than components that render it with a disclaimer.
• User-editable generation. Pin one section, regenerate another, promote a layout into a saved lens. The generated view becomes a starting point rather than a final answer.
• Multi-turn compositional editing. Swap the matrix for a chart, treated as a structural edit rather than a full rewrite.
• Cross-surface continuity. The same CGX brief rendered in-product, in an email digest, and as a slide export, from one payload.
• Evaluation as a product feature. Teams measuring which compositions drive completed actions, not which model scores best on a benchmark that has nothing to do with their users.

The destination is not an app with infinite pages. It is an app with a finite, excellent language of components, and an intelligence layer that speaks that language fluently under real context.

Software interfaces were built for a world where the product team could foresee the path. Contextual work refuses that assumption, and it has refused it for a long time. What changed is not that the problem got worse. What changed is that we finally have a component capable of composing an answer at runtime, and the protocol layer to carry it.

Contextual Generative Experience accepts that the right interface is often the one that did not exist until the question was asked, and insists that generated still has to mean designed, structured, grounded, and actionable. Constrain the vocabulary. Stream the structure. Bind to real context. Render with craft. Attach actions with causes. Measure what people actually complete.

Do that, and UI stops being a fixed map of the product. It becomes a living instrument for the work in front of someone, at the moment they need it.