RFD: introduce messageId field
#244
Conversation
…essage-id docs(rfd): introduce messageId field
Nemtecl
changed the title
messageId field
|
|
||
| The **Agent generates all message IDs**, for both user and agent messages: | ||
|
|
||
| - **For user messages**: When the Client sends `session/prompt`, the Agent assigns a message ID and returns it as `messageId` in the response |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
benbrandt
left a comment
benbrandt
left a comment
There was a problem hiding this comment.
Nice start! I have a few comments, but I think this is definitely a much needed feature
|
|
||
| ## What we propose to do about it | ||
|
|
||
| Add a `messageId` field to `AgentMessageChunk` and `UserMessageChunk` session updates, and to the `session/prompt` response. This field would: |
There was a problem hiding this comment.
I agree with @anna239 here... I am unclear on why a session/prompt response would need a messageId?
If anything that would feel more like a "turnId" which I'm not sure if that would always hold up either.
Basically a prompt would create one or more "messages" , which would happen via the chunks, and then I don't think we need anything on the prompt, unless I am missing something.
We could introduce a new session/update type of "message start" and "message end" if needed to carry extra metadata... but I am not sure how useful that is and would hold off unless we have a strong reason to do it.
I think as proposed this ultimately has similar behavior to now (you have to watch the chunks for a new message id) but does allow you to split messages of the same type, which is useful.
And it creates a nice anchor for other features as you mentioned
| - **Unique per message** within a session | ||
| - **Stable across chunks** - all chunks belonging to the same message share the same `messageId` | ||
| - **Opaque** - Clients treat it as an identifier without parsing its structure | ||
| - **Agent-generated** - The Agent generates and manages all message IDs, consistent with how the protocol handles `sessionId`, `terminalId`, and `toolCallId` |
There was a problem hiding this comment.
How do we handle messageIds for user messages? Are they generated by the client?
The agent is also allowed to supply user messages, it is true, but I feel we need to also allow the user messages from the prompt to have an id as well
If we allow both sides to generate though, we may need to require something like a uuid or have a prefix or something to avoid collisions
| ### Phase 1: Core Protocol Changes | ||
|
|
||
| 1. **Update schema** (`schema/schema.json`): | ||
| - Add required `messageId` field (type: `string`) to `AgentMessageChunk` |
There was a problem hiding this comment.
To make this a non-breaking change, we will need to have this be optional for now.
We can add SHOULD language to the spec, but changing that to a MUST/required will need to be a v2 change
|
|
||
| Alternatively, the field could initially be made **optional** to allow gradual adoption: | ||
|
|
||
| - Agents that support it advertise a capability flag during initialization |
There was a problem hiding this comment.
I think we can do optional, and then features that require a messageId would have an implicit flag in the sense that those methods would require a messageId and you wouldn't have one
|
|
||
| The **Agent generates all message IDs**, for both user and agent messages: | ||
|
|
||
| - **For user messages**: When the Client sends `session/prompt`, the Agent assigns a message ID and returns it as `messageId` in the response |
There was a problem hiding this comment.
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.
|
|
||
| - Tool calls use `toolCallId` | ||
| - Plan entries can be tracked by their position in the `entries` array | ||
| - Agent thoughts could benefit from message IDs if they're considered distinct messages |
There was a problem hiding this comment.
What is the reason not to add it to thoughts now? Wouldn't you also want some distinction there?
And could one message contain two tool calls?
I guess I am realizing it would make sense to better define what a "message" is in the protocol, and that might better guide which things need or don't need a message id
3 participants
This document proposes the addition of a
messageIdfield so that we can identify user and assistant message