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

keep only functional tools in the framework #64

Open
ismaelfaro opened this issue Dec 9, 2024 · 1 comment
Open

keep only functional tools in the framework #64

ismaelfaro opened this issue Dec 9, 2024 · 1 comment
Labels
enhancement New feature or request framework Building, deploying, scaling agents

Comments

@ismaelfaro
Copy link
Member

We should remove all the tools that are not core from the framework and move the rest like part of the examples or community contributions, example OpenMeteoTool.

@ismaelfaro ismaelfaro added the enhancement New feature or request label Dec 10, 2024
@psschwei psschwei transferred this issue from another repository Dec 18, 2024
@psschwei psschwei added the framework Building, deploying, scaling agents label Dec 18, 2024
@matiasmolinas
Copy link

Hi, I’d like to expand on the idea of “keeping only functional tools” by adding dynamic tool creation into the mix. Instead of simply removing non-core tools, I propose a pipeline where new tools—potentially generated at runtime by an agent—can be:

  • Tested Ephemerally: The agent generates a tool (script/snippet), and we tag it as “ephemeral” until it passes certain validation checks (syntax, basic functionality, etc.).
  • Tracked with Metadata: Each ephemeral tool has metadata—timestamp, version, success/fail counters, and who/what generated it. We can maintain these in a lightweight DB or a JSON structure.
  • Promoted or Rejected: If the tool meets acceptance criteria (e.g., it passes all checks or gets approved by a developer), it’s promoted to “functional” status. Otherwise, it remains deprecated or moves into examples/community.
  • Runtime vs. Repository: Approved tools can be deployed directly to the user’s runtime environment for immediate use. Optionally, we can also integrate a process to add them to the official repo (e.g., a GitHub PR or a dedicated “tools” folder) if they’re proven stable.

Why This Matters

  • We want to keep the framework lean by pruning non-core or failing tools.
  • But we also want a robust flow for dynamically generated tools to enter the system and potentially become part of the user’s final toolkit.
  • This approach aligns with an “evolutionary AI” perspective, where agents constantly refine their capabilities and push updates back into the platform if they’re validated.

Let me know your thoughts on this more advanced approach. If everyone agrees, I can start drafting a PR or design doc detailing how ephemeral vs. functional tools will be handled, along with the necessary metadata, validation gates, and user approvals. Looking forward to hearing your feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request framework Building, deploying, scaling agents
Projects
None yet
Development

No branches or pull requests

3 participants