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
First of all thank you for your well designed project!
I would propose to add some additional fields to the prompt management of type chat.
When developing projects around tool calling and Agent workflows there is often a need for few-shot prompting with tool calling examples and the appropriate tool response message. Right now I have to use the config field and create the message object at runtime. Moreover, if observed that I can add a message with role "tool" in via Python SDK but not in the UI.
Requirements:
Adding "Tool" Role to ChatMessage with additional argument "tool_call_id"
Adding "tool_calls" as an argument to assistant message
Adding "name" argument to all messages (to specify e.g. "example_assistant" & "example_user" according to OpenAI docs)
Suggestion
Since from current implementation there is no differentiation between arguments/fields and the message type I would be sufficient to stick with "role" and "content" and just add something like "additonal_kwargs" in the backend and the possibility to add more fields in the frontend.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Describe the feature or potential improvement
First of all thank you for your well designed project!
I would propose to add some additional fields to the prompt management of type
chat
.When developing projects around tool calling and Agent workflows there is often a need for few-shot prompting with tool calling examples and the appropriate tool response message. Right now I have to use the config field and create the message object at runtime. Moreover, if observed that I can add a message with role "tool" in via Python SDK but not in the UI.
Requirements:
Suggestion
Since from current implementation there is no differentiation between arguments/fields and the message type I would be sufficient to stick with "role" and "content" and just add something like "additonal_kwargs" in the backend and the possibility to add more fields in the frontend.
Thanks.
Additional information
No response
Beta Was this translation helpful? Give feedback.
All reactions