OpenCrew: A Multi-Agent Layer on Top of OpenClaw, Routed Through Slack Channels

The Problem OpenCrew Targets: One Agent Doing Every Job

OpenCrew's README frames the underlying issue bluntly: the problem is not that OpenClaw is weak, it is that a single agent is not enough. The failure mode it describes is context bloat. One agent handling every domain accumulates unrelated history, and the README characterises the symptom as the agent becoming sluggish mid-conversation. A second complaint is operational: running several projects in parallel means switching sessions with no visual overview of what is in flight. A third is that the agent has no model of which actions it may take unprompted, so the user confirms every step.

The project also names two slower-acting problems. Experience gained in one conversation stays in that conversation, so the same mistake recurs. And an agent that quietly adjusts its own behaviour has no auditor. OpenCrew's answer to all five is structural rather than model-level: split the work across several agents, give each one a channel, and add dedicated agents whose only job is knowledge extraction and change auditing.

The intended audience is stated in the README as decision makers, and the deployment path is designed to be executed by an existing OpenClaw instance rather than by a human typing commands. The README claims the documentation structure was tuned so that an OpenClaw can read it and complete deployment with minimal human intervention. That claim is about the documentation, not a measured outcome, and no benchmark is supplied for it.

Channels as Job Slots: The Routing Model Behind OpenCrew

The organising metaphor is explicit in the README: a channel is a post, a thread is a task, and #hq is the headquarters channel. Routing is therefore not done by a dispatcher process inside OpenCrew. The platform's own channel membership decides which agent sees a message. Invite the bot to #cto and the CTO agent answers there; invite it to #build and the Builder agent answers there.

The agent roster is split into three layers. Intent alignment sits with the user and a Chief of Staff agent, which the README says represents user intent and pushes tasks forward when the user is absent. Execution covers CTO, Builder, CIO and Research, where CTO decomposes architecture, Builder implements, CIO is described as a replaceable domain expert (investment, legal, marketing), and Research investigates on demand. System maintenance covers KO, which distils reusable knowledge from outputs, and Ops, which audits changes and guards against drift.

The minimum viable configuration is documented as three agents: CoS, CTO and Builder. KO, Ops, CIO and Research are optional additions. One design point is worth flagging because it contradicts how multi-agent systems are often drawn: the README states that CoS is not a gateway, and that a user who wants to talk to a particular agent simply enters that agent's channel. That removes a single point of failure but also means there is no central place where all traffic is logged by OpenCrew itself.

A2A v2 and the Shared-Bot Ceiling

The v0.3.0 release notes describe an architectural limit that existed from the project's start: when all agents share one Slack bot, the bot cannot trigger itself, so agents could only delegate one-way tasks through sessions_send. Discussion between agents was not possible. The release notes call this the biggest architectural constraint the project had.

The fix is to give at least one key agent its own Slack App. That independently identified bot can then be pulled into any execution agent's channel, where higher-level conversation (direction, review, consensus) happens alongside file-based collaboration in Markdown, with the user reviewing the final output. The release notes list three roles that justify independence: a Chief of Staff representing user intent, a Planner or Coordinator that expands requirements into acceptance criteria, and a QA or Evaluator. The reasoning given for separating QA is that an AI grading its own work tends to be lenient with itself. The README notes a minimum path of making just one agent independent and letting it cover those roles.

The setup is described as three steps: create a separate Slack App, configure multiple accounts, and invite the bot into the target channel. The README points to docs/A2A_SETUP_GUIDE.md for the detail. Critically, the README states that the collaboration discipline (the @mention check, turn counting, and NO_REPLY handling) depends on prompt rules, not system enforcement. It reports that Claude Opus 4.6 was stable in testing and advises testing other models in a low-risk channel first. That is an honest disclosure of a soft guarantee, and it is the single most important thing to understand before relying on discussion mode.

Getting It Running: Platform Choice, Channels, and the Deployment Prompt

The prerequisite is a working OpenClaw installation, verified by openclaw status returning successfully, plus a connection to the chosen platform. Three platforms are supported with different trade-offs. Slack is described as the most flexible and convenient, with full thread support but a single shared bot identity. Feishu supports per-agent bot identities but the README marks thread-based task isolation as not currently supported and links to a differences page. Discord supports both full threads and either independent bots or a Webhook Relay approach for per-agent identity.

Manual setup means creating channels and inviting the bot to each with /invite @yourbotname. The documented default set is #hq for CoS, #cto for CTO and #build for Builder, with #invest, #know, #ops and #research as optional extensions. The default mode across all three platforms is a single bot joining multiple channels, with routing by channel.

The documented deployment path is to hand the job to an existing OpenClaw. The README supplies a prompt template that instructs the agent to clone https://github.com/AlexAnys/opencrew.git into /tmp/opencrew, write the platform tokens into configuration without echoing them, and then read DEPLOY.md and follow it. The prompt explicitly tells the agent not to modify the user's models, auth or gateway configuration and to make only OpenCrew-specific additions. According to the README, the agent then backs up existing configuration, copies agent files, resolves channel IDs, merges configuration and restarts. Separate prompt variants are provided for Feishu (App ID and App Secret) and Discord (bot token).

Verification is a three-step test: send a message in the CoS channel and expect a reply, do the same for CTO, then have CTO assign a task to Builder and expect a reply in Builder's channel. Troubleshooting and error lists are deferred to docs/GETTING_STARTED.md.

Autonomy Levels and Task Classification as Configuration

Two mechanisms govern what agents do without asking. The Autonomy Ladder has four rungs. L0 means suggest only. L1 covers reversible actions such as drafting, research and document organisation, which the agent may do directly. L2 covers impactful but rollback-able actions such as opening a pull request, changing configuration or writing analysis, which the agent does and then reports. L3 covers irreversible actions (publishing, trading, deletion, outbound sending) and requires user confirmation.

The second mechanism is QAPS, a task classification scheme the README introduces but does not fully enumerate in the supplied material; the table is truncated at that point. What can be said is that the intent is to apply different handling norms to different task types rather than one uniform policy.

The value of the ladder is that it converts a vague instruction like "be careful" into four named levels that can be referenced in agent instructions. The weakness is the same one that applies to A2A discipline: nothing in the supplied material indicates that L3 confirmation is enforced by the platform rather than by the agent's own instruction-following. A user who needs a hard block on irreversible actions should treat the ladder as a convention, not an interlock.

Where OpenCrew Is the Wrong Tool

The clearest limitation is stated by the project itself: collaboration discipline rests on prompt rules, not system enforcement. Turn counting, @mention checks and NO_REPLY handling are conventions the model is asked to follow. A model that drifts from them will produce agents that talk over each other, fail to yield, or loop. The README's own mitigation is to test in a low-risk channel with the intended model, which is an acknowledgement that behaviour is model-dependent.

The second limitation is platform-specific. Feishu does not support thread-based task isolation according to the README, and the project links to a page explaining the difference from Slack. If your workflow depends on threads as the unit of task tracking, Feishu is the wrong platform for OpenCrew today, regardless of its per-agent bot identity support.

The third is scope. OpenCrew is a Shell-based configuration and documentation layer sitting on top of OpenClaw. It does not replace OpenClaw, and the deployment prompt explicitly forbids touching models, auth or gateway settings. Anyone not already running OpenClaw gets nothing from this repository. Anyone expecting a scheduler, a message bus or a state store inside OpenCrew will not find one in the supplied material.

A fourth, softer issue: the README mentions an Agent Blueprint repository under development for onboarding new agents without manually configuring workspace files, and notes the author has onboarded roughly ten agents through the current framework. That future capability is not available now, so manual workspace configuration remains the path for adding agents beyond the documented set.

How This Differs From Framework-Style Orchestration

The natural comparison is with code-first multi-agent frameworks such as LangGraph or CrewAI, where agents are defined in code, a runtime executes a graph or a crew, and state is passed through an explicit object or message channel. In those systems the orchestration logic is a program you can read, version and unit-test, and the runtime enforces the topology.

OpenCrew inverts this. There is no orchestration runtime in the repository; the Shell code is deployment glue. The topology lives in the chat platform's channel membership and in the agent instruction files. Coordination happens through messages a human can read, and the audit trail is the channel history plus the Markdown files agents write. That buys a very low barrier to entry and makes the system inspectable by non-programmers, which matches the stated audience of decision makers. It also means the guarantees are only as strong as the model's instruction-following, and that reproducing a run means replaying a conversation rather than re-executing a graph.

A second comparison point is the A2A protocol itself, which appears as a topic tag and as shared/A2A_PROTOCOL.md. The supplied material describes A2A here as OpenCrew's internal agent-to-agent collaboration model built on independent bot identities, not as an implementation of an external interoperability standard. Readers should not assume cross-vendor agent interoperability from the tag alone.

Licence, Maintenance and Upgrade Cost

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is a permissive licence and imposes no copyleft obligation on your own code. It is not legal advice; if you are embedding OpenCrew in a product, have your own counsel review the LICENSE file in the repository rather than relying on the badge.

On maintenance, the observable signals are the release cadence and the changelog content. v0.2.1 added Feishu and Discord support, v0.2.2 added independent bot identities for Feishu and three options for Discord, and v0.3.0 introduced A2A v2. The gaps between those dates are roughly one month and one month respectively, and the last push recorded is 2026-04-05, shortly after v0.3.0. The project is not archived.

Upgrade cost is where the architecture matters. Because deployment merges configuration into an existing OpenClaw setup and the deployment prompt instructs the agent to avoid touching models, auth and gateway settings, the blast radius of an upgrade should be limited to agent files and channel routing. The README also states the deployment process backs up existing configuration before copying agent files. The real upgrade risk is not code but prompts: A2A v2 changed how agents coordinate, and any customised agent instructions you have written may need to be reconciled with the new protocol described in shared/A2A_PROTOCOL.md. Budget for re-reading that file and the per-platform setup guides at each minor release, not just for pulling the repository.

Editorial conclusion

Adopt OpenCrew if you already run OpenClaw and have hit the point where one agent's context is crowded by unrelated domains, and if you are willing to run the three-agent minimum of CoS, CTO and Builder. Do not adopt it if you need hard, system-enforced guarantees about agent turn-taking, or if you rely on Feishu, where thread-based task isolation is documented as unsupported. Before committing, read shared/A2A_PROTOCOL.md section 7, the known limitations list, and test discussion mode in a low-risk channel with the model you actually intend to use, because the README states the collaboration rules depend on prompt discipline rather than platform enforcement.

Official sources

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