Multi-agent setup with separate workspaces

[broken sorrel]

Hi everyone — I’m trying to confirm the right OpenClaw architecture for my case.

Setup:

• OpenClaw 2026.4.12

• Gateway local, bind loopback

• gateway.auth.mode = none

• Two separate agents: main and raul

• Each has its own workspace and agentDir

  • main → /home/juan/.openclaw/workspace
  • raul → /home/juan/.openclaw/workspace-raul

• Each also has its own Telegram bot/account

• sessions.visibility = "all"

• agentToAgent.enabled = true

Important detail:
raul is not meant to be a transient subagent spawned by main.
He is a separate persistent agent with his own workspace, identity, session store, and external Telegram channel.

What I want:
main → communicate internally with raul → get results back

What I see:

• raul is visible from main
• I can see targets like agent:raul:main
• sessions_list works
• but sessions_send fails with:
  gateway closed (1008): pairing required

What is confusing:
Gateway logs say:
auth mode=none explicitly configured

But later I also see:

• scope upgrade request to operator.admin
• then gateway connect failed: pairing required

My questions:

1. With separate agents in separate workspaces, is sessions_send the right pattern for inter-agent communication?
2. Should this setup be modeled differently even if both agents are intentionally persistent and independent?
3. Can an internal scope upgrade still trigger pairing even with gateway.auth.mode = none?
4. What is the recommended pattern for persistent sibling agents with separate workspaces, instead of parent/child subagents?

I’m trying to understand the intended best practice here, not just a workaround.

Any guidance would be appreciated.

[solid prawn]

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

[carmine halo]

Let me check the auth/pairing side and the sessions_send path more directly.

Your mental model is basically right.

1. Yes, for persistent sibling agents, sessions_send is the right in-agent pattern.
   sessions_spawn is for transient parent/child work, not for an independent raul.

2. No, you do not need to remodel this as subagents if raul is intentionally separate.
   Separate workspace + agentDir + sessions + channel account is exactly the multi-agent shape.

3. Yes, a scope upgrade can still trigger pairing even with gateway.auth.mode = none.
   auth.mode = none disables shared-secret auth. It does not disable device pairing / device scope approval.

4. Recommended pattern:

   • separate configured agents + bindings
   • tools.agentToAgent.enabled: true
   • allowlist the sibling agent ids
   • tools.sessions.visibility: "all" only if you really want cross-agent visibility
   • use sessions_send to the sibling’s main/labeled session

Why your behavior makes sense:

• sessions_list / sessions.resolve are read-scoped
• sessions_send ends up starting an agent run, which needs write
• if the caller device/session was only paired for lower scopes, the gateway creates a scope-upgrade pairing request and closes with 1008 pairing required

So this looks like a pairing/scope issue, not the wrong architecture.

Also, one subtlety: if you are testing from CLI / Control UI, the caller may request a broader operator scope set than the minimum send path, which is why you can see operator.admin in the pending upgrade.

What I’d check next:

openclaw devices list
openclaw devices approve <requestId>