Give a generated AI interface a small vocabulary of reliable controls

The component is a promise

A chatbot can describe five options in a paragraph. An interface can let someone compare and select them. That sounds like an uncomplicated improvement until the options arrive slowly, one field is missing or the selected item changes during a refresh.

Google's October 29 developer walkthrough explains how A2UI and CopilotKit can connect agents to rich user interfaces. In the declarative approach, an agent describes an interface as data and an application renders it using a catalog of components. CopilotKit supplies integration with agent frameworks and the surrounding interaction stack.

The interesting design decision is the catalog. It determines more than which cards look consistent. It defines which choices the agent can offer and what information a component requires before it is meaningful.

This article proposes a small design exercise for that boundary. We have not run the tutorial or tested its recovery behavior. The examples below are hypothetical and apply to an app you build with A2UI or another component-based approach. They focus on stable controls and understandable failures rather than the final status of connected-app transactions.

Source: Google Developers: Build Generative UI Apps with A2UI and CopilotKit Agents ↗ · A2UI: Official protocol and component documentation ↗ · W3C WAI: Labeling Controls ↗ · W3C WAI: User Notification ↗

Choose one ordinary interaction

Start with a task that does not require a large catalog. Imagine an assistant helping a student choose a study session from a set of available times. The interface needs to show the options, distinguish them and preserve a selection while the person considers it.

Write down the information the student must compare: date, start time, duration, location and whether the session is remote. Decide which fields are essential. A time without a date or time zone may be too ambiguous to offer as a selectable option.

Now imagine the same content arriving as prose. What work does the reader do mentally? They locate the relevant attributes, compare them and remember which description corresponds to their choice. A component is useful when it makes that work easier without hiding important differences.

Do not begin by asking the agent to design anything it wants. Begin by defining the decision the interface should support. That gives you a reason to include a control and a reason to reject one that looks exciting but adds no useful information.

For the study-session example, a modest option card and a clear empty state may be enough for the first prototype. A map, calendar and animated summary can wait until the task demonstrates a need for them.

Write the rules for the smallest component

Describe an option card in ordinary language before writing its schema. It should have a stable identifier, a readable label and the attributes necessary for comparison. It should also have a defined response when an essential attribute is unavailable.

Make the difference between missing and unknown explicit. A location might be intentionally undecided. A location field might also have failed to load. Those situations should not silently produce the same reassuring blank space.

For this hypothetical app, you could decide that a session with an unconfirmed time appears as information but cannot be selected. The card would explain why. Another app might reasonably allow selection as an expression of interest. The important point is to choose the meaning deliberately.

Give the component a plain-language contract. State what the title identifies, what selecting the card does and which data must not be inferred. If the agent supplies an invented room name to satisfy a required field, the schema may be valid while the interface is misleading.

This is why structural validation and factual validation are separate. One checks whether a value has an allowed shape. The other checks whether the value is supported by the underlying resource. A trustworthy-looking component does not collapse those responsibilities.

Keep accessibility in the catalog

W3C's form-label guidance recommends identifying controls with associated labels. Its notification guidance also emphasizes feedback about outcomes and errors. These principles remain relevant when an agent decides which components appear.

Build labels into the component rather than relying on the model to produce an accessible variant every time. A study-session selector needs a name that a person can understand without depending only on its visual placement. An icon alone may not explain whether it changes the date, opens details or selects an option.

Review the component using a keyboard. Can someone move through the choices in an understandable order and tell which one is selected? Repeat the review when content is longer than expected. A design that works with a short label may become confusing with a full location description.

Make error text explain the next useful action. If there are no sessions matching the selected day, say whether the person can change the day or clear a filter. Avoid an empty rectangle that leaves them wondering whether the app is still working.

Do not assume a standard protocol certifies the accessibility of your application. The assembled experience depends on your components, their content and the way updates affect navigation. Keep those checks in the component review so improvements can benefit every generated screen that uses it.

Design the incomplete screen

The Google walkthrough describes incremental rendering and validation with recovery paths. Treat that as a reason to examine intermediate states in your own app, rather than assuming the eventual complete screen is the only one people encounter.

Suppose two session cards have arrived and a third is still being prepared. Should the first two be selectable? Is the set visibly incomplete? If the person selects one, will a later update preserve it? Decide these behaviors before judging the beauty of the final layout.

Avoid presenting a temporary ordering as a meaningful recommendation. If the first option appears simply because its data arrived first, do not label it best. Arrival order and ranking are different concepts.

Try unusually long labels, missing optional details and a slow response. Your aim is to see whether the layout retains meaning during change. This is a proposed review procedure; we are not reporting that A2UI or CopilotKit has any particular failure in these conditions.

If generation fails after partial content appears, choose whether to preserve the usable portion or replace the surface with an explanation. Either can be reasonable depending on the task. A sudden disappearance without explanation makes the person do unnecessary detective work.

Keep the fallback modest. A short text list with the same verified options can be more useful than repeatedly attempting an elaborate interface. The fallback should preserve the meaning of the choice, not merely fill the screen.

Keep identity stable while the layout changes

A user selects the Tuesday afternoon session. Then the agent reorganizes the list by location. What makes that selected session remain the same choice? It should be an underlying identifier, rather than its position on the screen or the exact wording of its title.

Include a reorder case in your prototype review. Select an option, change the sort or filter and inspect what remains selected. If the same position now points to a different session, a polished card has concealed a basic identity problem.

Also test two options with similar names. A person should be able to distinguish them through the attributes that matter. If both cards say study group and omit the date, the interface has not meaningfully improved on prose.

Make removal understandable. If a selected option becomes unavailable in your hypothetical dataset, show that change and ask the person to choose again. Do not silently substitute another option because it seems close enough.

The transferable lesson is that generated layout should be flexible while the meaning of data remains stable. Your app owns that stability. The model's ability to rearrange a screen does not make it responsible for the identity rules beneath the screen.

Keep the catalog smaller than your imagination

A large catalog can be impressive to demonstrate and difficult to maintain. Every component adds content requirements, states, layout behavior and interaction rules. Before adding another one, ask which actual user decision it improves.

For a first study-session prototype, you might need an option list, a detail panel and a message explaining that no matches were found. That is enough to explore meaningful choices. A decorative chart of availability may add complexity without helping somebody choose a time.

Give each component a clearly bounded purpose. A card that sometimes selects an option, sometimes opens a new page and sometimes triggers an external action is hard to understand. Separate those behaviors or make their labels unmistakable.

Document the version of the catalog used in your development notes. If an agent's instructions refer to fields from an older component definition, a failure may be caused by mismatched expectations rather than a model that cannot follow directions.

When updating a component, review existing examples that use it. A change that improves one long label may disrupt a compact view. A shared catalog spreads improvements, but it can spread regressions too. Keep a small set of representative screens you can revisit.

The purpose of restraint is not to limit creativity. It is to give the agent a reliable set of building blocks whose meanings you can explain to another person.

Run a review without depending on a perfect model output

You can review much of this design before connecting a live agent. Create several example payloads or manually populate your components with ordinary data. Include a complete session, one missing an optional field, one missing a required field and two with similar labels.

Add a deliberately unsupported component request. Your application should handle it through its defined validation or fallback route. Do not quietly interpret arbitrary content as trusted executable instructions simply because it came from the same conversation.

Show the examples to someone who has not seen the catalog rules. Ask them to choose a session and explain what they believe will happen. A disagreement between their interpretation and yours is useful feedback about the interface.

Then test the dynamic cases: reordered options, a removed selection, partial content and an unsuccessful generation. Record observations separately from your intended behavior. The intention belongs in the specification; what happened belongs in the review notes.

Only after those checks should you judge how well an agent selects and fills the components. That separates failures in your building blocks from failures in generation. It also makes the prototype useful even when a model response is inconsistent.

A2UI's declarative approach provides a way to express interface intent across systems. The quality of that intent still depends on the component choices. Make a few controls reliable enough that a person can understand them during an ordinary failure, and you have a stronger starting point than a large screen that only makes sense in a flawless demo.