Conversation history via AG-UI

[jiapingzeng]

Hello everyone, wondering if there is a recommended approach to building conversation history via AG-UI? I have a few questions and would love to hear how others are solving these.

1. How does the frontend retrieve a list of saved conversations (list of threadId)?
2. On a new page load, let's say we already retrieved a threadId that contains previous chat history. How would frontend ask the backend to retrieve previous history based on the threadId, when the user has not yet typed a new question?
3. Does frontend still need to send the full messages array on every request if the previous messages are stored in backend?

[fjgbue]

I would treat threadId as the durable conversation id and keep the conversation index outside the agent run itself, usually in your app or backend database.

For the three questions:

1. The frontend should retrieve saved conversations from an app-owned endpoint such as GET /threads. AG-UI gives you the protocol shape for running agents and streaming state, but the list of available saved conversations is normally product/application state.

2. On page load, if the frontend already has a threadId, it can call something like GET /threads/:threadId and hydrate the UI from stored messages or from a compacted AG-UI event stream. A good backend shape is to store events append-only by threadId, then return a compacted representation such as MESSAGES_SNAPSHOT plus STATE_SNAPSHOT for reload.

3. If the backend is the source of truth, the frontend does not need to send the full historical messages array on every request. It can send the threadId and the new user message, and the backend can reconstruct prior context from storage before invoking the underlying agent. If your backend is stateless, then yes, the frontend has to send enough message history for the agent to continue.

So the practical pattern is: store by threadId, index individual runs by runId, compact/replay events for hydration, and decide whether the frontend or backend owns history depending on whether your backend is stateful.

[langovoi]

But MESSAGES_SNAPSHOT event doesn't store runId, so messages can't be restored with reference to original run.
And without runId it is not possible to make features like regenerate, feedback (like / dislike) and branching, because every message from MESSAGES_SNAPSHOT becomes separate item on frontend side.

[uesleilima]

We've implemented the pattern @fjgbue describes, with a few concrete choices that may help others — and clear labels for what is protocol vs application.

1. Listing conversations

Agree this is application state, not AG-UI core. We expose a threads list endpoint (filterable metadata, pagination) owned by our backend. AG-UI does not need to standardize a thread index to be useful.

2. Hydrating history on page load (no new user message)

We use a dedicated state read:

• POST /agents/{name}/state → threadExists, state, messages (AG-UI message objects)
• Inspired by the ag-ui-adk experimental /agents/state route, adapted for LangGraph checkpoints

Protocol divergence: this is not a core AG-UI operation. It is the same class of out-of-band convenience discussed in #1827 (run_mode: "sync") and #971. A first-class sync/run intent would be preferable long-term so clients are not split across "run" and "state" APIs.

For reconnecting to a still-running turn we additionally return an activeRunId from that state read and reattach via an application convention on the normal run POST (forwardedProps.reattach). That reattach path is also outside the protocol today (see the reserved resumable discussion in #2161).

3. Sending full messages[] every request?

With a stateful LangGraph checkpointer, the backend is source of truth for history. The client still typically sends recent messages for the current turn (and for edit/regenerate detection), but it should not need to resend the entire transcript every time. Be aware: until the protocol gets an explicit rewind/fork anchor (#2161), adapters often infer edit/regenerate by diffing those inbound messages against the checkpoint — which is fragile around interrupts and dirty checkpoints.

Happy to answer follow-ups on the ADK-inspired /state shape specifically.

[kasuteru]

Just wanted to chime in that I think AG-UI should attempt to propose a standard for all of this as well. Backends / Apps could still ignore that standard and use their own, but currently, probably every single company / team implementing AG-UI is creating their own API endpoints for CRUD operations on threads, since everyone needs conversation history.

Happy to involve myself in any discussions about making this a standard. We are internally working on creating our own - ideally of course, we would like to align this with a general AG-UI standard so that we stay compatible with FOSS frameworks.