You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
.NET: Python: suggestion - add clear_messages() method to ChatMessageStoreProtocol #1712
The ChatMessageStoreProtocol currently defines methods for adding and listing messages, but lacks a method to clear/delete all messages. This is needed for common use cases like:
User-initiated conversation resets
Cleaning up test data
Implementing privacy/data retention policies
Starting fresh conversations in chat applications
Proposed Solution:
Add the following method to ChatMessageStoreProtocol:
asyncdefclear_messages(self) ->None:
""" Clear all messages from the message store. This method should remove all persisted messages, allowing the conversation to start fresh. """
...
Workaround:
Currently using an extended protocol in my codebase:
changed the title [-]Python: suggestion - add clear_messages() method to ChatMessageStoreProtocol[/-][+].NET: Python: suggestion - add clear_messages() method to ChatMessageStoreProtocol[/+]on Oct 28, 2025
The ChatMessageStore is really not intended to be a full abstraction for managing chat history. We need to reconsider its name to make it clear that it is really just about providing a view of the chat history required by the agent for execution, plus appending messages produced by the agent.
While it is of course possible to create a fully fledged Chat History storage abstraction with full CRUD support, that would be a separate feature and outside the scope of this abstraction.
The protocol already defines full state management, not just a "view", through methods like serialize(), update_from_state(), and deserialize(). More importantly, the framework's own implementations already provide clear_messages() functionality: the Python RedisChatMessageStore explicitly documents "DELETE: Clear all messages for a thread" as a core feature, while the .NET CosmosChatMessageStore and InMemoryChatMessageStore both implement ClearMessagesAsync() and Clear() respectively. Adding clear_messages() to the protocol simply makes this existing capability explicit rather than expanding scope, eliminating inconsistency and the need for custom wrapper protocols when users implement their own stores (and implementing own stores through which chat history is persisted and managed is a promoted feature of agent-framework based on examples and provided redis store).
My specific use case is actually tied to Microsoft Teams chat design limitations, which does not enable users to have several chats using one "chat app" and only enables users to clear chat history with deleting the said chat bot from the list of chats. This would obviously be bad UX and my solution was to enable users to reset LLM chat memory using a message, which is also not the best UX, but better. It also preserves whole history of previous conversations which somewhat mitigates not being able store separate chats. It is not like Agent Framework should concern itself with issues of Microsoft Teams, but I just wanted to outline example use case of enabling a user conversing with agent not only to "add_messages" and "list_messages" but also to "clear_messages".
We've just redone the context provider/history provider setup for both .Net and python and it is clearer now that it is read and write, not full CRUD, off course this does not prevent individual implementors of HistoryProviders from adding additional functionality, but we will not have an abstraction for that at this time. If you feel this is still needed please let us know and we will consider it.
Activity
[-]Python: suggestion - add clear_messages() method to ChatMessageStoreProtocol[/-][+].NET: Python: suggestion - add clear_messages() method to ChatMessageStoreProtocol[/+]westey-m commentedon Jan 7, 2026
The ChatMessageStore is really not intended to be a full abstraction for managing chat history. We need to reconsider its name to make it clear that it is really just about providing a view of the chat history required by the agent for execution, plus appending messages produced by the agent.
While it is of course possible to create a fully fledged Chat History storage abstraction with full CRUD support, that would be a separate feature and outside the scope of this abstraction.
anguzo commentedon Jan 7, 2026
The protocol already defines full state management, not just a "view", through methods like serialize(), update_from_state(), and deserialize(). More importantly, the framework's own implementations already provide clear_messages() functionality: the Python RedisChatMessageStore explicitly documents "DELETE: Clear all messages for a thread" as a core feature, while the .NET CosmosChatMessageStore and InMemoryChatMessageStore both implement ClearMessagesAsync() and Clear() respectively. Adding clear_messages() to the protocol simply makes this existing capability explicit rather than expanding scope, eliminating inconsistency and the need for custom wrapper protocols when users implement their own stores (and implementing own stores through which chat history is persisted and managed is a promoted feature of agent-framework based on examples and provided redis store).
My specific use case is actually tied to Microsoft Teams chat design limitations, which does not enable users to have several chats using one "chat app" and only enables users to clear chat history with deleting the said chat bot from the list of chats. This would obviously be bad UX and my solution was to enable users to reset LLM chat memory using a message, which is also not the best UX, but better. It also preserves whole history of previous conversations which somewhat mitigates not being able store separate chats. It is not like Agent Framework should concern itself with issues of Microsoft Teams, but I just wanted to outline example use case of enabling a user conversing with agent not only to "add_messages" and "list_messages" but also to "clear_messages".
eavanvalkenburg commentedon Feb 13, 2026
We've just redone the context provider/history provider setup for both .Net and python and it is clearer now that it is read and write, not full CRUD, off course this does not prevent individual implementors of HistoryProviders from adding additional functionality, but we will not have an abstraction for that at this time. If you feel this is still needed please let us know and we will consider it.