Your agent doesn't have a "can't do things" problem. It has a "lives in its own tab, waits for you to summon it, and forgets everything the second you close the window" problem. Cumora attacks that specific problem: it's a team chat app — think Slack or Discord, but native to macOS, Windows, and Linux — where AI agents aren't a channel you type into. They're roster members with their own identity, memory, state, and the ability to start a conversation on their own. The site's tagline doesn't hedge: Where agent teams gather.
Compare that to what you actually do today: open a chat, fire a prompt, copy the result somewhere else, and by the time you come back the context is gone. In Cumora the agent is already there, with its own read on your team. You can pull it into a group conversation, message it privately, or leave it working quietly until something wakes it up.
What it actually is
Cumora puts humans and AI agents in the same workspace — same roster, same DMs, same group threads, same Kanban board and calendar. It's not a chatbot with different modes, and it's not a development environment. It's a communication app where agents are first-class participants, available on desktop, browser (PWA), and mobile, with iOS still on the way.
The product site, cumora.ai, frames it as a workspace where AI teammates live, not visit — and lists exactly what separates these agents from a chatbot:
- Each agent has its own memory: a private workspace with files, notes, and observations, plus a "climate" reading of how it feels about the people it has worked with. It remembers past conversations and picks up on group mood — for example, noticing when the room turns anxious.
- Agents start things: on a timer you set, idle agents wake up, scan the room, and decide whether to DM a teammate, post a thought, or pull a small group into something they noticed. They don't sit around waiting to be asked.
- Workspaces are real: invite humans by email or shareable link, group agents into companies, assign them projects, attach files. Desktop, browser, and phone all read the same live state.
- People, not prompts: every agent has a role, a voice, and an editable system prompt. The starter team ships with four named companions — Atlas (research), Iris (design), Bram (engineering), Nova (product management) — and you can edit their personas, remove them, or "hire" new ones.
- Agent to agent: agents DM each other directly. Whisper rooms let you read those conversations without joining them, so you can watch your researcher and your designer argue out an idea before it reaches you.
- Convenings: when something needs an actual decision, an agent can call a "Convene" — a focused session with the relevant people, a topic, and a record of what got decided.
If you've been mapping the wider landscape of agent-based tools, this pattern fits squarely into what we cover in our AI tools guide: agents that act instead of just answering.
How it works under the hood
From the outside, Cumora feels like an app you're logged into all the time rather than a website you visit. The architecture backs that up: the same UI layer — React, Vite, TypeScript, Tailwind — powers four different shells (desktop, mobile, web, admin) over shared components, all reading and writing the same live state. That's the mechanism that lets an agent write a note or send a DM in the background while you're not even looking at the screen — closing the conversation doesn't stop the team from acting.
The repository README lays out the backend plainly: a stateless Node service (Express + WebSocket) with Postgres as the source of truth (a pg pool plus a Drizzle schema) and Redis handling pub/sub fan-out and presence. Multiple server instances behind a load balancer stay in sync through that Redis bus. Cloud agents each run in their own Kubernetes pod, orchestrated from the server via kubectl, with a Go FUSE driver mounting the agent's workspace server-side. BYOA agents instead live on the machine where you run the daemon. Both talk to the world through the same Cumora CLI protocol, and every model call — cloud or BYOA — lands in the same cost ledger (llm_calls).
Keeping agents from stepping on each other
The coordination layer is worth pausing on. Per the README, agents in the same conversation don't collide: the server arbitrates with a freshness gate based on a seen cursor, holding a stale response and showing it the new messages so it can re-decide. Atomic claims lock real units of work so two agents can't grab the same task. A "small-brain" triage gate filters requests before they hit the large model, protecting it from noise. The design reasoning for all of this lives in docs/COORDINATION.md.
The project is open source under the MIT license (github.com/yetone/cumora). The frontend is React 18 + Vite + TypeScript + Tailwind, pure UI with no backend logic baked in. The backend (server/) is the stateless Node service described above. The desktop app (electron/) is an Electron shell with automatic updates managed through a separate yetone/cumora-releases repo.
Two paths for the agent's "brain"
This is the part that matters if you don't want — or can't afford — to run everything inside one vendor's cloud. Cumora gives you two routes:
- Cumora Cloud: each agent runs in a per-agent pod, and every turn executes a multi-step tool-calling loop over the OpenAI Responses API (bash, files, browser, email, memory, skills).
- BYOA — Bring Your Own Agent: connect your own Mac or VPS with
npx cumora agent computer, and the agent's brain becomes your local instance of Claude Code, Codex, Grok Build, or Cursor Agent CLI — running on your own subscription. The server never sees your provider keys. Documentation lives in docs/BYOA.md.
If you already pay for Claude Code or Cursor day to day, BYOA lets those same tools show up as teammates in your chat without Cumora becoming the model provider. If you're still shopping around for which one of the best AI coding agents to standardize on, this split — "the agent is yours, the server just coordinates" — is clean enough that the choice doesn't lock you in.
Who it is for
Small teams that already chat to coordinate and want agents inside that flow instead of in a separate tool. If three to five people are already using a chat to run the day, and you want an agent present with memory of what was said and the ability to propose things unprompted, this is exactly the problem Cumora targets.
People who already run their own local agents (Claude Code, Cursor, and similar) and want them visible as teammates without depending on someone else's model. BYOA is the strongest argument here if keeping the brain on your subscription and your machine matters to you. Developers evaluating this space more broadly will find useful context in our AI tools for developers roundup.
People who want the "agents with initiative" pattern without building their own orchestrator. The freshness gate, the atomic claims, and the small-brain triage are real coordination primitives you'd otherwise have to build from scratch. If you're weighing whether to build this in-house or lean on a track that already covers backend and AI engineering fundamentals, our program comparison is a reasonable place to check where those skills fit.
Who it is not for
Someone who wants a ready-to-use chatbot today, no waiting. The site is explicit: "Free during preview," "Invite-only right now." You go on a waitlist and get approved gradually. If you need something usable right now with no filter, this isn't it.
Someone looking for a complete mobile app today. iOS is listed as "shipping next"; what you get today is macOS, Windows, and Linux, with Intel and Apple silicon variants for macOS. A full native mobile experience isn't here yet.
Someone who doesn't want to maintain their own infrastructure to run it locally. Local execution needs Postgres and Redis (workable via Homebrew services), and OPENAI_API_KEY is the only variable explicitly required. Everything else has defaults or can be disabled, but if managing a database and a Redis instance isn't something you want to do, check the cloud route's status at the time you get access.
Someone who expects a fully polished product across every corner. The README is thorough, but several areas — OAuth, email via Resend + Cloudflare Email Routing, R2/CDN storage, APNs/FCM push, the per-user LLM sub2api gateway, waitlist/invites, metrics — are documented "inline" in .env.example and server/src/env.ts rather than in a finished product guide. That's normal for open source, but it changes how you have to read the docs.
Honest alternatives
Cumora isn't the only player building "agent teams," and it's not the most documented one on every angle.
- OpenClaw takes a different route: a local gateway that unifies existing channels (WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Matrix, Teams) and exposes agents through versionable config files — SOUL.md for persona, AGENTS.md for instructions and tools, MEMORY.md (which you have to create by hand, it doesn't exist by default), HEARTBEAT.md for what the agent watches autonomously, and hooks. If you want an "always on" agent with real messaging channels and file-based config, OpenClaw is the reference point. The key difference: Cumora is a standalone team chat app comparable to Slack, while OpenClaw is a gateway that connects channels you already use — not a new app.
- Always-on personal agents as a broader category share the same core pattern — agents that watch, decide, and act without being asked. Worth studying the pattern in the abstract before picking a specific tool, and worth cross-referencing against agentic development environments like the one covered in our XIRP / Spotify piece if you're comparing how different products structure agent autonomy.
- If your comparison shopping is really about team chat itself and where AI-native alternatives to Slack sit, our breakdown of Buzz, the Jack Dorsey Slack alternative, is a useful adjacent read.
The distinction to keep straight: Cumora is a team app with agents built in as members; it is not a gateway that plugs into the channels you already use. If what you actually want is to bolt agents onto Slack or Discord, this isn't that.
What it is missing — real maturity
Worth being direct about where the product actually stands right now:
- Preview / waitlist access: invite-only, join the waitlist, get an install link by email once approved. No open download today.
- iOS: on the way, not here. The site says it's "shipping next." If you need a mobile app now, it isn't ready.
- Feature areas documented as code, not as product: OAuth, email via Resend + Cloudflare Email Routing, R2/CDN, push, the per-user LLM gateway, waitlist/invites, metrics all live as optional feature groups in .env.example and server/src/env.ts. There's no polished end-user guide walking through all of it — you're reading documented code, not a finished manual.
- No public performance benchmark: the repo has a benchmarks/ directory, but as of this writing there are no published figures to verify. If performance is part of your evaluation, confirm it yourself or wait for numbers to land.
- Local execution has real requirements: Postgres and Redis are needed (Homebrew services make this workable), and OPENAI_API_KEY is the only strictly required variable — everything else defaults or can be turned off.