Feature: Implement advanced multi-agent coordination patterns (starting with Debate)

[workonlly]

🔍 Issue Description

📌 Issue Type

• Bug
• Feature Request
• Enhancement
• Documentation
• Refactor
• Other (please specify)

---

📝 Description

What is happening?
Currently, the agent orchestration framework is limited to simple Sequential and Parallel execution. Users cannot utilize 5 out of the 7 planned multi-agent coordination patterns (e.g., Debate, Consensus, MapReduce, Supervision, Routing).

What should happen instead?
The framework should support complex multi-agent collaboration and cognitive swarm orchestration, allowing agents to dynamically interact, debate, and synthesize conclusions.

Why is this needed?
HIGH IMPACT: The lack of these patterns severely limits the framework's completeness and blocks developers from building complex, real-world multi-agent collaboration scenarios. Unblocking these patterns is essential for the core vision of the swarm orchestrator.

---

🎯 Proposed Solution

High-level approach:
Begin by implementing the Debate pattern as a foundational blueprint for complex orchestration. This requires a two-phase execution context within the scheduler:

• Phase 1: Debate (Parallel)
  • ├─ Debater1 → Argue Position A
  • ├─ Debater2 → Argue Position B
  • └─ Debater3 → Argue Position C
• Phase 2: Synthesis (Sequential)
  • └─ Judge → Synthesize Conclusion

Once this architecture is proven, the remaining patterns (Consensus, MapReduce, Supervision, Routing) can follow the same structural implementation.

---

📎 Additional Context

Implementing this unlocks the "Cognitive Swarm Orchestrator" capabilities of the framework.

[m13v]

the coordination overhead between agents is where this gets hard in practice. we run 4-6 Claude agents in parallel on the same codebase and tried several patterns before landing on something reliable. the debate pattern you're describing maps well to how we handle conflicting agent outputs - each agent works independently in an isolated git worktree, then a synthesis step merges the results. the key insight for us was that shared state between debaters needs to be minimal and explicitly defined upfront. trying to let agents share a working directory while debating causes race conditions that are incredibly hard to debug. also, the judge/synthesis step needs access to the full reasoning chain from each debater, not just the final output - otherwise it can't resolve contradictions intelligently.

[m13v]

here's our filesystem-based locking for multi-agent browser coordination (the mkdir atomic lock pattern): https://github.com/m13v/browser-lock/blob/main/playwright-lock.sh

and the orchestration layer that manages parallel agent sessions with worktree isolation and real-time status tracking: https://github.com/m13v/tmux-background-agents/blob/main/SKILL.md

[workonlly]

thankyou for guiding i will go through the docs and come up with a better solution soon