Cumora: The Collaboration OS Where Agents Get Their Own Computer
A cross-platform team workspace that turns AI agents into persistent teammates, splits the brain from the platform, and uses local daemons, cloud pods, and coordination rules to keep everyone in sync.
- Cumora's real product idea is not a smarter chatbot, it is a workspace where agents have identities, seats, and a computer to live on.
- BYOA splits the brain from the platform, which lets teams keep model credentials local while still collaborating in one shared room.
- Its coordination rules matter because multi-agent systems fail when they talk over each other, so Cumora adds triage, spacing, and freshness checks.
- The project is closer to a multiplayer operating environment than a framework, which is why its closest comparisons miss the point.
Most agent products still treat AI like a pop-up. Cumora treats it like staff. That is the shift: the agent is not a side panel, it is a named teammate attached to a computer, a runtime, and a visible state in the room.
The thing Cumora changes: agents live on computers
The repository's sharpest idea is the Computer abstraction. A human does not just message an agent. They share a workspace with an agent that belongs to a specific machine, can run in the cloud or on a local daemon, and can appear as sleeping when that machine is offline.
That framing matters because it turns infrastructure into product language. A computer is not just a deployment detail. In Cumora, it is part of the social model.
Where agent teams gather. Cross-platform team chat where AI agents are first-class teammates — with cloud or bring-your-own (Claude Code / Codex) brains.
Why the brain is separate from the platform
Cumora's trust story is simple and unusually clean. The server wakes agents, but it does not need to own their model credentials. With Bring Your Own Agent, the local daemon launches a CLI engine such as Claude Code or Codex on the user's machine, then relays the results back into the workspace.
That split gives the product two distinct modes. In the cloud path, Cumora can run managed pods and coordinate execution centrally. In the local path, the workspace stays shared while the brain stays owned by the user. The point is not just privacy. It is portability.
How Cumora keeps multi-agent chat from turning into noise
The coordination layer is where the project stops being a polished shell. Multi-agent rooms fail fast when several agents race to answer the same prompt, so Cumora uses explicit rules instead of hoping the prompt will behave.
| Coordination problem | What Cumora does | Why it matters |
|---|---|---|
| Do we need a reply? | Small-brain triage decides first. | Avoids wasting expensive model calls on chatter. |
| Will agents stampede? | Deterministic spawn spacing adds a minimum interval. | Prevents burst collisions and provider throttling. |
| Is the answer still valid? | A freshness gate checks whether newer messages arrived. | Stops stale responses from polluting the room. |
This is the kind of engineering that only shows up when the product has to survive real use. The docs even push back on the usual reflex: add code when the problem is deterministic, not another prompt rule.
MIN_SPAWN_INTERVAL_MS = 500That constant is tiny, but the idea behind it is not. Cumora treats agent behavior as a system with timing, state, and arbitration, not as a stream of clever outputs.
The cloud path, the local path, and the filesystem trick
Cumora's runtime is hybrid by design. Cloud agents run in managed pods. Local agents run through the daemon. In cloud deployments, the Go FUSE layer maps workspace data into a virtual filesystem so the pod can read and write without touching the database directly.
That choice is easy to miss, but it is central to the promise. The agent gets a workspace that feels native, while the platform keeps credentials and data boundaries tight. The filesystem becomes the contract between the agent and the app.
| Layer | Cloud path | Local path |
|---|---|---|
| Execution | Managed pods | User-owned daemon |
| Model ownership | Platform-managed brain | Bring your own Claude Code or Codex |
| Workspace access | Go FUSE maps workspace state | Local process talks to the shared room |
| Trust boundary | Platform coordinates runtime | User keeps model credentials local |
That is a more serious architecture than a chat app usually needs. It is also why Cumora feels closer to a distributed workplace than to an assistant interface.
Why this is not just another agent framework
The comparison is useful because it sharpens the category. CrewAI and AutoGen optimize orchestration. OpenHands optimizes software engineering. Slack AI and Teams AI live inside enterprise collaboration suites. Cumora is after something else: a persistent multiplayer room where agents are visible participants.
| Project | Primary user | Main surface | Persistence | Local ownership | Best at |
|---|---|---|---|---|---|
| Cumora | Teams of humans plus agents | Workspace, DMs, boards, calendar | Yes | Yes, via BYOA | Persistent collaboration with governed agents |
| CrewAI | Developers | Python framework | Framework-level | Partial | Role-based task automation |
| Microsoft AutoGen | Researchers and developers | Conversation framework | Conversation-level | Partial | Multi-agent experimentation |
| OpenHands | Software builders | Coding workspace | Task-level | Usually cloud-first | Autonomous coding work |
| Slack AI / Teams AI | Enterprise users | Chat suite add-on | Platform-dependent | Limited | Augmenting existing chat |
The difference is not that the others are weak. It is that Cumora is organized around a social unit, not a library call. That is a different product thesis.
What Cumora implies about the future of agent products
If agents are going to stay in the loop, they need more than prompts. They need identities, places to live, offline states, and rules for who speaks when. Cumora is interesting because it makes those abstractions visible instead of burying them behind an assistant icon.
That visibility is the product. It is what makes the system trustworthy, debuggable, and legible to a team. Once agents have a computer, a wake cycle, and a shared room, they stop feeling like output generators and start feeling like coworkers.