Thoughts to improve the tool caller #237
Replies: 1 comment
-
@ElisonSherton Awesome detailed write-up, thank you! Regarding the second issue, I have implemented a fix for this and it will be released in Regarding the first issue with ToolInsights, this is an extremely useful idea that I think needs to (and will) be a first-class feature in the engine. I'll find time soon to expand this part into a new discussion with a design proposal for ToolInsights. I will also try to prioritize this feature as I think it's a game-changer that's perfectly aligned with our "guided tool use" paradigm. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
TLDR
For First Point
Motivation
I am working on a bot which is supposed to do a task of credit card bill payment. You could find the code and the instructions to run the same here.
Here is how a conversation to make a payment to the credit card happened
Here are the guidelines for quick reference

Now, here look at the last message generated by the bot. If we actually inspect this message by going into the session logs, we find this
Further if we look at the tool caller inspection completion log, we find this
Now, the issue here is that the tool caller inferred the
payment_date_provided_by_customer
andpayment_source
on it's own without actually asking for these fields explicitly from the user. While this may be useful in some cases, we need a way to enforce the bot to ask for certain arguments before actually making a tool call because they are not to be inferred automatically from the context. Things like payment date and the sender's account etc. are really critical pieces which MUST come from the user. This is what motivated the need for the first topic in the TLDR; section above.Now, just hypothetically saying, consider a scenario where a user is asking questions about credit cards and just mentions that he has a
parlant-premium-card
in the passing. Then he digresses and then he comes back and asks a very generic question likeWhat is the rate of interest on credit cards nowadays?
Now let's say we have a tool,fetch_roi_of_card
which given a credit card type as a string input, outputs the rate of interest of that card by fetching it from the DB. Here, if the engine infers that the user talked about aparlant-premium-card
earlier and uses this card in the tool to fetch it's rate of interest and presents it to the user, it is OK. Although the user might have 10 other cards but the fact that bot inferred the card type to beparlant-premium-card
is not so bad. This could be an example of where inferring the tool arguments based on context could be considered alright.Current Behaviour
In Tool calling, even if we have specified a particular argument of a given tool as required for that tool to get executed, and the user has not explicitly provided that argument, the tool caller sometimes assumes the value and proceeds with the tool calling.
Desired Behaviour
Any developer using parlant's tool calling service should be able to do the following
This will enable a developer to bring about determinism in their tool calling workflows rather than being at the mercy of the spurious generations that the LLM may come up with for certain arguments in the tool.
For Second Point
Now refer this code to reproduce the error below.
Consider the same task which I was trying to do above i.e. making a payment to a credit card. Here is the conversation

Here is the log of everythin that happened during the last message generation step
Here is the log for Tool Calling and Message Generation for the last message in even more detail
As seen above, the tool caller failed because of the validation step present in
card_service:make_payment
tool where we assert that the date of payment should be in the future i.e. not today or in the past.Firstly, the payment date is wrongly made up/assumed by the tool caller. That aside, now look at the next issue. We see that the tool caller gets called and it fails on a certain validation step. This happens for all the three iterations (we have set max engine iterations to 3).
Now, the message generator does not get the fact that the tool caller was called and that the validation for payment date has failed. Knowing this information may help guide the message generation step better is what I think. Any thoughts on this are welcome.
Beta Was this translation helpful? Give feedback.
All reactions