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
The LLM always gets returned a string, which is my assumption why currently all internal representations of a tool call result are simply a string.
The motivation for the change in the title, would be that hooks which make use of a tool result callback, could differentiate between a successful and a failed tool call. This could be rather hard with tools which define a custom Error type, which the callback can't be generic over. But even then we could store the tool call as Result<String, String>, such that the information of failure would be preserved.
Is this something we'd want to have? Are there design issues which would block this?
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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The LLM always gets returned a string, which is my assumption why currently all internal representations of a tool call result are simply a string.
The motivation for the change in the title, would be that hooks which make use of a tool result callback, could differentiate between a successful and a failed tool call. This could be rather hard with tools which define a custom Error type, which the callback can't be generic over. But even then we could store the tool call as
Result<String, String>, such that the information of failure would be preserved.Is this something we'd want to have? Are there design issues which would block this?
All reactions