OpenClaw Multi-Agent Routing Guide

Multiple agents should represent real boundaries: different workspaces, senders, credentials, tool policies, or responsibilities. Creating several names that share the same unrestricted environment does not provide isolation.

Define each boundary

For every agent, record:

• Workspace and writable paths
• Model and fallback policy
• Allowed tools and sandbox mode
• Channel account or sender bindings
• Secrets available to that agent
• Whether it may delegate or message another agent

Use specific routing rules. A broad catch-all binding can send private or privileged work to the wrong workspace.

Inspect the resolved configuration

openclaw status --all
openclaw config get agents
openclaw channels status --probe

Validate configuration before restarting the Gateway. Then test one sender or channel route at a time with an unmistakable harmless request.

Test isolation

Ask each agent to identify its workspace and available tool categories. Confirm it cannot read another agent’s files or use another agent’s credentials. Test the default route separately so unmatched messages do not disappear or enter a privileged agent.

Delegated sub-agents inherit additional restrictions after the parent profile is applied. A tool excluded by the parent profile cannot be restored merely by allowing it in the sub-agent block.

Expected result

• Each test sender reaches exactly one intended agent.
• Workspace and secret boundaries remain separate.
• Tool availability matches that agent’s policy.
• Unmatched routes fail safely or reach the documented default.
• Logs make the selected route understandable.

Re-run routing tests after channel, agent, or policy changes.