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
For my API use by an agent I wanted to add some caching logic and other stuff, that needs to get the information in which chat it is right now, so like a unique chat/user id. But to send this to my API I need to have access to something like this in the agent skill and flows, for example that I can send it in the headers etc. This would improve the usability of agents massively for use cases like this, where a chat context is alo important for apis my agent is using.
The text was updated successfully, but these errors were encountered:
This sounds like something better suited for a custom fork of AnythingLLM. Until the chat is completed we would not yet have its known database ID. Kind of like a post-chat webhook is what this sounds like to where on each agent chat conclusion, an endpoint could be hit to forward this information.
I was thinking more of a variable or more generally speaking metadata, which can be accessed in existing API calls in the agent flows/skills (before the real LLM request is started), like having information about the workspace and thread and maybe also the user from which the request is coming available for API calls. For example if I want to do an API call to my own service, I want the service to know from which chat the request is coming. With this I could cache data which normally would be retrieved in a resource-intensive process or do monitoring chat wise etc.
I'm not sure if this would be better of in a custom fork, because I see quite a few scenarios where this could be important information for external, but mainly self written APIs/services I want to call.
What would you like to see?
For my API use by an agent I wanted to add some caching logic and other stuff, that needs to get the information in which chat it is right now, so like a unique chat/user id. But to send this to my API I need to have access to something like this in the agent skill and flows, for example that I can send it in the headers etc. This would improve the usability of agents massively for use cases like this, where a chat context is alo important for apis my agent is using.
The text was updated successfully, but these errors were encountered: