Multi-Agent Runtime

[arefbehboudi]

This change introduces multi-agent support to JavaClaw and adds an initial agent management experience.

Main changes:

• Added multi-agent runtime support
• Added an Agents page for listing and managing agents
• Each agent now has its own isolated:
  • workspace
  • conversations
  • skills
  • prompt files
• Users can add new agents
• Users can switch the active runtime agent during chat

This lays the foundation for running multiple independent agents in the same app without sharing memory, history, or workspace state.

[martinrevert]

Hi Aref! I bring to your attention info of a special case that could impact in the multi-agent approach. I've integrated OpenRouter as provider, but i didn't sent a PR waiting for your advance on multi-agents and subagents, because that will change for sure the way providers are integrated. As you may know, the thing is there is no oficial Java lib for OpenRouter, you just have to use the same lib and approach as OpenAI, just changing the root URL. Of course to achieve this i had to touch several things on onboarding steps and the provider to keep both options independent even using the same lib. I bring this to your attention because as happens with Ollama, OpenRouter is a nice option to delegate subagents on different models on the same agent/provider and it will be nice to see that also as a multi-subgents option mainly to manage costs but also to have differents concern model (audio, video, image processing, etc), but be aware that to have multi-agent options at same time with OpenAI and OpenRouter will bring this small challenge to reuse the same lib pointing to different URLs. Let me know what you think, i'm interested in your opinion on which could be the best approach on this on the onboarding steps and in the provider integration.

[arefbehboudi]

Hi Aref! I bring to your attention info of a special case that could impact in the multi-agent approach. I've integrated OpenRouter as provider, but i didn't sent a PR waiting for your advance on multi-agents and subagents, because that will change for sure the way providers are integrated. As you may know, the thing is there is no oficial Java lib for OpenRouter, you just have to use the same lib and approach as OpenAI, just changing the root URL. Of course to achieve this i had to touch several things on onboarding steps and the provider to keep both options independent even using the same lib. I bring this to your attention because as happens with Ollama, OpenRouter is a nice option to delegate subagents on different models on the same agent/provider and it will be nice to see that also as a multi-subgents option mainly to manage costs but also to have differents concern model (audio, video, image processing, etc), but be aware that to have multi-agent options at same time with OpenAI and OpenRouter will bring this small challenge to reuse the same lib pointing to different URLs. Let me know what you think, i'm interested in your opinion on which could be the best approach on this on the onboarding steps and in the provider integration.

Hi @martinrevert,
I faced a very similar issue when integrating Grok.

The first problem was the base URL not being configurable, and the second one was the provider selection being tightly coupled to Spring AI auto-configuration. Since Grok doesn’t have an auto-configuration in Spring AI, setting spring.ai.model.chat=grok resulted in failures.

In my MR, I removed the dependency on Spring AI auto-configuration entirely, which solved the issue. Also, providers can now define their own base URL independently.

Based on this, I think we could introduce a custom “OpenAI-compatible” provider abstraction. Since OpenRouter, Grok, and similar providers follow the same API pattern, we can reuse the same implementation and just configure base URL and API key.