OpenCrew: a multi-agent team layer for OpenClaw, routed through Slack, Feishu or Discord

The problem OpenCrew solves: one OpenClaw agent is not a team

OpenCrew starts from a specific diagnosis, stated plainly in its README: the problem is not that OpenClaw is weak, it is that one agent is not enough. The README lists the failure modes that follow. An agent that carries every domain accumulates context until it answers slowly. Parallel projects force you to switch sessions by hand because there is no task overview. Every step waits on your confirmation because the agent has no notion of which actions it may take alone. Lessons learned stay buried in chat history, and the agent drifts with no one auditing the drift.

The target reader is someone already running OpenClaw who wants an organisational structure rather than a better prompt. The README frames the audience as decision makers and says the system suits anyone who can follow a setup guide. Roles are borrowed from a company: a Chief of Staff for intent alignment, a CTO for architecture breakdown, a Builder for implementation, plus optional CIO, Research, KO and Ops agents. The README states a minimum viable team of CoS, CTO and Builder.

The mapping that makes this work is channel equals role, thread equals task, and #hq as the headquarters channel. That is the whole organising idea, and it is a good one because it makes the team visible in a tool people already have open.

How OpenCrew routes work: channels, threads and three layers

OpenCrew is a configuration and prompt framework layered on top of OpenClaw. The repository is mostly Markdown and Shell: the top level holds DEPLOY.md, README.md, CHANGELOG.md, LICENSE, and directories named assets, docs, patches, shared, v2-lite and workspaces. Deployment copies agent files into your OpenClaw setup and merges channel routing into its configuration. There is no separate daemon to run.

The README describes three layers. Intent alignment is you plus the CoS, who holds your deeper goals and can push work forward while you are away. Execution is CTO, Builder, CIO and Research, where CIO is described as a replaceable domain expert for investment, legal or marketing work. System maintenance is KO and Ops: KO distils reusable knowledge out of finished output, Ops audits changes and watches for drift. Neither maintenance agent does business work.

Routing is by channel. A single bot joins several channels, and the channel determines which agent answers. The README calls this the default single-bot mode and says it works on all three platforms. Per-agent identity is the advanced path, available on Feishu and Discord, where each agent can have its own bot name, avatar and API quota. Discord additionally supports a Webhook Relay, where one bot receives and replies under different identities.

Two mechanisms govern behaviour. The Autonomy Ladder defines four levels: L0 suggests only, L1 performs reversible actions directly such as drafting or research, L2 performs impactful but rollback-able actions and reports afterwards, and L3 requires your confirmation for irreversible actions such as publishing, trading, deleting or sending externally. The README also names a task classification scheme called QAPS, though the excerpt cuts off before its rules are given.

Installing OpenCrew and getting the first agent to answer

The README states a precondition: OpenClaw must already work for you, with `openclaw status` running successfully, and your chosen platform must already be connected. OpenCrew does not set up OpenClaw for you.

Step one is creating the channels and inviting the bot. In Slack you create each channel and then run the invite command inside it:

/invite @你的bot名

The README's example set is #hq for CoS, #cto for CTO and #build for Builder, with #invest, #know, #ops and #research as optional additions.

Step two is handing deployment to your existing OpenClaw. The README gives a prompt to paste, with the placeholder values replaced. It asks the agent to clone the repository and follow DEPLOY.md:

帮我部署 OpenCrew 多 Agent 团队。

仓库：请 clone https://github.com/AlexAnys/opencrew.git 到 /tmp/opencrew

Slack tokens（请写入配置，不要回显）：
- Bot Token: <你的 xoxb- token>
- App Token: <你的 xapp- token>

请读仓库里的 DEPLOY.md，按流程完成部署。
不要改我的 models / auth / gateway 配置，只做 OpenCrew 的增量。

The README says the agent will back up your existing configuration, copy the agent files, look up channel IDs, merge the configuration and restart. The instruction not to touch models, auth or gateway settings is deliberate: this is meant to be an incremental change to a working install. Feishu and Discord variants of the same prompt are given in collapsible sections, using App ID and App Secret for Feishu and a bot token for Discord.

Step three is verification, and the README gives three checks: send a message in the CoS channel and see a reply, do the same in the CTO channel, then ask CTO to delegate a task to Builder and confirm the reply appears in the Builder channel. If any of those fail, the README points to docs/GETTING_STARTED.md for error cases and a troubleshooting checklist. Manual deployment commands live in DEPLOY.md.

A2A v2: two bots in one channel, and why it is prompt-deep

The April 2026 release addresses what the README calls the project's biggest architectural limit. Under the original design all agents shared one Slack bot, and a bot cannot trigger itself, so agents could only delegate one-way through `sessions_send`. They could not discuss.

The v0.3.0 fix is to give at least one key agent its own Slack App, then invite that app into the channels of the executing agents. The README describes the result as high-level conversation inside the channel, covering direction, review and consensus, alongside actual collaboration through Markdown files and a final human review of the output. Setup is three steps: create an independent Slack App, configure the multiple accounts, and invite the bot into the target channels, with details in docs/A2A_SETUP_GUIDE.md.

The README recommends which agents deserve their own identity, citing Anthropic's harness design writing as a reference point. A Chief of Staff needs to enter other agents' channels to keep execution aligned with your goals. A Planner or Coordinator needs to interact with several executing agents, and the README argues planning should not be done by the executor. A QA or Evaluator exists because, in the README's words, an AI that both executes and self-checks tends to be lenient with itself. The minimum viable version is one agent with an independent app covering all three roles.

The honest part is the compatibility note. The README states that collaboration discipline, meaning @mention checking, turn counting and NO_REPLY, relies on prompt rules and is not enforced by the system. Claude Opus 4.6 is described as stable in testing, and other models are advised to be tried first in low-risk channels, with details under known limitations in shared/A2A_PROTOCOL.md. That is a real constraint: if your model ignores the turn counter, two agents can loop, and nothing in the codebase stops them.

Where OpenCrew is the wrong tool

The clearest limitation is platform coverage. The README's comparison table marks Slack and Discord as fully supporting threads for task isolation, and marks Feishu as not yet supporting them, with a link to a section explaining the difference. If you are a Feishu team and thread isolation is what you want, OpenCrew does not give it to you today. Feishu does support per-agent bots, so the identity story is better there than the task-isolation story.

The second limitation is the one described above: A2A v2 is a convention, not a mechanism. The README itself says the discipline depends on prompt rules. That means the quality of agent-to-agent collaboration varies with your model, and the project's own advice is to test in low-risk channels first. Anyone who needs hard guarantees about turn limits or message loops should look at a framework that enforces them in code.

The third is scope. OpenCrew is not a scheduler, a queue or an observability platform. It has no dashboard beyond your chat client, and the README does not describe metrics, tracing or alerting. If your need is reliable background job execution rather than a conversational team, this is the wrong layer.

Finally, the README notes a roadmap item rather than a shipped feature: an Agent Blueprint repository for onboarding new agents by describing requirements and adding a Slack channel, without hand-editing workspace files. The author states roughly ten agents have been onboarded through the current framework manually. Until that blueprint ships, adding an agent means editing files yourself.

Alternatives and the difference in approach

The obvious alternative is doing nothing beyond OpenClaw itself. A single agent with a well-written system prompt and disciplined session hygiene handles small workloads, and it has no channel routing to maintain and no second Slack app to keep alive. The difference is structural: OpenCrew splits context across agents so no single one accumulates every domain, whereas a single agent relies on you to start clean sessions. If your pain is context bloat rather than coordination, session discipline may be enough.

A second alternative is a code-level agent framework that runs agents as processes with an explicit message bus. Those enforce turn limits and handoffs in the runtime, which is exactly what OpenCrew's A2A v2 does not do. The trade-off runs the other way too: a runtime gives you enforcement and takes away the chat-native interface. In OpenCrew, a task is a thread you can read, search and reply to from your phone, which the README's screenshots show directly.

The third comparison the README invites is between OpenCrew's roles and Anthropic's harness design guidance. OpenCrew's contribution is not the idea of separating planning from execution or evaluation from production; it is packaging that idea as channel routing plus prompt files you deploy into an OpenClaw instance in one guided run. If you already accept the harness argument and just want it running in Slack, that packaging is the value.

Maintenance cost, licence and what to check before adopting

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it is worth checking how it interacts with the terms of OpenClaw itself and of any model provider you route through, since OpenCrew sits on top of both. Nothing here is legal advice; read LICENSE and the upstream terms.

The last push to the default branch was on 2026-04-05, and the most recent release, v0.3.0, is dated 2026-04-03. The repository is not archived. Between April and now there has been no push, so treat the project as a stable snapshot rather than something changing under you. For an MIT-licensed configuration framework that is not necessarily bad: the files you deploy will not shift. It does mean upstream fixes for the prompt-discipline issues described in the A2A notes are not arriving on their own.

Upgrade cost is concentrated in configuration merging. Deployment backs up your existing config and merges OpenCrew's channel routing into it, so a re-deploy after an OpenClaw upgrade means re-running that merge and re-checking the channel-to-agent mapping. The README's instruction to leave models, auth and gateway untouched is what keeps this cheap. If you have added agents beyond the defaults, expect to re-verify each channel mapping after any redeploy, because the routing table is the part most likely to drift out of sync with your workspace.

Editorial conclusion

Adopt OpenCrew if you already run OpenClaw and your single agent's context has become the bottleneck, and you are willing to keep a second Slack app and per-channel routing in sync. Skip it if you have not got OpenClaw working, if you need Feishu thread isolation today, or if you need agent-to-agent discipline enforced by code rather than by prompt rules. Before committing, verify three things: that `openclaw status` runs clean, that a plain test message reaches each agent's channel, and that your chosen model holds the @mention, turn-counting and NO_REPLY rules in a low-risk channel, because the repository states those are prompt conventions and not system constraints.

Frequently asked questions

Official sources

1. AlexAnys/opencrew on GitHub
2. Issues
3. License: MIT
4. README
5. Releases