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
This release addresses the request related issues brought up here regarding the use of multiple "meta" id's and the semantics of automatic responses to messages. Shoutout to @wwj718 for the great feedback for these updates!
Since this includes breaking changes, the version has been bumped to 1.5.0.
Summary:
All messages now populate the meta.id field with a UUID by default. Agents may set their own custom meta.id upon sending to overwrite the generated ID.
In addition, Agent.send() now returns the meta.id of the sent message. This way you may store the generated ID for your own purposes.
Removed the use of meta.response_id and meta.request_id. These have been replaced by meta.parent_id. I think the term "parent" is clearer. This choice is inspired by the Jupyter messaging docs.
To be clear, meta.parent_id if set, refers to the meta.id of the original message which the current message is responding to.
To illustrate, the following would be typical meta fields in a send/response pair:
# send
{
"meta": {
"id": "123", # the message ID here
},
...
}
# response
{
"meta": {
"id": "456", # response has its own unique meta.id"parent_id": "123", # refers to the prior message
},
...
}
All messages will now result in a [response] message like the above, returning the return value or error result from the message's action. These messages (unless using the request() method) will invoke the handle_action_value() and handle_action_error() methods appropriately.
One might want to filter these messages from view in a user interface. The demo Gradio app has been updated to demonstrate this. See the _should_render() and get_chatbot_message() methods for an example.
Agent.original_message() has been renamed to Agent.parent_message(). Additionally parent_message() takes a message as a parameter, allowing you to traverse a chain of messages in reverse.
Internally renamed Agent._pending_responses to Agent._pending_requests which I think is clearer.
The logger has been updated to provide colorization of output for easier reading. You may change the default "monokai" pygments style used for object output, by setting the LOG_PYGMENTS_STYLE environment variable.
Log "warning" messages for unimplemented handle_action_value and handle_action_error methods have been updated to only print once per session, in order to reduce logging noise in the default setting.
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
-
https://github.com/operand/agency/releases/tag/v1.5.0
This release addresses the request related issues brought up here regarding the use of multiple "meta" id's and the semantics of automatic responses to messages. Shoutout to @wwj718 for the great feedback for these updates!
Since this includes breaking changes, the version has been bumped to 1.5.0.
Summary:
All messages now populate the
meta.id
field with a UUID by default. Agents may set their own custommeta.id
upon sending to overwrite the generated ID.In addition,
Agent.send()
now returns themeta.id
of the sent message. This way you may store the generated ID for your own purposes.Removed the use of
meta.response_id
andmeta.request_id
. These have been replaced bymeta.parent_id
. I think the term "parent" is clearer. This choice is inspired by the Jupyter messaging docs.To be clear,
meta.parent_id
if set, refers to themeta.id
of the original message which the current message is responding to.To illustrate, the following would be typical meta fields in a send/response pair:
All messages will now result in a
[response]
message like the above, returning the return value or error result from the message's action. These messages (unless using therequest()
method) will invoke thehandle_action_value()
andhandle_action_error()
methods appropriately.One might want to filter these messages from view in a user interface. The demo Gradio app has been updated to demonstrate this. See the
_should_render()
andget_chatbot_message()
methods for an example.Agent.original_message()
has been renamed toAgent.parent_message()
. Additionallyparent_message()
takes a message as a parameter, allowing you to traverse a chain of messages in reverse.Internally renamed
Agent._pending_responses
toAgent._pending_requests
which I think is clearer.The logger has been updated to provide colorization of output for easier reading. You may change the default "monokai" pygments style used for object output, by setting the
LOG_PYGMENTS_STYLE
environment variable.Log "warning" messages for unimplemented
handle_action_value
andhandle_action_error
methods have been updated to only print once per session, in order to reduce logging noise in the default setting.Tests and documentation updated.
Beta Was this translation helpful? Give feedback.
All reactions