Can I retrieve an existing thread on OpenAI with the new Agents framework #6317
-
|
Use Case: I think I need to be able to instantiate an OpenAI AgentGroupChat with a thread id that already exists so that I can use it for the InvokeAgentAsync message. I admit I am still trying to figure this new framework out, but could use some direction here. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
|
@crickman, do you know if this is possible today? I know we're still working on enhancements to make it easier to serialize and deserialize group chats. I suspect this may be one of the additional gaps necessary to rehydrate an existing thread. |
Beta Was this translation helpful? Give feedback.
-
|
This is not possible today. As we discussed in early May, I have some thoughts on how this might be solved. |
Beta Was this translation helpful? Give feedback.
-
|
This isn't currently supported, but it is on our radar. I have a notion on how this might be supported, but need to coordinate with Matthew's work once he's back in the office. One thing to consider is that the Agent Framework isn't soley supporting the Open AI Assistant API. This means that a solution that supports serialization/deserialization must be valid across different agent modalities. Since an agent is able to participate in multiple converations / chats, managing thread-id it feels like this support may be logically bound to the chat contract (as opposed to agent). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Is there an architecture document somewhere that explains your overall direction? There was a design document early but looks like it’s gone now. appreciate all of your work on this. To get past our need, I have written a .net service to manage the new assistant streaming api on OpenAI. The .net SDK had not yet added support for it, but I assume they will get there at some point. We still plan to use agents that are not openai assistants, so definitely looking forward to understanding how your framework is going to be designed. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, there is a pending ADR; however, its focus is on what currently exists. I suspect serialization / deserialization may become its own ADR. I'm eager to coordinate with Matthew's thoughts around this and certainly have some notion of what may be required. However, I'm cautious to get out too far in front of my ski's in the absence of knowing what Matthew may be thinking. |
Beta Was this translation helpful? Give feedback.
-
|
multi agent is nice and all, but can we get “Normal” assitant v2 support in semantic kernel without multiagent abstraction? One nice feature of assistant api (including v2) is that it saves threads automatically so you can save conversation without additional effort, but that’s been “abstracted away” in semantic kernel and you can’t recover a thread: it’s created automatically under the hood and you can’t recover it assistant v2 with file search is very powerful and it would be nice to have sematic kernel power to use plugins. That should be your priority in my opinion. Not multiagent BEFORE fully supporting assistant api v2 |
Beta Was this translation helpful? Give feedback.
-
|
We've added support to directly invoke the assistant agent and explicitly manage the thread-id: Assistant V2 features are just around the corner. |
Beta Was this translation helpful? Give feedback.
-
|
this is VERY nice! I've tested it with plugins too. Can we get streaming :) ? |
Beta Was this translation helpful? Give feedback.
This isn't currently supported, but it is on our radar. I have a notion on how this might be supported, but need to coordinate with Matthew's work once he's back in the office.
One thing to consider is that the Agent Framework isn't soley supporting the Open AI Assistant API. This means that a solution that supports serialization/deserialization must be valid across different agent modalities. Since an agent is able to participate in multiple converations / chats, managing thread-id it feels like this support may be logically bound to the chat contract (as opposed to agent).