multi-agent setup

[tribal juniper]

I am trying to have a telegram channel with several agents. I am running an own model provider API. When I write into the multi-agent channel, I see that all of them react in "thinking" but none of them answers. It happens quite quickly so that it cannot be the timeout. In the backend I am running llamacpp. What else can I make, so that there is a queue for my agents?

I am also having another question: I am trying to have on agent to be the orchestrator of others. But it is not really working. Any suggestions on why? e.g. the main agent cannot tell another one to write me on telegram.

[subtle island]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[tight jackal]

First thing I’d check: please include openclaw --version when you reply — version matters a lot for multi-agent/channel behavior.

A few likely causes here:

1. This probably isn’t a queue problem. OpenClaw already queues inbound runs per session, and the main lane has a concurrency cap. If all agents briefly show “thinking” and then stop, that usually means the model call/run failed fast, not that it timed out.

2. llama.cpp / OpenAI-compatible backends often fail on agent turns because of tool schemas or content shape. Try disabling tool calls for that model entry first:

{
  models: {
    providers: {
      yourProvider: {
        models: [
          {
            id: "your-model",

            compat: {
              supportsTools: false
            }
          }
        ]
      }
    }
  }
}

If logs mention messages[].content needing a string, also add:

compat: {

  supportsTools: false,
  requiresStringContent: true
}

Then restart and test with a tiny prompt. Watch openclaw logs --follow while sending one Telegram message. Docs: https://docs.openclaw.ai/help/troubleshooting#local-openai-compatible-backend-works-directly-but-fails-in-openclaw

3. If your llama.cpp server can only handle one request at a time, serialize OpenClaw runs globally:

{
  agents: {
    defaults: {
      maxConcurrent: 1,
      subagents: {

        maxConcurrent: 1
      }
    }
  }
}

For rapid messages inside one chat/session, use /queue followup or /queue collect in that chat. Docs: https://docs.openclaw.ai/concepts/queue

4. For “several agents in one Telegram group”: bindings route an inbound message to one agent per matching account; they are not a broadcast/fan-out mechanism by themselves. If you want several independent agents to see the same Telegram group message, the normal setup is one Telegram bot/account per agent, each with its own channels.telegram.accounts.<id>.botToken, and bindings from account → agent. Docs: https://docs.openclaw.ai/concepts/multi-agent and https://docs.openclaw.ai/channels/telegram

5. For an orchestrator agent: use sub-agents, not “agent A tells agent B to independently message me”. The parent agent needs the tools enabled, and the target agents must be allowed:

{

  tools: {
    alsoAllow: ["sessions_spawn", "sessions_yield", "subagents"]
  },
  agents: {
    defaults: {
      subagents: {
        allowAgents: ["*"],
        maxSpawnDepth: 2
      }
    }
  }
}

maxSpawnDepth: 2 is only needed if a spawned orchestrator should spawn workers. Child results normally announce back up to the requester session, then the main agent replies to Telegram. Sub-agents do not get all session/message tools by default, so expecting a worker to directly send Telegram messages often fails unless you explicitly allow that tool path.