openclaw - 💡(How to fix) Fix [Feature]: Clarify and support persistent main-orchestrated specialist agents vs spawned sub-agent runs [1 participants]

Summary

I need clarification on OpenClaw’s intended multi-agent architecture.

I originally assumed OpenClaw could support one user-facing main agent that persistently orchestrates multiple specialist agents (code-builder, tech-researcher, knowledge-master, etc.) as internal workers.

After extensive testing, it now seems OpenClaw may instead be designed more around independent agent profiles plus temporary spawned sub-agent runs.

Problem to solve

It is currently unclear whether OpenClaw is intended for:

one persistent main orchestrator managing specialist worker agents internally, or multiple peer agent profiles routed/bound separately, with sub-agents used mainly as temporary spawned runs.

This ambiguity creates several problems:

it is unclear why users should define many named agents with separate workspace/auth/tool policies if persistent internal orchestration is not a first-class pattern it is unclear whether a custom internal agent-to-agent communication layer is a valid extension or is working against OpenClaw’s core design users who want a manager-worker architecture do not know whether they are using OpenClaw correctly or forcing the wrong mental model onto it

Proposed solution

Please clarify the intended architecture and recommended usage pattern in the docs.

Specifically:

Clearly explain whether agents.list is primarily meant for: profile isolation / routing / bindings or persistent internal team orchestration Clearly explain whether OpenClaw’s intended multi-agent model is: peer agent profiles + spawned runs or persistent main -> specialist worker orchestration If persistent main-orchestrated specialist workers are not a first-class pattern, state that explicitly and document what architecture is recommended instead. If persistent manager-worker orchestration is intended, document the supported and stable way to implement: main -> specialist delegation reliable internal coordination state/task handoff between agents

Alternatives considered

No response

Impact

This would help users choose the right architecture earlier and avoid building systems around the wrong assumptions.

It would also clarify whether OpenClaw is a good fit for:

one user-facing orchestrator plus persistent specialists or mainly for routed peer agents plus temporary spawned workers

That distinction has a major impact on system design, internal communication patterns, and whether users should extend OpenClaw or use a different orchestration layer.

Evidence/examples

No response

Additional information

No response