Handover parmeters to agent from GUI

đź’¬ Agents
1

Hi,

I have an app using the Agent Chat GUI component and an agent query to call my Agent. By default the agent query uses {{ componentname.agentInputs }} to call the agent and handover the input from the user. I would like to add other parameters as well. But everytime I add parameters like {{ url.searchparams.camapignID }} (one of my URL parameters) the object is automatically tansformed into a string. I also tried different possibilites to keep the object like using

{{ { ...PostGenerator.agentInputs, campaignId: url.searchParams.campaignId } }} or

{{ ({ ...PostGenerator.agentInputs, action: "invoke", campaignId: url.searchParams.campaignId }) }}

But this seem to end up in an endless session as the agent does not come back and keeps running until I reload the page.

But there must be a way of handing over more than just the agentInputs as parameters to an agent, especially to call the tools he uses.

Do you have any idea?

Thanks and best regards,
Ruediger

2

Well, it works but only in a nasty way :slight_smile: Instead of using the complete object from .agentInputs you “rebuild” the elements of the object yourself. Than you can add the parameters in “message”. Here ist the example:

{{ {
action: PostGenerator.agentInputs.action || "invoke",
messages: [
{
role: "user",
content: "Campaign Context: campaignId = " + url.searchParams.campaignId
},
...(PostGenerator.agentInputs.messages || [])
],
agentRunId: PostGenerator.agentInputs.agentRunId,
} }}

But doing this means to add the parameters to the user’s message input, as the role “system” is not available. This is ok for public parameters and data but why can’t we just use the “system” value for “role” when calling an agent?

3

Welcome to the community, @Ruediger! Thanks for reaching out. :slightly_smiling_face:

I'm glad to hear that you're building agents! The scenario you're describing is actually very similar to other feedback that we've received - as you can see here - but it sounds like you've already figured out the best workaround.

I'll update our internal tracking with some of the additional context that you've added here and give you an update as soon as I can!

5

Actually, Kent just documented our recommended approach to solving this particular problem over here. Let me know if you have any questions!