How should components and dataModel be represented in multi-turn agent conversation history?

[zhangHongEn]

How should components and dataModel be represented in multi-turn agent conversation history?

I'm trying to understand the intended way to integrate A2UI responses into a multi-turn agent conversation.

Suppose the user asks for a list of orders, and the agent responds with both dataModel and components:

Turn 0

messages = [
  user: "Query my orders",

  assistant: {
    dataModel: [
      { id: "order1", ... },
      { id: "order2", ... }
    ],
    components: {
      ...
    }
  }
]

On the next turn, the user refers to something rendered by the previous A2UI response:

user: "Cancel the first order"

For the next agent/LLM invocation, is the intended approach to preserve only the semantic/data state from the previous A2UI response and omit the component tree?

For example:

Turn 1

messages = [
  user: "Query my orders",

  assistant: {
    dataModel: [
      { id: "order1", ... },
      { id: "order2", ... }
    ]
  },

  user: "Cancel the first order"
]

instead of replaying the full A2UI response:

messages = [
  user: "Query my orders",

  assistant: {
    dataModel: [...],
    components: {...}
  },

  user: "Cancel the first order"
]

My assumption is that components mainly represents presentation/rendering state, while dataModel contains the semantic state needed to resolve references such as "the first order".

So my questions are:

1. Is it correct to omit components from subsequent conversation history and retain only dataModel?
2. Does A2UI have a recommended representation for previous A2UI responses when constructing the next agent/LLM request?
3. Should dataModel be considered sufficient conversational context for references to previously rendered entities, or is the application expected to maintain a separate semantic/conversation state?
4. Is conversation-history management intentionally outside the scope of A2UI?

I'm specifically asking about the agent/LLM conversation context across turns, rather than how A2UI surface updates are transported to the renderer.

[identity-wael]

You can keep a compact semantic snapshot in the next LLM request, but dataModel alone is sufficient only if it preserves what the user actually saw and can refer to.

For your example, I would retain the displayed order IDs in display order, along with the relevant order data and surface ID. If the UI sorts, filters, or paginates the orders, “the first order” need not mean the first entry in the original data array. That mapping is application state worth preserving even when you omit the component tree from the prompt.

There are two separate concerns here:

• LLM context: a compact snapshot can replace replaying all presentation JSON. My reading of the protocol is that it does not prescribe a particular conversation-history representation; this is an agent/application design choice.
• Surface state: retain the component/data state somewhere outside the prompt. If the next turn needs to patch the existing UI, provide the agent with the relevant component IDs, bindings, and current values rather than expecting it to reconstruct them from order data alone.

One relevant protocol feature is v0.9 createSurface.sendDataModel: when enabled, the client includes the surface’s current data model in metadata on messages to the server. That helps with user-edited values; it is not a rule requiring you to copy that entire payload into LLM history. Check your protocol/renderer version before relying on it.

For an explicit Cancel button, bind a stable order ID into its action context. For free-text “cancel the first order,” resolve against the displayed snapshot, and have the backend check ownership and whether cancellation is still allowed. So I would use your compact approach, with that display/reference state retained rather than assuming raw business data always captures it.