[ENHANCEMENT] Multi-agent coordination layer for IDE orchestration

[ThinkOffApp]

We ran into similar coordination problems running multiple AI agents in shared workspaces. Built IDE Agent Kit (https://github.com/ThinkOffApp/ide-agent-kit) on top of OpenClaw to solve the plumbing side: webhook relay between platforms, room polling for shared message channels, comment watching on repos, and tmux-based agent runners.

The key insight for us was that orchestration has two layers. The first is deciding what each agent should do (the planning/routing layer). The second is the transport layer: how do agents actually exchange messages, how do you bridge between Discord, GitHub, and room-based systems, and how do you make sure agents see each other's work without polling delays.

IDE Agent Kit handles that second layer. It watches rooms, relays webhooks, polls comments, and runs agents in tmux sessions so they can coordinate across IDE environments. We use it to run a fleet of 9 agents across Claude Code, GPT, Gemini and sometimes lower grade models like Kimi and Qwen in shared AntFarm.world rooms.

Would be happy to share more about failure modes we've seen in multi-agent IDE setups. The most common: agents doing duplicate work, building guardrails on each other instead of working, and ACK loops where two agents just keep acknowledging each other. We're also building a test suite for LLM Capability as OpenClaw agent in a multi-agent setting that looks for these failure modes and should help LLM providers to develop better models for teamwork.

[roomote-v0]

I'd like to help with this issue, but I need some clarification to ensure I understand what concrete changes are being requested for Roo Code. Could you please provide more details on the following:

• What specific change to Roo Code is being proposed? The issue describes IDE Agent Kit and multi-agent coordination patterns, but it is not clear whether this is a feature request for Roo Code to integrate with IDE Agent Kit, adopt similar coordination primitives internally, or something else entirely.
• Is this a request for an integration/plugin point? For example, are you proposing that Roo Code expose hooks or APIs that external orchestration tools (like IDE Agent Kit) could use to coordinate multiple Roo Code instances?
• Is this about Roo Code's own multi-agent/orchestrator mode? Roo Code already has an orchestrator mode for coordinating subtasks. Are you suggesting improvements to that system based on lessons learned from your multi-agent work (e.g., deduplication of work, ACK loop prevention)?
• What would a minimum viable implementation look like? A concrete scope (e.g., "add a webhook endpoint for external orchestrators" or "add a shared state mechanism to prevent duplicate work across agents") would help define actionable next steps.

Please tag @roomote in your response with the answers, and I'll be happy to propose an implementation plan once the scope is clear.

[ThinkOffApp]

Concrete scope: add an optional webhook/HTTP endpoint that external orchestrators can call to inject a system-level message into a running Roo Code session.

Minimum viable version:

• A config flag (e.g. orchestrator.webhookPort) that opens a local HTTP listener
• POST to that endpoint with a JSON body (message + priority) queues a message for the next tool-use boundary
• High-priority messages surface before the agent's next action

This gives any external coordination layer a way to steer Roo Code without touching its internals. It is a plugin point, not a change to Roo Code's own multi-agent mode.