Understanding catalog negotiation

[ISilviu]

Hello,

I'm trying to better understand A2UI's catalog negotiation.
The documentation seems to tie the catalog negotiation to A2A, but I believe this would also apply to projects that don't use A2A.

In my case, I have followed the agent development instructions. In that guide, the A2UI schema is static, and provided as context through the system prompt.

It is hard for me on how one should implement catalog negotiation, considering the provided example uses a static schema.
I have used a Pydantic schema to validate the A2UI schema outputted by the LLM.

If we employ catalog negotation, this means we would essentially need to:

1. Frontend sends the catalog ids in each request.
2. The backend receives it and propagates it to the part of the code that configures the LLM that responds in A2UI.
3. The code will dynamically pick the Pydantic classes to use, as well as pick/re-generate the a2ui_schema that is sent to the system prompt of the LLM.
4. The LLM will respond, with respect to the received catalog ID.

For reference, using LangChain and LangGraph.

Can you please confirm I have correctly understood the flow?

cc @gspencergoog @jacobsimionato

[sanjaykumar-xe]

I think your overall flow is close, but I would make one important distinction: catalog negotiation doesn't necessarily mean dynamically generating a new Pydantic model or A2UI schema for every request.

I would model it more like:

1. The renderer/client advertises the catalog IDs it supports (for example, supportedCatalogIds).
2. The agent/backend determines which catalog is compatible and selects that catalog for the UI surface.
3. The backend already has the corresponding catalog definition/schema available for that catalogId.
4. The LLM is constrained using that catalog's schema/instructions and generates A2UI output according to the selected catalog.
5. The generated A2UI messages include the selected catalogId, so the renderer knows how to resolve the components.

So with LangGraph/LangChain, I would probably keep a mapping such as:

catalogId -> catalog definition -> validation/structured-output schema

rather than regenerating the Pydantic classes and A2UI schema on every request.

Also, I don't think A2A is a requirement for the concept itself. A2A provides one way to exchange the capability information, but the same negotiation idea can be implemented in another transport/session layer as long as the client and agent agree on the supported catalog IDs.

The static-schema example can therefore still work: the schema is static for a particular catalog. Catalog negotiation determines which catalog/schema should be used for that interaction or surface.

The main difference I see from your proposed flow is that step 3 is more "select the existing catalog/schema associated with the negotiated catalogId" rather than "re-generate the schema dynamically."