google · wrenj · Apr 7, 2026 · Apr 7, 2026
diff --git a/docs/composer.md b/docs/composer.md
@@ -8,9 +8,11 @@ Try building A2UI widgets interactively with the **CopilotKit A2UI Widget Builde
 
 ## What it does
 
-- Experiment with A2UI components visually
-- Generate A2UI JSON by describing what you want
-- See real-time previews
-- Copy JSON to use in your agents
+The Widget Builder enables you to:
+
+- Experiment with A2UI components visually.
+- Generate A2UI JSON by describing desired interfaces.
+- View real-time previews.
+- Copy the generated JSON for use in agents.
 
 Built by the [CopilotKit](https://www.copilotkit.ai/) team.
diff --git a/docs/concepts/catalogs.md b/docs/concepts/catalogs.md
@@ -6,9 +6,9 @@ This guide defines the A2UI Catalog architecture and provides a roadmap for impl
 
 ## Catalog Schema
 
-A catalog schema is a [JSON Schema file](../specification/v0_9/json/client_capabilities.json#L62C5-L95C6) outlining the components, functions, and themes that agents can use to define A2UI surfaces using server-driven UI. All A2UI JSON sent from the agent is validated against the chosen catalog.
+A catalog schema is a [JSON Schema file](../../specification/v0_9/json/client_capabilities.json#L62C5-L95C6) outlining the components, functions, and themes that agents can use to define A2UI surfaces using server-driven UI. All A2UI JSON sent from the agent is validated against the chosen catalog.
 
-[Catalog JSON Schema](../specification/v0_9/json/client_capabilities.json#L62C5-L95C6) is below
+[Catalog JSON Schema](../../specification/v0_9/json/client_capabilities.json#L62C5-L95C6) is below
 
 ```json
 {
@@ -59,15 +59,15 @@ Whether you are building a simple prototype or a complex production application,
 
 ### The Basic Catalog
 
-To help developers get started quickly, the A2UI team maintains the [Basic Catalog](../specification/v0_9/json/basic_catalog.json).
+To help developers get started quickly, the A2UI team maintains the [Basic Catalog](../../specification/v0_9/json/basic_catalog.json).
 
 This is a pre-defined catalog file that contains a standard set of general-purpose components (Buttons, Inputs, Cards) and functions. It is not a special "type" of catalog; it is simply a version of a catalog that we have already written and have open source renderers for. 
 
 The basic catalog allows you to bootstrap an application or validate A2UI concepts without needing to write your own schema from scratch. It is intentionally sparse to remain easily implementable by different renderers.
 
 Since A2UI is designed for LLMs to generate the UI at either design time or runtime, we do not think portability requires a standardized catalog across multiple clients; the LLM can interpret the catalog for each individual frontend.
 
-[See the A2UI v0.9 basic catalog](../specification/v0_9/json/basic_catalog.json)
+[See the A2UI v0.9 basic catalog](../../specification/v0_9/json/basic_catalog.json)
 
 ### Defining Your Own Catalog
 
@@ -77,7 +77,7 @@ By defining your own catalog, you restrict the agent to using exactly the compon
 
 For simplicity we recommend building catalogs that directly reflect a client's design system rather than trying to map the Basic Catalog to it through an adapter. Since A2UI is designed for GenUI, we expect the LLM can interpret different catalogs for different clients.
 
-[See an example Rizzcharts catalog](../samples/agent/adk/rizzcharts/rizzcharts_catalog_definition.json)
+[See an example Rizzcharts catalog](../../samples/agent/adk/rizzcharts/catalog_schemas/0.9/rizzcharts_catalog_definition.json)
 
 ### Recommendations
 
@@ -88,7 +88,7 @@ For simplicity we recommend building catalogs that directly reflect a client's d
 
 ## Building a Catalog
 
-A catalog is a JSON Schema file that conforms to the [Catalog schema](../specification/v0_9/json/client_capabilities.json#L62C5-L95C6) that defines the components, themes and functions an agent can use when building a surface.
+A catalog is a JSON Schema file that conforms to the [Catalog schema](../../specification/v0_9/json/client_capabilities.json#L62C5-L95C6) that defines the components, themes and functions an agent can use when building a surface.
 
 ### Example: A Minimal Catalog
 
@@ -275,7 +275,7 @@ export class HelloWorldBanner extends DynamicComponent {
 }
 ```
 
-You can see a working example of a client renderer in the [Rizzcharts demo](../samples/client/angular/projects/rizzcharts/src/a2ui-catalog/catalog.ts).
+You can see a working example of a client renderer in the [Rizzcharts demo](../../samples/client/angular/projects/rizzcharts/src/a2ui-catalog/catalog.ts).
 
 ## A2UI Catalog Negotiation
 
@@ -461,4 +461,4 @@ Example of client reporting a missing required field
 
 ## Inline Catalogs
 
-Inline catalogs sent by the client at runtime are supported but not recommended in production. More details about them can be found [here](../specification/v0_9/docs/a2ui_protocol.md#client-capabilities--metadata).
+Inline catalogs sent by the client at runtime are supported but not recommended in production. More details about them can be found [here](../../specification/v0_9/docs/a2ui_protocol.md#client-capabilities--metadata).
diff --git a/docs/concepts/components.md b/docs/concepts/components.md
@@ -12,10 +12,10 @@ A2UI uses an **adjacency list model** for component hierarchies. Instead of nest
 
 **A2UI adjacency list:**
 
-- ✅ Flat structure, easy for LLMs to generate
-- ✅ Send components incrementally
-- ✅ Update any component by ID
-- ✅ Clear separation of structure and data
+- Flat structure, easy for LLMs to generate.
+- Send components incrementally.
+- Update any component by ID.
+- Clear separation of structure and data.
 
 ## The Adjacency List Model
 
@@ -171,7 +171,7 @@ Every component has:
 
 ## The Basic Catalog
 
-To help developers get started quickly, the A2UI team maintains the [Basic Catalog](../specification/v0_9/json/basic_catalog.json).
+To help developers get started quickly, the A2UI team maintains the [Basic Catalog](../../specification/v0_9/json/basic_catalog.json).
 
 This is a pre-defined catalog file that contains a standard set of general-purpose components (Buttons, Inputs, Cards). It is not a special "type" of catalog; it is simply a version of a catalog that has open source renderers available.
 
@@ -233,6 +233,8 @@ A surface is a complete, cohesive UI (form, dashboard, chat, etc.).
 
 ## Incremental Updates
 
+Incremental updates support the following operations:
+
 - **Add** - Send new component definitions with new IDs
 - **Update** - Send component definitions with existing ID and new properties
 - **Remove** - Update parent's `children` list to exclude removed IDs

diff --git a/docs/concepts/data-binding.md b/docs/concepts/data-binding.md
@@ -1,6 +1,6 @@
 # Data Binding
 
-Data binding connects UI components to application state using JSON Pointer paths ([RFC 6901](https://tools.ietf.org/html/rfc6901)). It's what allows A2UI to efficiently define layouts for large arrays of data, or to show updated content without being regenerated from scratch.
+Data binding connects UI components to application state using JSON Pointer paths ([RFC 6901](https://tools.ietf.org/html/rfc6901)). It allows A2UI to efficiently define layouts for large arrays of data and to show updated content without regenerating it from scratch.
 
 ## Structure vs. State
 
@@ -9,7 +9,11 @@ A2UI separates:
 1. **UI Structure** (Components): What the interface looks like
 2. **Application State** (Data Model): What data it displays
 
-This enables: reactive updates, data-driven UIs, reusable templates, and bidirectional binding.
+This enables:
+- Reactive updates.
+- Data-driven UIs.
+- Reusable templates.
+- Bidirectional binding.
 
 ## The Data Model
 
@@ -176,24 +180,24 @@ Interactive components update the data model bidirectionally:
 
 ## Best Practices
 
-**1. Use granular updates** - Update only changed paths:
-```json
-{
-  "dataModelUpdate": {
-    "path": "/user",
-    "contents": [
-      { "key": "name", "valueString": "Alice" }
-    ]
+- **Use granular updates**: Update only changed paths.
+  ```json
+  {
+    "dataModelUpdate": {
+      "path": "/user",
+      "contents": [
+        { "key": "name", "valueString": "Alice" }
+      ]
+    }
   }
-}
-```
+  ```
 
-**2. Organize by domain** - Group related data:
-```json
-{"user": {...}, "cart": {...}, "ui": {...}}
-```
+- **Organize by domain**: Group related data.
+  ```json
+  {"user": {...}, "cart": {...}, "ui": {...}}
+  ```
 
-**3. Pre-compute display values** - Agent formats data (currency, dates) before sending:
-```json
-{"price": "$19.99"}  // Not: {"price": 19.99}
-```
+- **Pre-compute display values**: Formats data (currency, dates) on the agent before sending.
+  ```json
+  {"price": "$19.99"}  // Not: {"price": 19.99}
+  ```
diff --git a/docs/concepts/data-flow.md b/docs/concepts/data-flow.md
@@ -311,11 +311,15 @@ Users see UI building in real-time instead of staring at a spinner.
 
 ## Error Handling
 
-- **Malformed messages:** Skip and continue, or send error back to agent for correction
-- **Network interruptions:** Display error state, reconnect, agent resends or resumes
+The system handles errors as follows:
+
+- **Malformed messages:** Skip and continue, or send error back to agent for correction.
+- **Network interruptions:** Display error state, reconnect, agent resends or resumes.
 
 ## Performance
 
-- **Batching:** Buffer updates for 16ms, batch render together
-- **Diffing:** Compare old/new components, update only changed properties
-- **Granular updates:** Update `/user/name` not entire `/` model
+To optimize performance:
+
+- **Batching:** Buffer updates for 16ms, batch render together.
+- **Diffing:** Compare old/new components, update only changed properties.
+- **Granular updates:** Update `/user/name` not entire `/` model.
diff --git a/docs/concepts/overview.md b/docs/concepts/overview.md
@@ -27,13 +27,17 @@ How components connect to application state using JSON Pointer paths. Covers rea
 
 === "v0.8 (Stable)"
 
+    Version 0.8 uses the following message types:
+
     - **`surfaceUpdate`**: Define or update UI components
     - **`dataModelUpdate`**: Update application state
     - **`beginRendering`**: Signal the client to render
     - **`deleteSurface`**: Remove a UI surface
 
 === "v0.9 (Draft)"
 
+    Version 0.9 uses the following message types:
+
     - **`createSurface`**: Create a new surface and specify its catalog
     - **`updateComponents`**: Add or update UI components in a surface
     - **`updateDataModel`**: Update application state

diff --git a/docs/concepts/transports.md b/docs/concepts/transports.md
@@ -31,9 +31,9 @@ standardized agent communication.  An A2A extension provides easy integration wi
 
 **Benefits:**
 
-- Security and authentication built-in
-- Bindings for many message formats, auth, and transport protocols
-- Clean separation of concerns
+- Security and authentication built-in.
+- Bindings for many message formats, auth, and transport protocols.
+- Clean separation of concerns.
 
 If you are using A2A, this should be nearly automatic.
 

diff --git a/docs/ecosystem/a2ui-in-the-world.md b/docs/ecosystem/a2ui-in-the-world.md
@@ -12,9 +12,9 @@ A2UI is being adopted by teams at Google and partner organizations to build the
 
 The Opal team at Google has been a **core contributor to A2UI** from the beginning. They use A2UI to power the dynamic, generative UI system that makes Opal's AI mini-apps possible.
 
-- **Rapid prototyping**: Build and test new UI patterns quickly
-- **User-generated apps**: Anyone can create apps with custom UIs
-- **Dynamic interfaces**: UIs adapt to each use case automatically
+- **Rapid prototyping**: Build and test new UI patterns quickly.
+- **User-generated apps**: Anyone can create apps with custom UIs.
+- **Dynamic interfaces**: UIs adapt to each use case automatically.
 
 > "A2UI is foundational to our work. It gives us the flexibility to let the AI drive the user experience in novel ways, without being constrained by a fixed front-end. Its declarative nature and focus on security allow us to experiment quickly and safely."
 >
@@ -32,10 +32,10 @@ Gemini Enterprise enables businesses to build powerful, custom AI agents tailore
 
 A2UI is being integrated to allow enterprise agents to render **rich, interactive UIs** within business applications—going beyond simple text responses to guide employees through complex workflows.
 
-- **Data entry forms**: AI-generated forms for structured data collection
-- **Approval dashboards**: Dynamic UIs for review and approval processes
-- **Workflow automation**: Step-by-step interfaces for complex tasks
-- **Custom enterprise UIs**: Tailored interfaces for industry-specific needs
+- **Data entry forms**: AI-generated forms for structured data collection.
+- **Approval dashboards**: Dynamic UIs for review and approval processes.
+- **Workflow automation**: Step-by-step interfaces for complex tasks.
+- **Custom enterprise UIs**: Tailored interfaces for industry-specific needs.
 
 > "Our customers need their agents to do more than just answer questions; they need them to guide employees through complex workflows. A2UI will allow developers building on Gemini Enterprise to have their agents generate the dynamic, custom UIs needed for any task, from data entry forms to approval dashboards, dramatically accelerating workflow automation."
 >
@@ -53,10 +53,10 @@ The [Flutter GenUI SDK](https://docs.flutter.dev/ai/genui) brings dynamic, AI-ge
 
 GenUI SDK uses **A2UI as the underlying protocol** for communication between server-side agents and Flutter applications. When you use GenUI, you're using A2UI under the covers.
 
-- **Cross-platform support**: Same agent works on iOS, Android, web, desktop
-- **Native performance**: Flutter widgets rendered natively on each platform
-- **Brand consistency**: UIs match your app's design system
-- **Server-driven UI**: Agents control what's shown without app updates
+- **Cross-platform support**: Same agent works on iOS, Android, web, desktop.
+- **Native performance**: Flutter widgets rendered natively on each platform.
+- **Brand consistency**: UIs match your app's design system.
+- **Server-driven UI**: Agents control what's shown without app updates.
 
 > "Our developers choose Flutter because it lets them quickly create expressive, brand-rich, custom design systems that feel great on every platform. A2UI was a great fit for Flutter's GenUI SDK because it ensures that every user, on every platform, gets a high quality native feeling experience."
 >
@@ -78,9 +78,9 @@ The [Agent Development Kit](https://google.github.io/adk-docs/) (ADK) is Google'
 
 ADK integrated the A2UI v0.8 standard catalog to automatically render spec-compliant agent parts as native UI components directly in the chat. ADK also handles A2UI↔A2A message conversion, so agents built with ADK can send rich UI to any A2UI-capable client.
 
-- **Built-in rendering**: ADK Web renders A2UI components natively in the dev UI
-- **A2A integration**: A2UI messages are converted between A2A DataPart metadata and ADK events
-- **Agent SDK**: The [A2UI Python agent SDK](https://github.com/google/A2UI/tree/main/agent_sdks/python) provides an ADK extension for generating A2UI from agents
+- **Built-in rendering**: ADK Web renders A2UI components natively in the dev UI.
+- **A2A integration**: A2UI messages are converted between A2A DataPart metadata and ADK events.
+- **Agent SDK**: The [A2UI Python agent SDK](https://github.com/google/A2UI/tree/main/agent_sdks/python) provides an ADK extension for generating A2UI from agents.
 
 **Try it:**
 - [ADK Documentation](https://google.github.io/adk-docs/)
@@ -99,10 +99,10 @@ ADK integrated the A2UI v0.8 standard catalog to automatically render spec-compl
 
 AG UI excels at creating high-bandwidth connections between custom frontends and their dedicated agents. By adding A2UI support, developers get the best of both worlds:
 
-- **State synchronization**: AG UI handles app state and chat history
-- **A2UI rendering**: Render dynamic UIs from third-party agents
-- **Multi-agent support**: Coordinate UIs from multiple agents
-- **React integration**: Seamless integration with React applications
+- **State synchronization**: AG UI handles app state and chat history.
+- **A2UI rendering**: Render dynamic UIs from third-party agents.
+- **Multi-agent support**: Coordinate UIs from multiple agents.
+- **React integration**: Seamless integration with React applications.
 
 > "AG UI excels at creating a high-bandwidth connection between a custom-built front-end and its dedicated agent. By adding support for A2UI, we're giving developers the best of both worlds. They can now build rich, state-synced applications that can also render dynamic UIs from third-party agents via A2UI. It's a perfect match for a multi-agent world."
 >
@@ -123,10 +123,10 @@ AG UI excels at creating high-bandwidth connections between custom frontends and
 
 A2UIAgent extends AG2's ConversableAgent with built-in A2UI capabilities — prompt engineering, schema validation with retry, and action handling — so developers can add generative UI to their agents without custom rendering code.
 
-- **Validated output**: Built-in schema validation and retry ensures reliable A2UI generation
-- **Dual transport**: Serves the same UI over A2A (JSON-RPC) and AG-UI (SSE)
-- **Cross-platform**: One agent serves web, desktop, and mobile clients
-- **Custom catalogs**: Extend the component catalog with domain-specific components
+- **Validated output**: Built-in schema validation and retry ensures reliable A2UI generation.
+- **Dual transport**: Serves the same UI over A2A (JSON-RPC) and AG-UI (SSE).
+- **Cross-platform**: One agent serves web, desktop, and mobile clients.
+- **Custom catalogs**: Extend the component catalog with domain-specific components.
 
 > "A2UIAgent brings the A2UI protocol to AG2, enabling agent expression with dynamic, rich, and interactive UIs. Reliable, client-agnostic rendering means our developers spend less time on integration and more time building great experiences."
 >
@@ -147,10 +147,10 @@ As Google adopts AI across the company, A2UI provides a **standardized way for A
 
 **Internal agent adoption:**
 
-- **Multi-agent workflows**: Multiple agents contribute to the same surface
-- **Remote agent support**: Agents running on different services can provide UI
-- **Standardization**: Common protocol across teams reduces integration overhead
-- **External exposure**: Internal agents can be easily exposed externally (e.g., Gemini Enterprise)
+- **Multi-agent workflows**: Multiple agents contribute to the same surface.
+- **Remote agent support**: Agents running on different services can provide UI.
+- **Standardization**: Common protocol across teams reduces integration overhead.
+- **External exposure**: Internal agents can be easily exposed externally (e.g., Gemini Enterprise).
 
 > "Much like A2A lets any agent talk to another agent regardless of platform, A2UI standardizes the user interface layer and supports remote agent use cases through an orchestrator. This has been incredibly powerful for internal teams, allowing them to rapidly develop agents where rich user interfaces are the norm, not the exception. As Google pushes further into generative UI, A2UI provides a perfect platform for server-driven UI that renders on any client."
 >
@@ -192,10 +192,12 @@ Have you built something with A2UI? [Share it with the community!](community.md)
 
 ## Next Steps
 
-- [Quickstart Guide](../quickstart.md) - Try the demo
-- [Agent Development](../guides/agent-development.md) - Build an agent
-- [Client Setup](../guides/client-setup.md) - Integrate a renderer
-- [Community](community.md) - Join the community
+For more information, see the following resources:
+
+- [Quickstart Guide](../quickstart.md) - Try the demo.
+- [Agent Development](../guides/agent-development.md) - Build an agent.
+- [Client Setup](../guides/client-setup.md) - Integrate a renderer.
+- [Community](community.md) - Join the community.
 
 ---