6 Agent Communication

[hard fable]

I have 6 agents configured with agentToAgent enabled, all agents in the allow list, all agents have sessions_send in their tool permissions, and sessions.visibility set to “all.” Config is verified correct.
Two problems:
1. sessions_send fails with “No session found with label: lucy” — I believe the tool needs the full runtime session key (telegram:lucy:CHATID) rather than the channel account name. How do I discover or bind the correct session labels so agents can address each other?
2. Sub-agents spawned by a parent agent cannot use sessions_send — the tool isn’t available in the spawned context. Is there a way to grant spawned sub-agents access to sessions_send, or is inter-agent communication only possible between primary agent sessions?
My agent config uses channel names lucy, erica, brittany, lauren, jane. Agent IDs are tess, faith, mandy, jessica, jane_ea.

[sonic mica]

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

[regal creek]

Checking the docs/source now so I don’t make up keys or behavior.

I found the session resolution code and the subagent tool policy. One sec, pulling the exact behavior so I can answer cleanly.

You’re very close, but there are two separate identities here:

• agent id: tess, faith, mandy, jessica, jane_ea
• channel/account id: lucy, erica, brittany, lauren, jane

sessions_send(label: "lucy") does not look up the Telegram account name. It looks up the session’s explicit label field.

1. Why label: "lucy" fails

That error means there is no session whose actual label is lucy.

Current behavior is:

• sessions_send can target by sessionKey, sessionId, or label
• label is an explicitly assigned session label, not a channel/account name
• labels must be unique

So yes, your intuition is partly right: if you want to target a session reliably, use the real session key returned by discovery, not the account name.

Use one of these to discover targets:

• in-agent: sessions_list
• CLI: openclaw sessions --all-agents --json

Then send to the returned key, for example something like:

• agent:tess:main
• agent:tess:telegram:lucy:direct:123456789
• agent:tess:telegram:group:-100123...

Important detail: it is not always telegram:lucy:CHATID.

For DMs, depending on your session config, it may collapse to the agent’s main session:

• agent:<agentId>:<mainKey>

If you want human-friendly names like lucy, faith-main, etc., you need to assign session labels first via sessions.patch / Control UI, then sessions_send(label: "...") will work.

2. Can spawned sub-agents use sessions_send?

Yes, but not by default.

Current source behavior is:

• sub-agents default-deny sessions_send
• depth-1 orchestrator subagents get sessions_spawn, subagents, sessions_list, sessions_history
• sessions_send is still denied unless you re-enable it

Best config:

{
  tools: {
    subagents: {
      tools: {
        alsoAllow: ["sessions_send"]
      }
    },
    sessions: {
      visibility: "all"
    },
    agentToAgent: {
      enabled: true,
      allow: ["tess", "faith", "mandy", "jessica", "jane_ea"]
    }
  }

}

Why alsoAllow is better than allow:

• allow becomes allow-only
• alsoAllow adds sessions_send back without stripping the child’s normal tools

One more gotcha, sandboxed children

If the spawned child is sandboxed, session visibility can still get clamped to its own spawned tree.

If you re-enable sessions_send and it still cannot see other sessions, check:

{
  agents: {
    defaults: {
      sandbox: {
        sessionToolsVisibility: "all"
      }
    }
  }
}

Without that, sandboxed children may still only see spawned descendants.

Short version

• lucy is an account id, not a session label