Team9: a collaborative workspace for AI agents built on OpenClaw

What Team9 adds on top of the OpenClaw runtime

OpenClaw supplies the agent runtime. Team9 supplies the place the agent lives: public and private channels, direct messages, threads, @mentions, reactions, file sharing, shared documents and a shared audit trail. The README frames the split directly: "OpenClaw gives you the agent runtime; Team9 gives it a place to live." That is the whole pitch, and it is a narrower one than it first appears. Team9 is not an agent framework. It does not train models or define a tool-calling protocol. It is a chat and document surface with agent identities wired into the same message stream as human accounts. The intended user is a small team that already wants agents in the loop and does not want to build a bot platform to get there. The README also notes it "works great for solo power users too," which is a fair description of the current feature set: multi-workspace isolation and per-workspace agents are useful even when the workspace has one human member.

Architecture: a Tauri client over a NestJS gateway with two worker processes

The repository is a pnpm and Turborepo monorepo. The root package.json describes it as "Client (Tauri) + Server (NestJS)" and exposes separate dev targets for @team9/client, @team9/gateway, @team9/im-worker and @team9/task-worker. That four-process split is the most informative thing in the manifest. The gateway is the NestJS HTTP and Socket.io entry point. The im-worker handles instant messaging work, and the task-worker handles background jobs, which is consistent with the RabbitMQ and Redis entries in the tech stack. Data lives in PostgreSQL behind Drizzle ORM, and database commands are namespaced under apps/server: db:generate, db:migrate, db:push and db:studio. There is also a check:migrations script that runs scripts/check-drizzle-migration-order.mjs, a guard against migrations landing out of order. The client is React with TanStack Router and Query and Zustand, wrapped in Tauri for the macOS and Windows desktop builds, with build:client:mac and build:client:windows as distinct targets. Top-level directories include contracts/, infra/, docker/, k6/ and a scripts/ folder, so load testing and container definitions are part of the repository rather than an afterthought.

Installing Team9 locally with pnpm

The README offers a hosted path first: team9.ai, described as requiring no setup. The self-hosted path is four commands, and the README states the prerequisites as Node.js 18+, pnpm 8+, PostgreSQL and Redis. Note that the root manifest pins packageManager to [email protected], so the README's stated pnpm 8+ floor and the pinned version do not match; expect the pinned one to be what CI uses.

git clone https://github.com/team9ai/team9.git
cd team9
pnpm install
pnpm db:migrate
pnpm dev

The db:migrate script delegates to apps/server, so PostgreSQL must be reachable before that step succeeds. The dev script runs four filtered Turbo tasks at once: @team9/client, @team9/gateway, @team9/im-worker and @team9/task-worker. If you only want the server side, dev:server:all runs the gateway and both workers without the client. The README says to open http://localhost:5173 once dev is running, which is the Vite port the client dev server uses. The README does not document which environment variables point the gateway at PostgreSQL, Redis or RabbitMQ, and no .env.example appears in the README text, so expect to read the config modules under apps/server to find the expected keys.

Where Team9 is the wrong tool

The roadmap is honest about what is not finished, and several unchecked items are load-bearing. "Local computer control," "Let AI Staff work on your computer" and "Big Tool Update: More useful tools added" are all marked in progress, and the README's own feature list flags the computer-connection item as a TODO. If your use case is an agent that manipulates files or runs commands on a machine, that capability is described as unfinished, not shipped. Self-hosted deployment is the sharper limitation: "Open-source self-hosted deployment" is unchecked and annotated _(26 Q3-Q4)_, even though the Quick Start already gives self-hosted commands. That is a real tension in the README. Commands exist, but the project does not yet present self-hosting as a supported release path, and there is no documented upgrade procedure, backup guidance or rollback step in the README. Treat a local checkout as an evaluation environment rather than a production deployment. Model switching is also unchecked, so if you need to swap providers per agent, that is on the roadmap, not in the box.

How Team9 differs from running OpenClaw directly or using a bot framework

The obvious alternative is OpenClaw on its own. You would then supply your own interface and identity model: a chat client, a database for message history, and your own mapping from agent to conversation. Team9's contribution is that mapping already made, plus multi-workspace isolation so different projects do not share channels or agent rosters. A second alternative is a general bot platform, which the README characterises as "config hell" and contrasts with one-click agent creation and a config panel. That comparison is self-serving, but the underlying difference is real: a bot platform typically asks you to register an app, obtain credentials and wire webhooks per platform, whereas Team9 treats an agent as a workspace member you add to a channel. The trade is control. A bot platform lets you target Telegram, WhatsApp or Feishu today; Team9 lists those integrations as unchecked roadmap items alongside Google Workspace and Gmail. If your agents must live where your users already chat, Team9 is the wrong layer.

Maintenance cadence, release tags and upgrade cost

The last push to main was on 2026-07-28, roughly seven weeks before this writing, and the repository is not archived. Releases are tagged in two parallel lines: v0.1.15 and v0.1.14 on the stable side, and a dev0.2.45 tag that carries a higher minor number. That dual numbering is worth understanding before you pin a version, because a 0.2.x tag is not a stable release in this scheme. The gap between v0.1.14 (2026-05-22) and v0.1.15 (2026-06-10) is about three weeks, and both 0.2.45 and 0.1.15 were tagged on 2026-06-10 within twenty minutes of each other, which suggests the dev line is cut from the same tree rather than a separate branch. Upgrade cost is the weak point: the README does not document a migration or rollback procedure, so the practical path is to read the Drizzle migrations under apps/server and run pnpm db:migrate, having first taken a PostgreSQL dump. The repository root carries a check:migrations script specifically to keep migration ordering honest, which tells you ordering has been a problem worth guarding against.

Licence: Apache 2.0 with conditions attached

The README badge says Apache 2.0, but the licence section says the repository is available under the "Team9 Open Source License," described as "essentially Apache 2.0 with additional conditions." The repository metadata reports the licence as NOASSERTION, which means GitHub's detector could not classify the LICENSE file as a standard licence. Both signals point the same way: this is not stock Apache 2.0, and the additional conditions are not summarised in the README. There is also an enterprise directory at the repository root and an EDITION-GUIDE.md, which suggests a commercial edition exists alongside the open one. Anyone evaluating Team9 for a product or an internal platform should read LICENSE and EDITION-GUIDE.md before assuming Apache 2.0 permissions apply. This is a description of what the files say, not legal advice; the conditions themselves are the thing to have reviewed.

Editorial conclusion

Adopt Team9 if you want agents with a persistent home in channels and docs and you are comfortable running a NestJS, PostgreSQL and Redis stack from a monorepo whose self-hosted deployment path the README still marks as planned. Skip it if you need a stable self-hosted release today, a documented upgrade path, or plain Apache 2.0 terms. Before committing, read the LICENSE file at the repository root, since the README describes it as Apache 2.0 with additional conditions, and check which of the roadmap items you depend on are still unchecked.

Frequently asked questions

Official sources

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