I can see how this is useful for development.
However, since I don’t develop or create modules, I don’t see any immediate use case for myself.
It might have helped to support the AgentZero update process programmatically if comparable information about the architecture or update process had been available in the module. That’s why I wasn’t able to do it. Ai Agent: Agentzero - #48 by capote
@oneitonitram @Stll0
I’m also wondering whether it wouldn’t make sense to support both the agent-based system management of NS8 itself and that of the individual modules by providing structured information, as in AGENTS.md.
So far, I’ve made do by referring to the respective documentation (Nethserver docs or GitHub). But depending on the size of the context window and the general capabilities of the LLM being used, this may or may not work.
In particular, when container boundaries are crossed (e.g., log analysis, restarting services on the host or in other modules), this would improve the targeted operation of agents, token efficiency, and speed.
It was quite a challenge at first to make the agents understand that they are running in a container under NS8 and not on a standalone system using native Docker (e.g., management via runagent rather than podman).
Some of the trial-and-error involved in the agents building their own knowledge could be shortened.
Regardless of that, I’d be generally and fundamentally interested in hearing about your experiences with agent-based support.
I still think we could improve the learning curve for beginners here if we could compile a set of best practices or general guidelines with regard to the agent-based systems available here—AgentZero and Hermes Agent.
In my case, at any rate, it was quite a bit of fiddling around before I had more or less figured out how to get started and build meaningful use cases.
But since even Linus Torvalds supports the use of AI, I think the topic will continue to gain momentum and that reservations about it can be further reduced.