What_A2UI_and_AG-UI_Actually_Do

Google's A2UI standard and CopilotKit's AG-UI protocol solve a specific problem: how do you let an agent return a rendered interface component instead of text?

In a traditional agent workflow, the agent's output is bounded by natural language. It can describe a table, recommend an action, explain a concept - but all of it is text. The frontend receives text and decides how to render it. The agent has no way to say "render a table with these columns and this data, sorted by this field, with this action button at the bottom." It can describe that intent in words, but translating that description into a rendered component requires human reading and manual implementation.

A2UI changes the boundary. The agent returns structured data - a component type, properties, data bindings, event handlers. The component is declared, not described. The frontend receives a component specification and renders it. The agent's output is no longer text; it's a UI declaration.

AG-UI is the protocol layer that makes this communication possible. It standardises the event-based channel between the agent backend and the frontend application. The agent returns a component declaration; the application layer above AG-UI validates it against a schema, maps it to the frontend's component library, handles data binding, and passes the rendered output to the user. The loop is closed: the agent decided what to show, and the frontend rendered it.

This is powerful because it collapses the translation step. An agent can now make a rendering decision - "this context calls for a table, not a paragraph" - and have that decision execute directly. But power and risk move together. The decision is no longer made by a human designer who has reviewed the final output. It's made by a system, in response to specific input, in real time. That system's decisions must be governed.

The_Difference_Between_a_Deliverable_and_a_Behaviour

A UI deliverable is something humans recognise. It has an author, a review history, a specification. It was designed, approved, built, tested, and deployed. It exists in a fixed form, and that form was examined by multiple people before any user saw it.

A UI behaviour is an output - the result of a system making a decision. When an agent renders a UI component in response to user input, it is producing a behaviour, not a deliverable. Nobody pre-approved that specific rendering. It was not individually designed or tested. It emerged from a system rule applied to live input.

The difference matters because governance is different for each. A deliverable can be governed by review and approval. A behaviour can only be governed by constraints on the system that produces it.

Three properties make this shift relevant:

First: it varies by input. The same agent rule produces different renderings depending on what the user asks for and what data is available. Governance cannot specify a single component instance - it must specify the space of valid renderings the system is allowed to produce. This is a constraint on a system, not a review of an artefact.

Second: it interacts with system state. A rendering valid in isolation may be invalid in context. An agent might render a button that executes an action the current user is not authorised to perform. The button is valid as a component. The action is not valid for this user at this moment. The governance spec must account for the system state at render time, not just the rendering rule in isolation.

Third: it can produce accessible and inaccessible renderings from the same specification. A component can be rendered in ways that comply with WCAG 2.1 AA and ways that do not, depending on how data is surfaced and composed. A human designer typically produces a finite number of states, each individually reviewed for accessibility. An agent produces a combinatorial space of renderings. Most will never be individually audited. Accessibility compliance must be enforced at the component and composition level, not assumed from a specification.

These three properties mean that a design system - which governs how humans produce UI - is not enough. You need a separate governance layer that constrains what agents are authorised to render, given what context, with what constraints.

The_Design_System_Is_Not_the_Governance_Layer

A design system governs visual and interaction standards. It specifies which colours are allowed, which typography scales, which spacing rules, which button states, which animation durations. It constrains visual output. It ensures consistency. It makes it possible for different people to produce interfaces that feel like they belong to the same product.

A design system does not answer: which components is an agent authorised to render? What data can it surface? What actions can it make available? What happens when constraints can't be met?

These are not design system questions. They are governance questions. They require statements like "this agent can render tables, but not timelines," or "this agent can show read-only data, but not execute writes," or "this agent must not render forms that collect payment data." A design system has no mechanism for these constraints. It was not built for them.

The gap is not a design system failure. Design systems were built to help humans produce consistent visual output. Agents produce rendering decisions, not consistent visual output. Agents need a different constraint layer.

That layer is what I call a trust catalogue.

What_a_Trust_Catalogue_Actually_Looks_Like

I am building this now. EXP_008 (Generative UI Renderer) takes natural language input and returns rendered UI via a declarative block schema. The schema is the constraint layer: heading, paragraph, button, card, stat, form, input_field, divider, badge. A button block requires a variant from an enumerated list - primary, secondary, outline. The agent cannot produce a button with a free-text variant. The enumerated variants are the ones the rendering layer has implemented handling for. Anything outside the list produces a known error, not an unknown behaviour. That is a trust catalogue in code.

A trust catalogue answers what a design system cannot: what is the agent authorised to render?

It specifies: Which components can this agent use (e.g., read-only data display, but not forms)? Which data can it surface (e.g., public product information, but not user payment history)? Which actions can it make available (e.g., "view details," but not "delete")? What accessibility requirements must be met (WCAG 2.1 AA as a hard requirement, not aspiration)? What happens when a constraint cannot be satisfied (fallback to text, surface an error, refuse the request)?

A trust catalogue is a governance spec. It defines the boundary between "this agent is authorised to produce" and "this is out of scope."

I already use this pattern for content output. In my Labs experiments, I run an Autonomous Brand Pipeline (EXP_005) where agents generate brand concept variants - visual direction, colour palette, language tone, values framework. These concepts must pass through an evaluation step before being surfaced to me.

The evaluation logic is straightforward: each concept is scored against a set of brand rules. Those rules are the trust catalogue for generated brand content. They specify what the agent is authorised to produce:

Authorised voice: practitioner register, specific examples, intellectual honesty, flat affect Authorised palette: cool greys, accent blue, chartreuse - no warmth, no gradients Authorised values: autonomy, precision, operational reality - nothing about "disruption" or "the future" Forbidden patterns: fast fashion language, urgency tactics, greenwashing, positioning copy, empty superlatives

The pipeline generates concept variants in parallel, scores each against the brand rules, lists flagged violations per concept, and surfaces only the ones that clear the threshold. The rules are enforced in code, not in a review document. This is what a trust catalogue looks like in production - a running evaluation step, not a memo.

A concept that violates the voice rules - say, it uses "game-changing" or "passionate about" - is flagged and scored down. Only concepts that pass evaluation are surfaced for review. I am not reading every variant the agent produces; I am reading the ones the trust catalogue approved.

The same logic applies to rendered interfaces, with one crucial addition: interfaces have functional behaviour that text does not.

When an agent generates a brand concept, the risk is reputational - a poor concept makes the brand look careless. When an agent renders a UI component, the risk includes functional incorrectness. The agent might render an action button the user is not authorised to use. The interface will work. The user will click the button. And nothing will happen because the backend will reject the request. But the interface suggested the action was available, and it was not. That is a functional error that a trust catalogue must prevent.

The evaluation step for agent-rendered UI is therefore more complex. It must check not just component validity and data visibility, but also authorisation alignment between the frontend rendering decision and the backend access control model.

What_the_Governance_Spec_for_Agent-Rendered_UI_Looks_Like

A governance spec for agent-rendered UI has several components:

Component authorisation list. Which components can this agent render? In EXP_008, the current authorised block types are: heading, paragraph, button, card, stat, form, input_field, divider, badge. Button requires a variant from an enumerated list: primary, secondary, outline. The agent populates the schema; the renderer executes it; anything outside the schema definition is a known refusal. The authorisation list is not arbitrary - it maps to what the renderer has error handling for. You cannot add a block type without also specifying what the renderer does when it fails.

Data surface rules. What data can the agent include in rendered components? This is not just "public vs. private." It's more specific: "this agent can surface account balance for the authenticated user only," or "this agent can show order history for orders the user placed, not orders other users placed." These rules are checked before the component is rendered.

Action authorisation. What actions can the agent make available in rendered components? This must align with the backend authorisation model. If the backend says "this user can create items but not delete them," the frontend must not render a delete button for this user. The simplest enforcement is to query the backend authorisation model before deciding which buttons to render. The agent's job is to decide which data to show; the authorisation layer's job is to decide which actions are valid for the current context.

Accessibility requirements. WCAG 2.1 AA compliance is a hard requirement, not aspirational. This means the component rendering engine must validate accessibility properties of every rendered component - alt text for images, ARIA labels for buttons, proper heading hierarchy, sufficient colour contrast. If a required accessibility property is missing, the component does not render. An error is surfaced instead.

Fallback behaviour. What happens when the agent wants to render something outside its authorisation? The safest option is to refuse and surface an error message. The more generous option is to degrade gracefully - render a text description instead of the requested component. The governance spec should specify which fallback applies in each case.

These five elements - component list, data rules, action authorisation, accessibility requirements, fallback behaviour - form the boundary the agent operates within. The agent can be as sophisticated as you want it to be. But it can only render what the trust catalogue permits.

Production_Commitment,_Not_Public_Preview

A2UI and AG-UI make it possible to ship agent-rendered interfaces. They do not make it possible to ship them correctly.

The gap is the governance spec. This is not a design problem or an engineering problem. It is a governance problem. Someone must hold all three disciplines simultaneously - design, engineering, governance - and write down what the agent is authorised to produce.

When a UI was a deliverable, all three disciplines looked at the same artefact. A designer produced a mockup. An engineer built it. A governance person checked it for compliance and risk. When the UI is a behaviour, this alignment breaks. The designer is not looking at the rendered output - it does not exist yet. The engineer is building a system that produces outputs, not a specific output. The governance person is now upstream, constraining the system before it produces anything.

The disciplines stop speaking the same language.

This is not a temporary friction. It is structural. The person who holds all three - who understands what the agent can render, what the system constraints are, what the governance rules must be - is the person who writes the spec. That person has to exist before you ship agent-rendered UI.

This is the principle that every layer of a system - from data access to API contract to rendering rules - must have someone responsible for its correctness, not just its existence. For agent-rendered UI, that means someone owns the trust catalogue, tests it, revises it when new agent capabilities arrive, and ensures it covers all the use cases the agent is actually deployed against.

If you ship agent-rendered interfaces without this person and this spec, you will ship incorrect interfaces. They will function without crashing. But they will suggest actions the user cannot perform, surface data that violates privacy rules, or fail accessibility requirements. The correctness problem will not be immediately obvious because the interface is generated - it is harder to spot than a bug in a fixed UI. But it will be there.

EXP_008 is mid-build. Nine block types specified. The accessibility validation step runs on complete renders; partial renders when data is missing are not yet covered. That is a named specification gap, queued. The trust catalogue is a living document. The factory is running. The spec is still being written.