I'm setting up a tool to make sure the agent has context when fielding inbound calls. The tools is findContactDetails, and it should pull all the details such as first name, email, phone #, call conversation history, text message history etc. In a perfect world, just like a human, for an inbound call, the agent could just take a quick glance at the prospect info and know it for the rest of the conversation without even bringing this up to the prospect of having done so. And this feels to me the purpose of async tools. But right now, when it's toggled on, the response can be sent to the agent, however the agent isn't able to access it (or at the very least communicate to the prospect that it has access to it) which IMO seems like it entirely defeats the purpose. Before posting this, it looks like this surfaced at least 5 times and goes back to even July. And it seems like the agent not responding with whatever result from the async tool ***at any other point in the conversation***is how it should be. So I guess I'm confused about this? Btw, when async is toggled off, it works as intended (e.g. agent calls prospect by their first name) and the agent can bring it up I think later in the conversation as well. Here are examples: Async toggled off, call ID: a8fb58d4-83b2-449b-b0fa-8f15109d8906 Async toggled on, call ID: e5be4d7f-63df-4959-9f10-db2aab813498 If the async tool is working as intended, would highly recommend making edits to the intention behind it. I think this will help many other users that would be trying to get information for the agent silently because each "just a sec" by the inbound agent voiced to the prospect, in a sales context, is a detriment to the customer experience.

@george.l Thank you for providing such detailed feedback on the findContactDetails tool and its asynchronous functionality. It's clear that you're looking for a seamless integration where the agent can access the prospect's information instantly and without interrupting the flow of the conversation. From your description, it seems that when the async tool is toggled on, the agent is not able to utilize the information effectively during the call, which is indeed contrary to the intended purpose of the tool. The goal is for the agent to have all the necessary information at a glance, without having to explicitly ask the prospect or mention that they are looking up details, thus maintaining a smooth and natural interaction. I understand that this issue has been persistent and has come up multiple times since July. It's important that the tool works as intended, both with async toggled on and off, to ensure that agents can address prospects by their first name and reference relevant information later in the conversation as needed. Given the situation, I would recommend that the development team reviews the asynchronous functionality of the findContactDetails tool to ensure that it aligns with the intended user experience. The tool should provide the agent with all the necessary information in the background, allowing them to engage with the prospect without any noticeable delays or interruptions. If you have any further details or specific suggestions on how to improve the tool, please feel free to share them. Your input is valuable in enhancing the tool's performance and the overall user experience. If you need immediate assistance or have additional concerns, please ask support for more info on this.

Follow up obstacle. What's the maximum length/is there a character limit for the response? Trying to understand at what point is a response back to the agent via the tool/function call so big that the agent no longer registers the content of the response. E.g. When the character count of the response is >2k, it seems to have broken the agent, even if run synchronously compared to prior: Here's the call ID: 7138a6d4-e447-4600-9e12-06e6eb85ef4f

> And this feels to me the purpose of async tools. @george.l The async tools are designed to create and execute tools that trigger events or side effects external to the ongoing call. When a tool is set to "async", the Agent does not consume or wait for its response. Instead, the tool is triggered solely to perform an action or create a side effect where an immediate response is not necessary > E.g. When the character count of the response is >2k, it seems to have broken the agent, even if run synchronously compared to prior: Your supposed to send the response back in string format instead of object. For long response you have to convert into a paragraph of type string. https://cdn.discordapp.com/attachments/1310912310860058695/1311896362819780698/Screenshot_2024-11-29_at_8.55.57_AM.png?ex=674a8632&is=674934b2&hm=6cb1c7ba5a5a459b2d215f8595e17e82805b84830a90bb48ae48bac0b027194b&

Got it, so the response back in string format instead of object point is super helpful thank you. Is there anyway we can actually get access to what you see in that screenshot? Like it seems like we can't manually check what is received via the tool call besides the call out to Make for example. Got it on the async tools, so for example if I wanted to initiate a tool call to our crm GoHighLevel to update a tag and with a property being the tag to be added as required. It'd go ahead and do that is that it?

@george.l do let me know If I can close this ticket?