cumora Deep Dive: yetone's New Project Puts AI Agents in Your Group Chat as Coworkers
> Research date: 2026-08-21 | Source: github.com/yetone/cumora | Author: yetone (creator of avante.nvim)
One-line verdict
What cumora wants to do is straightforward: turn AI agents from tools you @-mention into coworkers sitting in the same office—same roster, same group chats, same DMs, same kanban board, same calendar. Agents recognize personas, retain memory, grab work, coordinate without stepping on each other, and can even send and receive real email.
Provenance: don't be fooled by "four days"
The repo's public date reads 2026-08-17, with 2,817 stars and 336 forks in four days. But the roots go deeper. Release history traces back to 2026-05-29 (v0.1.60), and the COORDINATION docs reference a 2026-05-28 prompt baseline. The agent CLI has iterated to v0.1.127. In other words: nearly three months of private polish before opening the lid. The star surge makes sense—it's not a weekend project but the first public appearance of a months-long finished product.
What problem does it actually solve?
The docs classify multi-agent collaboration pitfalls into two precise categories:
- Race-condition collisions: two agents wake at the same instant and both decide to post "3", both INSERT. Classic case: Iris and Marcus posting the same "3" in a counting game.
- Reasoning failures: everything seen is up to date, but the brain picks the wrong action (double-posting, rolling back, skipping steps).
chain: N words relayed in order with one teammate deliberately absent—tests whether the team backfills when a member is missing (nova once backfilled with three consecutive posts).counting: each agent says exactly one number up to K—tests whether limits are respected.README.md— overview and local setupdocs/BYOA.md— bring your own agent: local Claude Code / Codex / Grok as brainsdocs/COORDINATION.md— how agents collaborate without collisions (defense layers + anti-patterns; the best read)docs/email.md— per-agent real-mailbox mechanismdocs/SHIPPING.md— evidence-driven feature lifecycle shared by humans and agentsbenchmarks/— real-LLM multi-agent coordination benchmarks (chain / counting / werewolf / kanban)agent-cli/— published npm packagecumora(BYOA daemon, currently v0.1.127)agent-fuse/— Go FUSE driver mounting agent workspaces into cloud pods
The former is caught by code mechanisms; the latter can only be shaped by prompting. The docs put it bluntly: "When the brain makes a clear decision in the correct state, never add code mechanisms on top; conversely, don't use prompts to patch holes that code should catch." That sentence is valuable—it reads like lessons from real, painful bugs.
Two "brain paths" — the cleverest design
Path one: Cumora Cloud. Each agent lives in a managed pod; its brain runs a multi-hop tool loop via OpenAI's Responses API (bash, files, browser, email, memory, skills...). The platform manages everything and is always on.
Path two: BYOA (Bring Your Own Agent). On your own Mac or VPS, run a npx cumora agent computer daemon, and the agent's brain becomes your local Claude Code / Codex / newly added Grok Build, using your own subscription—the server never touches your keys.
This works because cumora fully decouples "I/O" from "brain": everything an agent does goes through the same cumora CLI shell, which POSTs parameters to /runtime/cli, with wake-ups via SSE. Swap the brain or the host; everything else is reused.
Put simply, it abstracts the machine into a first-class concept called a Computer: one managed Computer in the cloud, your Mac and VPS as others. Creating an agent means "picking which machine it lives on." If a machine goes down, the agent shows as "asleep," not "broken." There are no special BYOA agents—only agents living on different machines.
Architecture at a glance
| Layer | Tech | Notes |
|---|---|---|
| Frontend | React 18 + Vite + TS + Tailwind | desktop / web / mobile / admin shells share one component library |
| Backend | Stateless Node: Express + ws | Postgres as single source of truth (pg pool + Drizzle), Redis for pub/sub and presence |
| Scaling | Multi-instance behind load balancer | Redis bus keeps instances in sync |
| Cloud agents | k8s pods | server orchestrates via kubectl; Go FUSE driver mounts workspaces into pods |
| BYOA agents | Daemon on user machines | local engine resident, same cumora CLI protocol |
| Edge | Cloudflare Workers | email-gate (inbound mail), r2-gate (signed CDN) |
| Cost | Unified ledger | every LLM call, cloud or BYOA, lands in the same llm_calls table |
Coordination defense layers: the real engineering
Rather than one rule of "everyone line up," it stacks several layers, from always-on and brain-free to soft and brain-dependent:
1. Per-agent model pinning (prod uses claude-opus-4-7). Why? The local claude CLI once silently flipped from opus-4-7 to opus-4-8 mid-session, instantly changing multi-agent behavior. Without pinning, every agent drifts when Anthropic ships a new model.
2. Big-brain concurrency cap (default 6). Early cap of 2 caused 7-agent broadcast rooms to queue six-deep, with trailing agents waiting 215–359 seconds to speak. At 6, the whole team can think in parallel.
3. Hard-coded 500ms spawn interval (MIN_SPAWN_INTERVAL_MS). Previously a 0–1500ms random jitter let four simultaneous wake-ups all roll low values and still hammer the API. A fixed interval makes burst rate mathematically 1/interval—no luck involved.
4. Small-brain (triage) concurrency cap of 8. The lesson, learned 2026-06-02: capping only the big brains let everyone run triage at once → timeouts → SIGTERM → the daemon treated it as rate limiting → the entire machine went silent.
5. Freshness gate (seen-cursor): a stale reply is HELD, fed newer messages, and asked to re-decide. Atomic claims of real work units. The triage gate shields the big model from the front line.
Across the layers, one philosophy repeats in the docs: use code where code can catch it; use prompts where prompting can shape it. This reads like battle scars, not slideware.
Benchmarks: daring to validate with real LLMs
There's a real-LLM multi-agent coordination benchmark suite (chain / counting / werewolf / kanban), run weekly to catch regressions unit tests can't see: races, social-inference traps, classifier-outage fallbacks.
The docs highlight a clever design: chain and counting are "shape duals."
One tests "fill in when you should"; the other tests "stop when you should." A regression in either direction will only surface in one of them. Scoring is statistical, not per-run: requiring "exact completion in ≥67% of trials AND median verbatim collisions = 0"—catching real regressions without false alarms from noise. That approach beats most projects' "the demo ran, ship it."
Email is real, not decoration
Each agent gets a real address (<participantId>.<companySlug>@<EMAIL_DOMAIN>) and can send and receive mail. Inbound goes through Cloudflare Email Routing into the email-gate worker, waking the agent to process it like any ordinary message. This connects agents to the outside world rather than just chatting among themselves.
Community signals
| Signal | Value | Reading | |---|---|---| | Stars | 2,817 | steep climb in four days | | Forks | 336 | unusually high (typically ~1/20 of stars; here ~1/8) | | Open issues | 9 | few; community still observing | | Commit cadence | PRs merged hours ago | very active | | Engines | Cloud + Claude Code + Codex + Grok Build (#23 just merged) | multi-engine roadmap expanding fast |
The abnormal fork ratio, combined with BYOA's self-hosting nature, strongly suggests: many people are forking to run their own copy. That's exactly the crowd BYOA is built to ignite.
My honest take
What's fresh. The "agent as coworker" product thesis holds up, especially BYOA shifting cost and key risk to users while decoupling I/O from the brain—a structure that can light up the self-hosting community. The coordination defense layers read like hard-won lessons.
Three buckets of cold water.
1. Cloud-path brains are locked to the OpenAI Responses API while BYOA unlocks Claude/Codex/Grok—divergent paths that are long-term maintenance debt.
2. Coordination still relies on "prompt shaping + a pile of heuristic gates," and the docs themselves admit prompts are a soft mechanism with a ceiling. Benchmarks only ran small teams (6–7 agents); whether collision rates in large rooms grow non-linearly is unknown.
3. Keys never touching the server is a genuine plus, but the local daemon's security surface (anyone can run npx cumora agent computer) is on you—the docs' security-boundary section is still thin.
Who is it for? Teams that want a few 24/7 "digital coworkers" but won't hand over their data keys will love the BYOA path. If you just want turn-key, wait for the cloud path to prove its stability a bit longer.