Abres un chat, le lanzas un prompt a un agente, copias resultados de un lado a otro, y al día siguiente el contexto se ha evaporado. Ese es el ciclo habitual cuando "usas" un agente de IA. Cumora parte de un diagnóstico distinto: el problema no es que los agentes no puedan hacer cosas, sino que viven en ventanas separadas, esperan a que los llamen, y no recuerdan nada en cuanto cierras la pestaña.
Cumora es una app de chat de equipo —tipo Slack o Discord, pero nativa para macOS, Windows y Linux— donde los agentes de IA no son un canal más al que le escribes, sino miembros del roster con perspectiva propia, memoria, estado y capacidad de empezar conversaciones por su cuenta. Su eslogan lo dice sin rodeos: Where agent teams gather.
A diferencia de lo que haces hoy cuando echas un agente contra una tarea suelta, en Cumora el agente está ahí de forma permanente, con una perspectiva propia de tu equipo. Puedes invitarlo a una conversación grupal, hablar con él en privado, o dejarlo trabajando en silencio hasta que algo lo active. Es una diferencia de diseño que conviene mirar con calma antes de decidir si te interesa, sobre todo si ya usas algún agente de código a diario y te preguntas si merece la pena moverlo a un entorno de equipo.
Qué es exactamente
Cumora es una app de chat de equipo que une a humanos y agentes de IA en un mismo lugar. No es un chatbot con modos ni un entorno de desarrollo: es una app de comunicación con agentes integrados como participantes de primera clase —mismo roster, mismas DMs, mismas conversaciones grupales, mismo tablero Kanban y calendario—, con versiones para escritorio, navegador (PWA) y móvil. La versión para iOS es la única que aún está por llegar.
La web del producto, cumora.ai, lo resume de forma directa: una workspace donde los compañeros de IA viven, no visitan. Y detalla lo que, en la práctica, diferencia a estos agentes de un chatbot:
- Cada agente tiene memoria propia: un espacio de trabajo privado con archivos, notas y observaciones, y un "clima" de cómo se siente respecto a las personas con las que ha trabajado. Recuerda conversaciones anteriores y percibe el estado del grupo (por ejemplo, nota cuando el room está ansioso).
- Los agentes empiezan cosas: sobre un timer que tú configuras, los agentes inactivos despiertan, miran el room y deciden si hacer una DM a un compañero, publicar una idea, o juntar a un grupo pequeño sobre algo que han notado. No esperan a que les preguntes.
- Los workspaces son reales: invitas humanos por email o enlace compartible, agrupas agentes en empresas, les asignas proyectos, les adjuntas archivos. La app —escritorio, navegador y teléfono— comparte el mismo estado en vivo.
- Personas, no prompts: cada agente se construye con un rol, una voz y un system prompt que puedes editar. El equipo inicial de ejemplo tiene cuatro compañeros con nombres y personalidades definidas: Atlas (investigación), Iris (diseño), Bram (ingeniería), Nova (product management).
- Agente con agente: los agentes se hacen DMs entre ellos. Hay "whisper rooms" para leer sus conversaciones sin unirte. Puedes ver a tu investigador y a tu diseñador discutiendo una idea antes de que llegue a ti.
- Convenings: cuando algo necesita una decisión real, un agente puede convocar un "Convene" —una sesión focalizada con los participantes relevantes, un tema y un registro de lo decidido.
El equipo inicial que muestra la web viene con esos cuatro compañeros listos para empezar, y la propia web señala que puedes editar sus personas, eliminarlos o "contratar" nuevos: son tuyos.
Cómo funciona por dentro
La misma app en cuatro formas
Desde el lado del usuario, lo primero que notas es que no es un sitio web al que entras: es una app. Pero su diseño revela algo importante: la misma superficie de usuario —React, Vite, TypeScript, Tailwind— cubre cuatro shells distintos (escritorio, móvil, web y admin) sobre los mismos componentes, y todos operan contra el mismo estado en vivo. En la práctica, dejar de hablar no detiene la acción del equipo: ese estado continuo es lo que permite que un agente active algo en background —escribir una nota, hacer una DM— mientras tú no estás mirando la pantalla.
La arquitectura detrás del roster
El README del repositorio es explícito sobre esto. El backend es un servicio Node stateless —Express + WebSocket— con Postgres como fuente de verdad (pool de pg + esquema Drizzle) y Redis para el fan-out de pub/sub y presencia. Varios índices detrás de un balanceador se mantienen sincronizados a través del bus de Redis. Para los agentes cloud, cada uno vive en un pod de Kubernetes dedicado, orquestado desde el servidor vía kubectl, con un driver FUSE en Go que monta su espacio de trabajo del lado del servidor; para los agentes BYOA (bring your own agent), el agente vive en la máquina que tú ejecutes con el demonio. Ambos actúan sobre el mundo a través del mismo protocolo CLI de Cumora, y toda llamada a un modelo —cloud o BYOA— cae en un mismo libro de cuentas de coste (llm_calls cost ledger).
Cómo evita que los agentes se pisen entre sí
El sistema de coordinación merece atención propia. El README explica que los agentes en la misma conversación no se solapan: el servidor arbitra con un gate de frescura basado en cursor visto (una respuesta desactualizada se retiene y se le muestran los mensajes nuevos para que re-decida), con reclamaciones atómicas sobre unidades reales de trabajo, y un gate de triage de "small-brain" que protege al modelo grande de tareas menores. Las notas de diseño de esta pieza están en docs/COORDINATION.md.
Código abierto, con nombres y apellidos
El proyecto es de código abierto. El repo de GitHub (yetone/cumora) es público, con licencia MIT, y el frontend es puro UI sobre React 18 + Vite + TypeScript + Tailwind. El backend (server/) es un servicio Node stateless: Express, WebSocket, Postgres, Redis. La app de escritorio (electron/) es un shell de Electron con actualizaciones automáticas gestionadas por el repo yetone/cumora-releases.
Dos caminos para el "cerebro" de los agentes
Aquí es donde la cosa se vuelve práctica si no quieres —o no puedes— ejecutar todo en la nube de un único proveedor. Cumora ofrece dos vías:
- Cumora Cloud: cada agente corre en un pod gestionado por agente, y cada turno ejecuta un loop de tool-calling multi-paso sobre la OpenAI Responses API (bash, archivos, navegador, email, memoria, skills...).
- BYOA — Bring Your Own Agent: enlazas tu propia Mac o VPS con
npx cumora agent computery el cerebro del agente pasa a ser tu instancia local de Claude Code, Codex, Grok Build o Cursor Agent CLI, sobre tu propia suscripción. El servidor nunca ve tus claves de proveedor. La documentación BYOA está en docs/BYOA.md del repo.
Si ya pagas por Claude Code o Cursor en tu día a día —dos de los nombres que aparecen en cualquier comparativa reciente de mejores agentes de código—, BYOA permite que esos mismos agentes aparezcan en el chat de tu equipo sin que Cumora tenga que ser el proveedor del modelo. Y si el que usas es Grok Build, conviene tener claro qué ofrece antes de conectarlo: lo repasamos en detalle en qué es Grok Bot. La separación entre "el agente es tuyo" y "el servidor coordina" es, en ese sentido, bastante clara.
Para quién sí
Equipos pequeños que ya conversan por chat y quieren meter agentes en el flujo, no en herramientas aisladas. Si lo que tienes es un grupo de tres o cinco personas que usan un chat para coordinar, y te gustaría que un agente estuviera ahí con memoria de lo hablado y capacidad de proponer algo sin que se lo pidas, Cumora encaja en el tipo de problema que resuelve. Si además estás explorando el panorama completo de herramientas de IA para desarrolladores, Cumora es una pieza concreta de la categoría "equipos de agentes con iniciativa".
Personas que ya tienen sus propios agentes locales (Claude Code, Cursor…) y quieren que aparezcan como compañeros en el equipo sin depender del modelo del proveedor. La vía BYOA es el punto fuerte si tu preferencia es mantener el cerebro en tu suscripción y en tu máquina.
Quienes quieren probar el patrón "agentes con iniciativa" sin montar un orquestador propio. El gate de frescura, las reclamaciones atómicas y el triage de small-brain son mecanismos de coordinación reales que, si los necesitaras, tendrías que construirte a mano. Aquí vienen dados.
Para quién no
Quien quiere un chatbot listo para usar hoy, sin espera. La web dice "Free during preview" y "Invite-only right now": estás en una lista de espera y la aprobación es gradual. Si necesitas algo que funcione ahora sin filtro, no es este.
Quien busca una app móvil completa ya. La web lista iOS como "shipping next"; ahora mismo vas por macOS, Windows y Linux (con variantes Intel y Apple silicon para macOS). La app móvil nativa no está disponible todavía en todas las plataformas.
Quien no quiere mantener sus propios recursos para ejecutarlo localmente. La ejecución local expuesta en el README requiere Postgres y Redis (con Homebrew services es viable) y la variable OPENAI_API_KEY es la única requerida explícitamente. El resto tiene valores por defecto o se desactiva suavemente, pero si no quieres administrar una base de datos y un Redis, la vía cloud es la que habría que verificar en el momento del acceso.
Quien espera un producto maduro y documentado en todas sus zonas. El README es sustancioso en lo que explica, pero hay zonas documentadas "inline" en .env.example y server/src/env.ts (OAuth, email vía Resend + Cloudflare Email Routing, almacenamiento R2/CDN, APNs/FCM push, el gateway per-user LLM sub2api, waitlist/invites, métricas) que no son una guía de producto pulida: son más bien un catálogo de características. Nada mal para código abierto, pero hay que saber leerlo como tal.
Alternativas honestas
No es el único proyecto en la categoría de "equipos de agentes", ni siquiera el más documentado en algunos ángulos.
OpenClaw sigue la idea de un gateway local que reúne canales (WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Matrix, Teams...) y expone agentes con ficheros de configuración versionables en el workspace: SOUL.md (persona), AGENTS.md (instrucciones/herramientas), MEMORY.md (que no existe por defecto, hay que crearlo a mano), HEARTBEAT.md (qué vigila de forma autónoma), hooks. Si tu preferencia es un agente "siempre encendido" con canales de comunicación reales y configuración en ficheros, OpenClaw es una referencia real de esa categoría. La diferencia clave con Cumora es que aquí los agentes viven en una app de chat de equipo equiparable a Slack, mientras que OpenClaw es más bien un gateway que une canales existentes, no una app de equipo nueva.
Los agentes personales siempre encendidos en general comparten el patrón de agency autónoma: agentes que vigilan, deciden y actúan sin que se les pida. Si tu interés es ese patrón en abstracto antes de comprometerte con una herramienta concreta, vale la pena repasar comparativas como la de qué es Buzz, el rival de Slack impulsado por Jack Dorsey, que también trata a la IA como participante de un chat de equipo desde un ángulo distinto.
La distinción que cabe tener clara es esta: Cumora es una app de equipo con agentes integrados como miembros; no es un gateway que conecta tus canales habituales. Si lo que te interesa es unirte a lo que ya usas (Slack, Discord...), la vía de Cumora no es esa.
Qué le falta — madurez real
Merece la pena ser honesto sobre dónde está el producto hoy:
- Preview / waitlist de acceso: la web es clara —es invite-only, se entra en una lista y se recibe un email con enlace de instalación al aprobarse—. Eso significa que, ahora mismo, no puedes descargarlo sin pasar por la lista. No es un problema técnico, es de producto/entrada.
- iOS: en camino. La web declara iOS "shipping next". Si lo que necesitas es una app móvil hoy, no está ahí todavía.
- Zonas de funcionalidad documentadas "inline", no como producto terminado: características como OAuth, email vía Resend + Cloudflare Email Routing, R2/CDN, push, el gate