[Suggestion] Enhance utils.py to Support Additional Tool/Agent Folders

[genwch]

I am interested in using your project and would like to deploy it on my Kubernetes (k8s) cluster. However, I encountered some issues related to the maintenance of tools and agents during deployment.

It would be very helpful if there could be an additional folder to store new tools and agents. Could you enhance utils.py to load tools and agents from multiple folders, specified via a .env file?

[Eternity714]

Can the problem be solved by rebuilding the images?

[genwch]

I’d like to provide more details about my suggestion. I have built an image and deployed it in Kubernetes. It works perfectly when I use the command kubectl exec -it -- python agent_kernel.py.

However, when I want to add new tools or agents, I need to place them in the existing tools/agents folders, which requires rebuilding the image each time. To improve this process, I suggest separating the tools into two folders: one for the original tools and one for custom tools. This way, we can add or update custom tools without needing to rebuild the entire image.

I have already forked the project and am testing these changes. This is why I am raising this suggestion to make the project more flexible and easier to maintain.

[Eternity714]

Based on my understanding of your requirements, you seem to want to add tools and agents without the need to rebuild the project, and to use new features within the current container.

I have a new idea: using volume to map the tool and agents folders to the local environment, and to automatically reload when there are changes, which might solve your problem.

However, more details need to be tested and adjusted by you.

I hope to receive your further feedback, thank you.

The content above is to be translated by Kimi.

[mikekelly]

This is an interesting one. It was an intentional design decision not to separate out the core agents and tools as special cases so that the system can eventually modify/upgrade them just as it would with any other tool. You're experiencing one of the downsides of that. Another that I considered at the time is that not splitting out the core components also makes it easier for AgentK to brick itself.

For the sake of argument, let's say that we intend to stick with that original design decision for now, is there a reason you can't mount a volume containing the full repo just as the docker-compose scheduler is doing?

[genwch]

Thank you for your detailed response. I understand the reasoning behind the design decision to keep the core agents and tools together. I appreciate the insight into the potential downsides of separating them.

Regarding your suggestion, I will explore the option of mounting a volume containing the full repo, similar to the docker-compose scheduler. This approach might indeed address the issue without needing to rebuild the image each time.