The AIP Agent interactive widget in Workshop needs to render, before it can generate a session ID. But this breaks some workflows, e.g. when you’d want the Agent to collaborate with the user on something the user generates previously.
This could be a summary generated by another function or a search for a corpus of documents, that the user wants the Agent to work on.
Even when passing a new string or having the agent loaded, but keeping the section hidden until needed, passing a new string to the session ID variable will not generate a new session ID (RID), unless the widget is rendered in the main view.
This means that some workflows break, e.g. storing the session ID for an Agent interaction in an Object, as the user clicks a button to start this agent interaction.
Refactoring the workflow to have the entire workflow in the Agent is not possible, as tool usage is incredibly slow (implementing a tool in an Agent basically doubles the time it takes to use said tool).
Could we have more control over how this works, please?
And additionally, could we as admins get access to user’s sessions, so we can use these in stack traces?
From the agents side, we are tracking supporting exporting sessions to datasets, which should help with the admin stack traces request.
Is the problem here that we don’t generate a session ID until the user first sends a message? I’m a bit confused the workflow you are trying to support.
One thing that may help you here is publishing the agent as a function. This would allow you to run the function wherever and continue the session in the AIP Interactive Widget by writing the output sessionRid into the session identifier variable in the Workshop config.
User searches for the documents that they want to include in the corpus, used by the agent as context.
Once this is done, the workflow moves over to the Agent screen.
Regardless if this is on a new page, a new tab or even a new section on the same page, but hidden by a conditional, the a sessionID will not generate before the widget is rendered on screen – regardless of whether you pass an input string to it.
Functions is a good shout – I’ll see if that works in the current flow. I’m already jumping through quite a few hoops to get this workflow to work in Workshop, so hoping this won’t break it further.