-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tool Library and Tool Generation #63
Comments
Great ask! We have some of this but not all of this, and the discoverability and assistance for non-technical users could be improtved. Within each workspace, there is a tab for custom tools. I can see, however, how this doesn't meet the need where a non-technical user wants build an agent and A bee agent can help accomplish (b) and we have an internal proof of concept built by @jenna-winkler. But it's not yet integrated into the user flow of tool creation. |
@anafucs for consideration as we are reworking IA after learning how users are working with workspaces. If workspaces are expected to be more separate (like slack where a user spends most of their time in a single workspace) then maybe having the public tools repeated in each workspace and alongside the python tools would make sense? It would facilitate the user flow that @aniketmoha9 is describing here. You could imagine a visual differentiation (or not!) among public tools, tools from others in your workspace, and tools you made. I know y'all thought deeply about this, so just dropping a data point into the thinking pool. |
These are some of things which i was thinking can be useful
|
Another idea. How about making that tool library an open registry where the LLM agent itself can search for and pull "tool" code that can be utilized for fulfilling the needs "on the fly" while processing an agent task. The registry supplies the source code of the tool written in Python which can then be fed into bee-code-interpreter to run. When we are to create super-generic agent which can deal with almost any arbitrary requirement, it ends up in the question how broad varieties of tools the implementation can provide to LLM along with prompt. Currently, this is done during development which makes the question almost equal to how much imagination the implementer can yield, which naturally has certain limit. Having a tools registry lets it done during runtime rather than development freeing up the implementer from squeezing their imagination during development. The more the regisry gets rich, the smarter the exisiting agent gets. The only tool an agent needs to be fed is a tool to find a suitable tool - "ToolFinderTool" so to speak. |
The tool library can be something similar to prompt library which we have in watsonx.ai prompt lab, it will have a list of all working and properly tested tools and can be searched using the user tool requirements or tool description, also if the tool is not present in the library then it can have a option to generate the python function for a tool based on the tool requirements.
this feature can help non technical users to create agents.
The text was updated successfully, but these errors were encountered: