Cumora: team chat where the AI agents are on the roster, not in a sidebar

The problem Cumora is aimed at: agents with no shared room

Most agent tooling assumes one human talking to one agent in one terminal. The moment two people and three agents need to work on the same thing, that model breaks: there is no shared roster, no shared history, and no way for an agent to know that another agent already picked up the task. Cumora's answer is to make the chat product itself the coordination surface. Agents appear in the same roster as humans, get DMs, sit in group conversations, and are assigned cards on the same Kanban board. The README describes the target directly: agents "hold personas and memory, claim work, coordinate with each other without colliding, send and receive real email." That last clause is unusual. Inbound mail arrives through a Cloudflare Worker called email-gate, outbound mail goes through Resend, so an agent can be reached at an address rather than only inside the app. The intended user is a small product or engineering team that already runs coding agents and wants their output visible to everyone, not trapped in one developer's scrollback.

Architecture: a stateless Node server, Kubernetes pods, and a CLI contract

The README's architecture diagram splits the system into four layers. The frontend in src/ is React 18 with Vite, TypeScript and Tailwind, wrapped in four shells (desktop, mobile, web, admin) that share the same components. The backend in server/ is described as a stateless Node service built on Express and ws, with Postgres as the source of truth and Redis for pub/sub fan-out and presence. The detail worth pausing on is the realtime outbox: durable board, document and calendar writes enqueue invalidations in a transactional PostgreSQL outbox, and any number of server instances drain it through leased SKIP LOCKED claims in server/src/realtime-outbox.ts. The README states the consequence plainly: Redis degradation delays live refresh but never changes the command result, and clients reconcile by pulling the API. That is a deliberate trade of freshness for correctness, and it is the kind of choice that shows up later as a UI that occasionally needs a reload. Agent runtime has two paths. Cloud agents live in per-agent Kubernetes pods orchestrated through kubectl, with a Go FUSE driver in agent-fuse/ mounting their server-side workspace. BYOA agents run wherever you start the daemon. Both speak the same cumora CLI protocol, and every LLM call from either path lands in one llm_calls cost ledger, which is the only place you can see what cloud and local agents spend together.

Installing Cumora locally and getting to the first agent turn

The README's local path assumes Postgres and Redis are already running; Homebrew services are named as acceptable. The first command creates the database, then the OpenAI key is exported. The setup script installs root dependencies plus the Email Worker dependencies, and dev:all runs migrations before starting two processes: Vite on port 5180 and the API server on port 5181.

createdb -h localhost cumora
export OPENAI_API_KEY=sk-...

npm run setup
npm run dev:all

Open http://localhost:5180 for the PWA, or run npm run electron:dev for the desktop window, which also applies migrations. The seeding behaviour is the part to understand before you judge the product: the README says an empty database is seeded with a starter team of 6 agents, 3 humans and 9 conversations, and zero messages. Nothing in the chat history is canned, so the first thing you see is an empty room and the first thing you type is what fills it. Only OPENAI_API_KEY is hard-required. Everything else has a local default or soft-disables when unset, and the README names server/src/env.ts as the authoritative list of optional feature groups, with .env.example annotating a commonly-edited subset. The defaults table gives DATABASE_URL as postgres://$USER@localhost:5432/cumora, REDIS_URL as redis://localhost:6379, and PORT as 5181.

For the BYOA path, the README points at npx cumora agent computer to pair your own Mac or VPS, with the agent running on your local provider account. The supported engines listed are Claude Code, Codex, Grok Build, Cursor Agent, OpenCode, pi, Gemini CLI, Qwen Code, Antigravity and ZCode. Claude Code and Codex get fail-closed filesystem, command-network and subprocess-credential boundaries by default; the README says the other engines require an explicit unsandboxed compatibility opt-in, and that the server never sees your provider keys. If you plan to use anything other than those two engines, that opt-in is the decision you are actually making.

The coordination gate is the real product, and it is also the main risk

Agents that share a room will talk over each other unless something arbitrates. Cumora's mechanism, per the README, is a seen-cursor freshness gate: a stale reply is HELD and the agent is shown the newer messages so it can decide again. On top of that sit atomic claims on real units of work, and a small-brain triage gate that shields the big model. The two-tier model split is enforced in CI rather than left to convention: npm run guard:big-brain is described as a guard that only agent turns may use the big model, with the cheap tier handling JSON classifiers, palette and gender inference, and heartbeat agenda triage. That is a stronger constraint than most projects of this shape bother to encode. The risk is that the held-reply loop is a re-decision, not a queue. Under a fast-moving room an agent can be shown newer messages repeatedly, and the README does not document a bound on how many times that happens or what the user sees while it is happening. If your team expects instant replies in a busy channel, this design will feel slow, and the documentation does not offer a way to turn it off.

Where Cumora is the wrong tool

Cumora is not a Slack or Teams integration, and the README makes no claim that it is. If your team lives in an existing workspace and you want an agent to answer there, Cumora does not solve that: it is the workspace. The second boundary is operational weight. Running it yourself needs Postgres and Redis, and the cloud path needs Kubernetes with kubectl orchestration and a FUSE mount inside each pod. That is a real infrastructure surface for a chat app, and the README does not describe a single-binary or SQLite mode. Third, the test story has a trap the README flags itself: the integration suite prints [integration] skipped and exits 0 without INTEGRATION_DATABASE_URL, which looks like a pass, and it TRUNCATEs every table, so it needs a throwaway database. Anyone wiring this into CI without reading that paragraph will believe a suite ran when it did not. Finally, mobile coverage is uneven. The iOS app is distributed through TestFlight as a beta, and the README states Android is not published yet and must be built from android/.

How Cumora differs from running Claude Code or Codex on their own

The obvious alternative is what most teams do now: each developer runs Claude Code or Codex in a terminal and pastes results into a shared channel. Cumora's BYOA mode does not replace those engines, it reuses them. The difference is where state lives. In a terminal, the transcript belongs to one machine and one person; in Cumora, the agent is a roster entry with memory and persona, its work is claimed atomically so two agents do not take the same card, and its LLM calls are recorded in the same cost ledger as cloud agents. The trade is control. A terminal session gives you an unsandboxed shell with your full environment; the README says Claude Code and Codex under Cumora run with fail-closed filesystem, command-network and subprocess-credential boundaries by default. That is a meaningful restriction, and for engines other than those two the README requires you to opt out of sandboxing explicitly to get compatibility. If your workflow depends on an agent reaching arbitrary hosts or credentials, Cumora's default posture will block it, and the opt-in is the escape hatch rather than the norm.

Licence, upgrade cost, and what the release cadence suggests

Cumora is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is the whole of the licence implication here; whether your organisation accepts MIT for a product this close to your internal workflows is a question for your own review, not something the repository answers. On maintenance, the last push was on 2026-09-10 and the repository is not archived. Three releases landed in quick succession around 2026-08-28 and 2026-08-29: v0.7.0, v0.8.0 and v0.9.0, while package.json carries version 0.18.2. That gap between the release tags and the manifest version is worth noting if you plan to pin: the npm package published from agent-cli/ is what BYOA users install, and it is not necessarily the same number as the repository manifest. Upgrading the server means running npm run migrate, which dev:all and electron:dev already do for you. Upgrading a BYOA daemon means the engine you paired, and the README's warning about the unsandboxed opt-in applies again after any engine change. There is no documented rollback procedure in the README, so treat a migration against a production database as a one-way step until you have verified otherwise.

Editorial conclusion

Adopt Cumora if you already have a team that talks to Claude Code or Codex in a terminal and wants those sessions to live in a shared room with a board and a calendar, and if you are willing to run Postgres and Redis locally or let Cumora Cloud host the pods. Do not adopt it if you want a drop-in chatbot for a Slack workspace you do not control, or if you need Android today: the README says Android is not published yet and must be built from android/. Before committing, run npm run dev:all, confirm the seeded starter team appears with zero messages, and read docs/COORDINATION.md and docs/BYOA.md to check that the seen-cursor gate and the fail-closed sandbox match how your team actually works.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yetone/cumora on GitHub