RFD: introduce messageId field

[Nemtecl]

This document proposes the addition of a messageId field so that we can identify user and assistant message

[anna239]

But a response to the session/prompt comes only after all session\update messages are streamed https://agentclientprotocol.com/protocol/prompt-turn . We also plan to support user messages in the middle of the agent's interactions, in this case it's also not clear how to return messageId to the client.
I like your proposal a lot, but this particular part about server generating client messages' ids looks a little cumbersome to me

[benbrandt]

Agreed. An alternate approach could be to introduce a new session/update that assigns it... But I wonder if we just need a way to get unique ids from both sides.

[anna239]

Strictly speaking, you want them to be unique only among client\server messages. A message role (user/assistant) can be treated as a part of the id, but this complicates things in the scenario with multiple clients. But probably we can be safe just having UUIDs there, wdyt?

[Nemtecl]

Thanks for the great discussion, everyone!

Using a session/update mechanism like user_message_chunk to echo messages with IDs would create a mapping challenge: how would clients reliably link IDs to their original messages? Content matching isn’t foolproof, so PromptResponse avoids this issue entirely

We could let the client set a temporary messageId, then have the agent update it via session/update with a permanent one. But is everyone comfortable with the client assigning any ID, even temporarily? No strong opinion on my side

For mid-turn user messages, we can address ID assignment during that feature’s design. For now, let’s focus on what’s concrete and avoid over-engineering for hypotheticals 🙏 ?

Open to all suggestions and compromises to keep this RFD progressing! 🚀

[benbrandt]

Nice start! I have a few comments, but I think this is definitely a much needed feature

[benbrandt]

Agreed. An alternate approach could be to introduce a new session/update that assigns it... But I wonder if we just need a way to get unique ids from both sides.

[Nemtecl]

Hey everyone, really sorry for the delay, we've been super focused on Mistral Vibe release 🙇

I tried to answer most of the comments, hope we are close to have a consensus and merge 🙏

[Nemtecl]

Thanks for the great discussion, everyone!

Using a session/update mechanism like user_message_chunk to echo messages with IDs would create a mapping challenge: how would clients reliably link IDs to their original messages? Content matching isn’t foolproof, so PromptResponse avoids this issue entirely

We could let the client set a temporary messageId, then have the agent update it via session/update with a permanent one. But is everyone comfortable with the client assigning any ID, even temporarily? No strong opinion on my side

For mid-turn user messages, we can address ID assignment during that feature’s design. For now, let’s focus on what’s concrete and avoid over-engineering for hypotheticals 🙏 ?

Open to all suggestions and compromises to keep this RFD progressing! 🚀

[benbrandt]

@Nemtecl @anna239 been thinking about this... What do you all think about only supplying message ids for agent messages for now?

Would this solve enough problems without creating new ones?
I think getting ids for user messages is going to be a bit tricky... but I wonder if we can make progress by at least introducing message ids for the agent side?

[denofevil]

@benbrandt by looking at the elevator pitch, we need to identify client messages, not just agent ones:

lays the groundwork for future capabilities like message editing.

We're looking also at messageId for the purpose of deduplicating messages on session/load (and echoing client prompt to multiple clients, I'll be drafting that shortly). I suppose we can kill two birds with one stone here if we agree on the id generation scheme, e.g. both sides could generate them as UUID.

[benbrandt]

@denofevil the issue I have is that not all agents (such as codex) allow for passing user message ids in.
It's possible we can hope for the best, but would need some work to make sure this is reliable enough for all of the operations you want to do

[denofevil]

I might be not seeing the whole picture here. AFAIU codex goes through an adapter, adapter can just don't pass messageId to the agent. If we're speaking about editing the message, I suppose that would be under an agent's capability anyway

[Nemtecl]

Hi @benbrandt and @denofevil 👋

I agree with @denofevil’s perspective. This will not only enable message identification but also unlock other features, such as edit functionality

For agents that don’t yet support messageId, we could introduce an agent capability flag for feature that need message id. Clients could then fall back to alternative workflows, such as fork sessions, to maintain compatibility while encouraging adoption of the new standard

As a first step, I’m open to making the messageId configurable, either generated by the client or the agent, using a UUID format. This flexibility should help ease the transition and accommodate different implementations

Let me know if this aligns with your vision, and I’m happy to address the changes !

[benbrandt]

@Nemtecl right but I guess you can also implement edit (this is how we do it in zed and codex seems to do something similar) by truncating the message history to before the user message (basically an inclusive index of the agent message id) and then submit the new user message with the edited text.

So I feel like we could still support a lot of these flows with just agent message ids. The replay aspect @denofevil brings up makes sense though.

I am fine with aligning on uuids. Regarding capabilities, this makes sense. This feels like something we could make mandatory in a major version bump, but we'll need to make opt-in for now.

If you dont' mind doing one more round of updates to the RFD, we can likely move to draft stage and see what issues we run into with implementation