Skip to content
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

Open
aniketmoha9 opened this issue Nov 11, 2024 · 4 comments
Open

Tool Library and Tool Generation #63

aniketmoha9 opened this issue Nov 11, 2024 · 4 comments
Labels
question Further information is requested

Comments

@aniketmoha9
Copy link

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.

@geneknit
Copy link

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.
Globally available validated tools are accessible via the lefthand nav.

image

I can see, however, how this doesn't meet the need where a non-technical user wants build an agent and
a) see every tool they have access to add (including public tools and any tools added by developers than may be in they workspace
b) if they can't find what they are looking for, an assisted ability to create a custom tool.

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.

image

@geneknit
Copy link

@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.

@mmurad2 mmurad2 added the question Further information is requested label Nov 18, 2024
@aniketmoha9
Copy link
Author

These are some of things which i was thinking can be useful
Key Features of This Tool Library:

  • Hundreds (or thousands) of tools organized with metadata for easy retrieval.
  • A natural language interface to find tools by description.
  • some tools can be Pre-built connections with IBM products, APIs, and third-party software
  • If a tool matching the user’s requirements isn’t found, the system can dynamically generate Python code for the requested functionality based on the user's prompt or query.
  • This feature would leverage watsonx.ai (specific model already tested to give good results) to create function definitions or templates for tools, potentially integrating external libraries or APIs as needed.
    How It’s Similar to a Prompt Library:
  • A prompt library stores reusable prompts to interact with LLMs. Similarly, this tool library would store reusable tools or function definitions with searchable metadata.

@skydancer41
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants