Summary

The SRE-triage MAS sample's coordinator (workspaces/sre/AGENTS.md) tells the model to use sessions_spawn to delegate to specialist sub-agents (@telemetry, @backend, @db), but never instructs the model to pass the agentId parameter that actually switches the spawned child to the target agent's workspace and tool allowlist. The @telemetry/@backend/@db markers are treated as prose labels, not as structural args. As a result, every spawned sub-agent runs in the SRE workspace with the SRE tool allowlist (sessions_spawn/sessions_list/sessions_send only), making real specialist investigation impossible.

Reproduction

1. install_remote.sh (clean, scenario 2 / order-db-deadlock).
2. openclaw agent --agent sre --json -m "Customers report checkout failures...".
3. Inspect the resulting session JSONL under ~/.openclaw/agents/sre/sessions/*.jsonl.

Observed (real run, 2026-04-24T20:49:20Z):

{"name":"sessions_spawn","arguments":{"runtime":"subagent","mode":"run","label":"telemetry-checkout-incident","task":"You are @telemetry. Investigate this incident via the DB REST API only at http://127.0.0.1:8765..."}}

No agentId field on any of the 3 spawn calls. The 3 child sessions land under agents/sre/sessions/*.jsonl (not agents/telemetry/sessions/), and each child's session header reports cwd: /data/.openclaw/workspaces/sre. The children then hallucinate strings like to=browser.open / to=exec because the platform actually exposes only the inherited SRE allowlist.

Root cause

workspaces/sre/AGENTS.md Communication Protocol says:

For specialist subagents (@telemetry, @backend, @db), use sessions_spawn and do NOT use sessions_send.

Nowhere is the model told that sessions_spawn accepts an agentId parameter. The platform does support it — spawnSubagentDirect (openclaw 2026.4.12, subagent-spawn-DFAWGY7r.js) reads params.agentId, validates against agents.sre.subagents.allowAgents (which install_remote.sh correctly sets to ["telemetry","backend","db"]), and creates the child under agent:${targetAgentId}:subagent:${uuid}.

Expected

After install, the SRE coordinator reliably routes each spawn to the right specialist agent's workspace + tools.

Suggested fix

Two complementary changes:

1. workspaces/sre/AGENTS.md — in "Communication Protocol", add an explicit instruction and example:

   For specialist subagents, call sessions_spawn with agentId: "telemetry" (or "backend" / "db"). The agentId argument is required — without it, the spawned child runs in your own workspace and cannot access specialist tools. Example:
   sessions_spawn({ "agentId": "telemetry", "runtime": "subagent", "mode": "run", "label": "...", "task": "..." })

2. install_remote.sh — set subagents.requireAgentId: true on the sre agent so the platform rejects spawn calls that omit agentId with a clear error instead of silently inheriting context. The config knob already exists in openclaw-core.

Related

Interacts with #34 (sister bug in this repo) — even with this fix, specialist sub-agents will still have an empty toolset until the tool-name registration issue is addressed. The two should land together.