Feature Request: Native Multi-Agent Routing

[WoodyWangHou]

Hi, I'd like to ask for a feature in nanobot to support what openclaw does as Multi-Agent Routing. I think currently it is possible to do so manually by spinning up multiple nanobot gateway instances and hatch agents one by one, but it is a bit hassle sometimes, if nanobot could support it natively, I think the main agent could help hatching other agents easily. As for use-cases, my personal use case is to add specialized agents for different scenario and task, but there could be more.

I'd love to hear if this feature is valuable to be supported natively, happy to create a PR for this if it makes sense.

More detailed technical specs that I vibed with cc:

---

Summary

Add native support for running multiple isolated AI agents within a single nanobot gateway instance, each with its own memory, persona, and dedicated channels.

What is an Isolated Agent?

An isolated agent is a completely separate runtime instance with:

1. Isolated Memory

   • Own MEMORY.md and HISTORY.md files
   • Separate conversation sessions
   • No memory overlap with other agents

2. Isolated Persona

   • Own SOUL.md, AGENTS.md, USER.md files
   • Own skills directory
   • Different personality/tone per agent

3. Dedicated Channels

   • Own channel credentials and configurations
   • Messages routed by channel account

4. Message Routing

   • Simple routing: message's channel+account determines which agent handles it
   • Default agent for unmatched channels

Value Proposition

Use Case	Example
Work vs Personal	Work agent with formal tone + personal agent with casual tone
Different Models	Fast/cheap model for simple tasks + premium model for complex reasoning
Specialized Skills	Developer agent with shell/tools skills + support agent with CRM skills
Multi-account	Multiple WhatsApp/Telegram numbers handled by different agents

[chengyongru]

Hi @WoodyWangHou ，

Does this feature feel like it can be implemented through a startup script? Is it really necessary to add it to the native implementation of nanobot?

[WoodyWangHou]

it absolutely does by following what #1642 suggests, this feels like a useful thing to be supported natively though if many ppl are setting up multiple agents already. No strong opinion but wondering if it feels like smth that could be supported natively.

[liiir1985]

I have a PR implementing such feature: #2064
Any thoughts about it? It's a little bit different though, it has isolated workspace, persona, memory, and can talk to each other(can be configured who can see whom) via internal message bus. But channels are only mapped to the main agent.

multiple nanobot instances was giving me a lot headache as well, making sure every instance's working properly in the startup script isn't that easy, especially if I want to start nanobot as a service

[JiajunBernoulli]

I have two OpenClaw Agents and three NanoBot Agents to do many different things.

I think the current mode is more elegant than OpenClaw.

1. Easy to understand:
   1.1 Simplicity is a prerequisite for reliability: Implementing multi-agent in code will disrupt the existing design and increase the cost of development and testing.
   1.2 No additional configuration KV: OpenClaw requires additional binding of the mapping relationship between subagent and channel.
2. Better isolation: I can safely change the configuration of nanobot-a by nanobot-b, and even if there is an error, it will not affect nanobot-b. However, changing the configuration of openclaw-a by openclaw-b may resulting in the crash of all agents.

[liiir1985]

I have two OpenClaw Agents and three NanoBot Agents to do many different things.

I think the current mode is more elegant than OpenClaw.

1. Easy to understand:
   1.1 Simplicity is a prerequisite for reliability: Implementing multi-agent in code will disrupt the existing design and increase the cost of development and testing.
   1.2 No additional configuration KV: OpenClaw requires additional binding of the mapping relationship between subagent and channel.
2. Better isolation: I can safely change the configuration of nanobot-a by nanobot-b, and even if there is an error, it will not affect nanobot-b. However, changing the configuration of openclaw-a by openclaw-b may resulting in the crash of all agents.

so how did you make the agents know each other? and how to make them to communicate with each other? Am i missing something? I didn't find a way or channel to achieve this, rather than writing files into peer agent's workspace file and let heartbeat to check the file change

[dmahurin]

Here is a WIP PR implementing agent handoff. This is different than multi agent configured to be subagents.

#2108

Though admittedly, multi agents configured to be used as sub agents is perhaps more flexible for many cases.

#2064

In general, I think using just multiple instances will be insufficient for many cases, and multiple configured agents in one nanobot would be required in some form.

[WoodyWangHou]

I have two OpenClaw Agents and three NanoBot Agents to do many different things.

I think the current mode is more elegant than OpenClaw.

1. Easy to understand:
   1.1 Simplicity is a prerequisite for reliability: Implementing multi-agent in code will disrupt the existing design and increase the cost of development and testing.
   1.2 No additional configuration KV: OpenClaw requires additional binding of the mapping relationship between subagent and channel.
2. Better isolation: I can safely change the configuration of nanobot-a by nanobot-b, and even if there is an error, it will not affect nanobot-b. However, changing the configuration of openclaw-a by openclaw-b may resulting in the crash of all agents.

well it always come with trade offs and there are counter points:

1. Overhead: it's incurring unnecessary overhead for usability (writing scripts managing multiple instances), and also I just simply don't see why I need to run multiple gateways for multiple agents. The gateway is just really a simple message multiplexing router that could potentially multiplex the communication between user and multiple agents.
2. Easy to understand: those problems could be solved if the implementation follows a clean interfaces design and the codebase conventions. Same goes for KV. I am not a fan of openclaw codebase neither but I partly blame it to full AI driven development than multi-agent itself (if you are willing to hand off code design, implementation completely to AI).

anyways sounds like this is smth ppl are not interested, so I will close this issue for now until someone think this is valuable.

[ariedov]

Is there a way to do this with docker/compose?