ConversationMessage has no stable id, causing duplicate/out-of-order messages in AG-UI frontends for conversational Flows

Finding: In an external report, a crewAI conversational Flow served over AG-UI with ag-ui-crewai (conversational=True) reportedly shows duplicated or out-of-order chat messages in CopilotKit/AG-UI frontends, because historical messages get a new random id on every MESSAGES_SNAPSHOT rebuild. Reported versions: crewai 1.15.22, ag-ui-crewai 0.3.1, @ag-ui/client and core 1.0.2, @ag-ui/crewai 0.0.4, @copilotkit/react-core and runtime 1.77.0 (https://github.com/crewAIInc/crewAI/issues/7924). This is an external report; KFA did not reproduce it. Reported mechanism (hypothesis from the reporter's source reading, not maintainer-confirmed): ConversationMessage has no id field, and litellm_messages_to_ag_ui_messages backfills a fresh uuid4 whenever id is missing. As a result the same message gets a different id in each snapshot. The reporter says the AG-UI client merges snapshots by id, so unstable ids make it append copies rather than update in place (https://github.com/crewAIInc/crewAI/issues/7924). The reporter also points to an existing ag-ui-crewai patch that preserves the id of only the current turn's user message. Per the reporter, assistant replies and earlier user messages remain unstable. Reported reproduction: serve a conversational Flow through add_crewai_flow_fastapi_endpoint, drive it from a CopilotKit frontend, send two messages in one thread, and inspect the outgoing messages or rendered chat. The reporter says identical role/content appear with different ids. The reporter says a backend-only comparison of ids across snapshots shows the same thing. Status: the issue is open. A contributor commented that ConversationMessage should keep a stable id from creation so later snapshots can reuse it (https://github.com/crewAIInc/crewAI/issues/7924#issuecomment-6026673636). That is intent to investigate, not a confirmed cause, fix, or release. No fix commit or released version appears in the supplied sources. Diagnosis, conditional: if you run this stack and see duplicates whose content matches but whose ids differ between snapshots, this report's explanation is a candidate cause. The reporter's proposed direction is a stable per-message id assigned once at creation, which is not implemented in any supplied source. Workarounds: the reporter found no application-side workaround. Excluding messages from state serialization reportedly does not affect MESSAGES_SNAPSHOT and can break persistence round-trips. The CopilotKit messageFilter reportedly only trims the outbound request. Treat these as the reporter's claims, unverified by KFA. Limitations: single external report, no independent reproduction, third-party client behavior taken from the reporter, and middle comments may be missing from the supplied timeline.