Improve orchestration output serialization #7
Conversation
# Conflicts: # azure/durable_functions/openai_agents/decorators.py # azure/durable_functions/openai_agents/model_invocation_activity.py
Signed-off-by: Phillip Hoff <[email protected]>
…tion Signed-off-by: Phillip Hoff <[email protected]>
Signed-off-by: Phillip Hoff <[email protected]>
Signed-off-by: Phillip Hoff <[email protected]>
@philliphoff Do I understand it correctly that this is not about an Agent instance output, but about orchestrator function output? In this case, I'm a bit worried about us special-casing this specifically for the OpenAI integration. Someone could try to return objects of this kind from a regular orchestrator, and now they will suddenly encounter a different behavior. If returning objects like this is common (but still not mandatory) in OpenAI Agents scenarios, perhaps we should expose the serializing utility as public API, so that the user can be explicit about this choice? |
@AnatoliB It was common enough to be the cause of all of the broken samples, which followed a pattern of returning the I don't like exposing this (only) as a public API as it'd not be very discoverable, in particular, to OpenAI developers. (I'd rather instead push the DF SDK to do similar serialization under the covers.) |
|
@philliphoff Ok, this is fair, let's go with what you've implemented and perhaps adjust the regular DF SDK to match this behavior later. |
2 participants
Allow developers to return "raw" agent output from orchestrations rather than be forced to deal with specific Durable semantics (i.e. that orchestrations must return strings even though activities can return objects (that meet certain requirements)).
Now, if an agent returns a Durable model, Pydantic model, or typed dictionary, the object will be implicitly serialized to a string.