GitHub user jingchang0623-crypto added a comment to the discussion: [Discussion] Supervisor + Sub-Agent Orchestration: Concrete Multi-Agent Use Cases for Event-Driven Agents
Great technical deep dive. Running a 5-agent team for 90+ days has taught us a few things about supervisor + sub-agent patterns that might be relevant here. **On the "same job vs cross-job" question:** Our production setup uses both: 1. **Same-job (OpenClaw `sessions_spawn`)**: We spawn sub-agents for parallel tasks within the same context. Key insight: Pass minimal context to sub-agents, not the full conversation history. Our rule: sub-agent gets task description + relevant files, never the coordinator's full memory. This prevents context pollution. 2. **Cross-job (GitHub Discussions as mailbox)**: For async collaboration, we use GitHub Discussions as a message bus. Each agent writes to a discussion thread, other agents read and respond. This is slower (minutes to hours latency) but survives crashes, works across time zones, and leaves an audit trail. **On context isolation:** The biggest win from sub-agent architecture is not scalability — it is context hygiene. A coordinator running for hours accumulates garbage context. Spawning fresh sub-agents for specific tasks gives you clean working memory. Our content creation pipeline: ``` Coordinator: "Write article about MCP" ├─ Sub-agent A: Research (fresh context) ├─ Sub-agent B: Write (fresh context) └─ Sub-agent C: Review (fresh context) ``` Each sub-agent sees only its inputs, not the whole history. This reduces hallucination and improves consistency. **On the "judge/critic" pattern:** We implemented this via a competitive pattern: 3 writer agents generate drafts, a judge agent picks the best. The judge uses different evaluation criteria than the writers. This gives better results than a single agent self-critiquing. **Cost control note:** Supervisor + sub-agent is expensive if you run it continuously. We use cron to spawn the supervisor, which then spawns sub-agents, which terminate after completing tasks. No idle agents burning tokens. Our detailed patterns documented here: https://miaoquai.com/tools/openclaw-multi-agent-orchestration Thanks for the FLIP-577 reference — the RpcOperator direction looks promising for Flink-native sub-agent support. GitHub link: https://github.com/apache/flink-agents/discussions/660#discussioncomment-16929990 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
