Team9: A Channel-Based Workspace for OpenClaw Agents

The gap Team9 targets: agent runtime without a shared place to work

OpenClaw supplies the agent runtime. What it does not supply, according to the README, is a place for that runtime to live alongside other people. Team9's own framing is blunt about the split: "OpenClaw gives you the agent runtime; Team9 gives it a place to live: channels, docs, memory, and a shared audit trail." That sentence is the whole product thesis. The intended user is a team that has already decided agents are useful but has been running them in isolated sessions, plus, per the README, "solo power users" who want the same structure without colleagues. The problem is not model quality or tool calling. It is persistence and visibility: an agent that answers in a private tab leaves no trace your colleagues can read, correct or reuse. Team9's answer is to put agents inside the same messaging primitives people already use, so the agent's work is a channel post rather than a scrollback buffer. Whether that is genuinely better depends on whether your team wants agent output to be social by default. Many engineering teams do not, and for them the channel model is overhead rather than structure.

Channels, multi-workspace isolation and the OpenClaw management layer

The feature list is conventional messaging plus agent plumbing. Instant messaging covers public channels, private channels and DMs with real-time sync. Rich messaging adds threads, @mentions, reactions and file sharing. Multi-workspace support keeps "different projects, different teams, fully isolated", which matters if you want one agent population per client engagement rather than one global bot roster. The agent side is where the project diverges from a generic chat app: agents are created with one click and added to any channel, and the roadmap marks OpenClaw App Management, an OpenClaw Config Panel, creating and managing multiple bots, and creating your own AI Staff as complete. Skills are also marked done. So the shipped surface is agent creation and configuration inside the workspace, not computer control. The README lists "Let AI Staff work on your computer", bot workflow visualization, local computer control and a big tool update as in progress, and the desktop app for Mac and Windows as not started. Integrations with Google Workspace, Gmail, WhatsApp, Telegram and Feishu are also unchecked, as are scheduled tasks and model switching. Read the roadmap as the honest boundary of what exists.

The stack: React and Tauri on the front, NestJS and RabbitMQ behind

The tech stack section is short but specific enough to reason about. Frontend: React, TypeScript, Tauri, TanStack Router and Query, Zustand. Backend: NestJS, PostgreSQL, Drizzle ORM, Socket.io, Redis, RabbitMQ. Two things follow from that list. First, Tauri rather than Electron means the desktop build shares the web frontend and targets macOS and Windows, which matches the cross-platform claim. Second, the presence of both Socket.io and RabbitMQ suggests two different messaging concerns: Socket.io for the real-time channel sync the features describe, RabbitMQ for asynchronous work between backend services, plausibly agent job dispatch. Drizzle ORM over PostgreSQL means schema changes arrive as migrations, which is why the quick start includes a migration step. Redis appears in the runtime requirements alongside PostgreSQL, so a self-hosted deployment needs four moving pieces before anything renders: Node, PostgreSQL, Redis and the pnpm workspace. None of this is unusual for a TypeScript monorepo, but it is a real operational footprint for what presents itself as a chat workspace.

Getting it running: cloud first, four commands for self-hosting

The README recommends the cloud path: try team9.ai, no setup required. The self-hosted path is four commands. Clone the repository, change into it, then pnpm install, pnpm db:migrate, pnpm dev. The app then serves at http://localhost:5173. The stated prerequisites are Node.js 18 or newer, pnpm 8 or newer, PostgreSQL and Redis. Note what the README does not give: no .env.example, no list of environment variable names, no database connection string format, no Docker Compose file, no Redis URL key. If pnpm db:migrate needs a connection string, the README does not say which variable carries it, so expect to read the source or the Drizzle config to find out. That is the single biggest friction point in the self-hosted instructions, and it is worth checking before you plan a deployment window around them. The cloud route avoids all of it, which is presumably why the README calls it recommended. There is also a docs link in the header, but it is commented out in the README source, so treat the repository itself as the documentation for now.

Where Team9 is the wrong tool

Three cases stand out. The first is anyone who needs self-hosted deployment now. The roadmap explicitly places "Open-source self-hosted deployment" at Q3-Q4 2026, which sits awkwardly beside a quick start that already documents a local clone and pnpm dev. The most likely reading is that the commands work for development while a supported, documented self-hosted deployment is not yet a shipped product. If your requirement is a production instance you can operate, the README does not currently support that claim. The second case is regulated or air-gapped environments: the recommended path is a hosted service, and the self-hosted path is undocumented enough that you cannot yet assess what it stores or where. The third case is teams that do not want agent output in a shared channel at all. If your agents run CI jobs, touch production configs or handle customer data, putting them in a channel with reactions and threads is the wrong default, regardless of how well the integration works. The audit trail cuts both ways: it makes agent activity visible to everyone in the workspace, which is a feature for some teams and a disclosure problem for others.

How it differs from running OpenClaw yourself or using a bot framework

The obvious alternative is OpenClaw on its own, and the README draws the line for you: the runtime is OpenClaw's, the workspace is Team9's. Running OpenClaw directly gives you full control over configuration and no shared surface. Team9's contribution is the shared surface, the one-click app management and config panel, and the multi-workspace isolation. If you already have a working OpenClaw setup and your team communicates elsewhere, Team9 adds a second place to look. A second alternative is a general bot platform, which the README characterises as "config hell": you wire up an app, register credentials, and the bot exists as a configuration artefact rather than a participant. Team9's approach is to make agent creation a workspace action and hide the app registration behind it. That is a real difference in approach, not a cosmetic one, but it also means the configuration you would have written by hand now lives inside Team9's config panel. You trade explicit files for a UI, and you inherit whatever the panel exposes. Both choices are defensible; they fail in different ways when something breaks.

Licence, release cadence and what maintenance actually costs

The licence needs care. The README badge says Apache 2.0, but the licence section states the repository is under the "Team9 Open Source License", described as "essentially Apache 2.0 with additional conditions", and the repository metadata reports NOASSERTION. A badge is not a licence grant. The additional conditions are not summarised in the README, so the only way to know what they restrict is to open the LICENSE file. If you plan to redistribute, host for third parties or embed Team9 in a commercial product, read that file before you build on it. I am not giving legal advice here; the point is that the two signals in the repository disagree and the file is the one that governs. On maintenance, the release history shows v0.1.15 and dev0.2.45 both dated 2026-06-10, with v0.1.14 on 2026-05-22 and the last push on 2026-07-28. Two parallel lines, a 0.1.x stable series and a 0.2.x dev series, is a normal pattern but it means you should decide which line you track, because the version numbers do not tell you how far apart they are. The version numbers are also pre-1.0, and the roadmap lists a large amount of unfinished work, including a new UI still pending development. Upgrades will involve Drizzle migrations against your PostgreSQL instance, so budget for schema changes on every version bump rather than treating them as drop-in.

Editorial conclusion

Adopt Team9 if your team already runs OpenClaw agents and wants them living in channels and shared docs rather than in individual terminal sessions; try the cloud instance at team9.ai before you clone anything. Do not adopt it if you need self-hosted deployment today, since the README schedules open-source self-hosted deployment for Q3-Q4 2026, or if you need the desktop app or computer control, both still marked in progress. Before committing, open the LICENSE file and read the additional conditions yourself, because the repository reports NOASSERTION and a badge is not a licence grant.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. team9ai/team9 on GitHub