Right now, working with A2UI requires jumping back and forth between a lot of different layers just to build or update a single feature. If you want to change a component or add a new one, you have to manually sync it across the agent's JSON schema catalog, the few-shot examples, the system prompts/UI descriptions, and the actual front-end component implementation and registry. If you change one property name, you're hunting through four or five different files in different languages to keep it from breaking.
To make this a lot easier to build with, it would be awesome to introduce some developer tooling—either through a CLI, specialized agent skills, or both—that handles this coordination for us. The goal is to let developers manage the UI lifecycle and the underlying boilerplate using simple natural language or clean configs.
Proposed Capabilities
Part 1: Authoring components and catalogs with natural language
The most important part of this would be the ability to create or update custom catalogs, examples, and UI descriptions just by talking to an agent. For example, a developer should be able to say something like, "add a new view to my app that shows a monthly sales breakdown" or "change the restaurant booking form to include a field for dietary restrictions."
Instead of a human manually editing five different files, the tool/agent should figure out exactly what needs to change across the workspace and handle it automatically:
- UI Descriptions: Update the system instructions that tell the LLM when and why to use that specific interface.
- Agent Card & Skills: Update the
AgentCard metadata and any associated AgentSkills.
- Custom Catalog: Automatically update the formal JSON schema registry with the right parameters and properties.
- Examples: Write or update the static mock JSON examples used to teach the LLM how to output the component.
- Client-side implementation: Generate the physical front-end component code (like Angular or Lit files) and automatically hook it up to the client catalog registry.
Part 2: Automating configuration options and boilerplate
A second piece—which is less critical but would still save a ton of time—is adding skills to manage the underlying boilerplate configurations. There is a lot of setup code in the project examples, but the most important parts are really just the settings.
An agent should just inherently understand how to read and update those configurations without a developer having to manually scaffold everything. This includes updating things like:
- AgentCards and identity options
- Runners and executors (
agent_executor.py)
- System instructions and routing setups
Implementation Approach
Agent skills seem much better suited for handling the natural language side of this workflow. However, depending on just how "boilerplate" some of that underlying boilerplate code actually is, it might make more sense to rely on a CLI for those specific tasks so that the code-generation results are completely stable and predictable.
There are plenty of configurations we can eventually automate, but starting with natural language component generation would completely remove the biggest manual tax of building with the protocol today.
Right now, working with A2UI requires jumping back and forth between a lot of different layers just to build or update a single feature. If you want to change a component or add a new one, you have to manually sync it across the agent's JSON schema catalog, the few-shot examples, the system prompts/UI descriptions, and the actual front-end component implementation and registry. If you change one property name, you're hunting through four or five different files in different languages to keep it from breaking.
To make this a lot easier to build with, it would be awesome to introduce some developer tooling—either through a CLI, specialized agent skills, or both—that handles this coordination for us. The goal is to let developers manage the UI lifecycle and the underlying boilerplate using simple natural language or clean configs.
Proposed Capabilities
Part 1: Authoring components and catalogs with natural language
The most important part of this would be the ability to create or update custom catalogs, examples, and UI descriptions just by talking to an agent. For example, a developer should be able to say something like, "add a new view to my app that shows a monthly sales breakdown" or "change the restaurant booking form to include a field for dietary restrictions."
Instead of a human manually editing five different files, the tool/agent should figure out exactly what needs to change across the workspace and handle it automatically:
AgentCardmetadata and any associatedAgentSkills.Part 2: Automating configuration options and boilerplate
A second piece—which is less critical but would still save a ton of time—is adding skills to manage the underlying boilerplate configurations. There is a lot of setup code in the project examples, but the most important parts are really just the settings.
An agent should just inherently understand how to read and update those configurations without a developer having to manually scaffold everything. This includes updating things like:
agent_executor.py)Implementation Approach
Agent skills seem much better suited for handling the natural language side of this workflow. However, depending on just how "boilerplate" some of that underlying boilerplate code actually is, it might make more sense to rely on a CLI for those specific tasks so that the code-generation results are completely stable and predictable.
There are plenty of configurations we can eventually automate, but starting with natural language component generation would completely remove the biggest manual tax of building with the protocol today.