feat: Support for Declarative Input Validation in UI Components

[Bangkah]

Is your feature request related to a problem? Please describe. Currently, A2UI allows agents to render input components (like text fields or sliders) dynamically. However, there isn't a standardized way in the JSON/Protobuf schema for the agent to define client-side validation rules. This results in unnecessary round-trips to the LLM just to catch simple formatting errors (e.g., invalid email format or password length).

Describe the solution you'd like I suggest adding a validation field to input-capable components in the A2UI schema. This would allow the renderer to handle basic logic locally.

Key features should include:

• Regex Support: For patterns like emails, phone numbers, or custom IDs.
• Range Constraints: min, max, and step for numeric inputs.
• Required Flag: A boolean to prevent submission if the field is empty.
• Error Messages: A custom errorMessage string defined by the agent to be displayed when validation fails.

Describe alternatives you've considered

• Server-side validation: Handling this only at the Agent level (too slow for UX).
• Hardcoding in Renderer: Less flexible as the Agent cannot adapt validation rules on the fly.

Additional context This would bring A2UI closer to frameworks like JSON Schema Form or React Hook Form, but optimized for the Agent-to-User streaming protocol.

[lrosenthol]

At Adobe, we created a technology called json-formula which combines JMESPath (for targeting elements of a JSON structure) with OpenFormula (for Excel like functions) for declarative formula expressions.

It is being used by a number of organizations and standards bodies for a variety of purposes, including data validation of field values. There are multiple implementations in JavaScript/Typescript, C++ and other languages.

Would be happy to discuss further.

[Bangkah]

Hi @lrosenthol, thank you for the insights! json-formula sounds like a very robust solution, especially since it's already battle-tested at Adobe and other organizations.

My main goal with this proposal is to keep the A2UI schema 'LLM-friendly'—meaning it should be simple enough for an agent to generate without adding too much token overhead. How do you see the integration of json-formula in terms of schema complexity? Would it be possible to implement a lightweight subset of it for basic validation (like regex or range) while keeping the protocol performant for streaming?

[lrosenthol]

My main goal with this proposal is to keep the A2UI schema 'LLM-friendly'—meaning it should be simple enough for an agent to generate without adding too much token overhead.

Understood, and we have experience using LLM's to produce json-formula directly - so that is not a blocker to its adoption.

You may find that you use multiple steps - since the validation operations (in general, not specific to json-formula) may be better addressed by a different context/prompt or possibly even a different LLM or approach.

[Bangkah]

That's a very interesting point, @lrosenthol. If we go with a multi-step approach or a separate context for validation, how do you envision the 'handshake' between the primary UI generation prompt and the validation logic? Does it happen at the Agent level before streaming to the client, or is the validation logic bundled within the UI component response? I'd love to see an example of how you've structured these prompts for LLMs to output json-formula reliably.