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
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.
The text was updated successfully, but these errors were encountered:
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!
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.
The text was updated successfully, but these errors were encountered: