current state context provider added

Author: eavanvalkenburg

docs/decisions/00XX-python-agent-threads.md

@@ -17,10 +17,11 @@ Currently in Python we use `threads` in the following way: we have a single thre
 - However before all of that a thread is `uninitialized`, meaning it has neither a `ChatMessageStore` nor a `service_thread_id`.
 - It also has a method called `on_new_messages` which does nothing when called to a thread that has a `service_thread_id`, but when called to a thread that has a `ChatMessageStore`, it will call the `add_messages` method of the `ChatMessageStore` instance.
 This all means that at various moments a thread can be different things and have different behaviors, which can be confusing for users. It is also unclear which chat clients can support which type of thread, and what the implications are of using one or the other, in combination with the `store` parameter.
-- We currently do not have additional thread types, such as a A2AAgentThread, which has a TaskID in addition to a service_thread_id.
+- In Python, we currently do not have additional thread types, such as a A2AAgentThread, which has a TaskID in addition to a service_thread_id.
 - `ChatMessageStore` is mostly used as a simple list of `ChatMessage` instances, but can also have additional logic, such as persisting messages to a database, or loading messages from a database.
 - There is a proposal to add a `AgentThreadStore` abstraction and a in-memory implementation, which would further complicate the current `AgentThread` class, this adds a id and save and load methods.
 - Currently the thread is updated by the agent, based on the outcome of the whole run, so if the underlying chat client does function calling, we won't get the intermediate messages in the thread until the end of the run, this has raised a question as well, as users would like to have the thread updated during the run, so that they can see the intermediate messages, however this runs the risk of ending up with a thread that is not usable anymore, for instance because it is missing chunks (when streaming) or does not have function call results matching the function calls.
+- Context providers are currently added to the thread, they are stateful, for instance when you want to use a context provider to summarize it needs the last couple of messages, and because a service side thread does not hold that, the context provider needs to store those messages itself. This makes serializing and deserializing threads more complex as well, as the context providers need to be serialized as well, including both the state of this particular thread and the internal logic and configuration of the context provider itself.
 
 Current (simplified) state for a AgentThread with a ChatMessageStore in Python:
 ```mermaid