Abres una terminal para Claude Code. Otra para Codex. Una tercera para Cursor. Cada una con su contexto, su historial y su tarea a medias. A los veinte minutos ya no recuerdas cuál estaba arreglando el bug del login y cuál migrando la base de datos, y el tiempo que ganas por tener tres agentes trabajando lo pierdes saltando entre ventanas.
Ese es exactamente el problema que Multica dice resolver. Y conviene entenderlo bien, porque en cuanto pasas de un agente a varios, el cuello de botella deja de ser la inteligencia del modelo y pasas a serlo tú.
Este análisis sale de fuentes primarias: el repositorio oficial, la API de GitHub, la web del producto y su archivo de licencia. Las cifras son del 14 de agosto de 2026.
Qué es Multica, en una frase
Multica es una plataforma open source que convierte agentes de programación en compañeros de equipo: les asignas incidencias como se las asignarías a una persona, y trabajan en un tablero compartido con humanos.
Su propia descripción en GitHub lo dice sin rodeos: «Assign issues to Claude Code, Codex, Cursor, and 17 more coding agents like teammates». Veinte agentes en total, todos ejecutándose donde ya los tienes instalados.
No es un modelo. No es un agente. Es la capa de coordinación que va por encima de los agentes que ya usas.
El problema real: el contexto que se pierde entre terminales
Cada CLI de agente vive en su propia sesión. Cuando cierras la terminal, se va el contexto. Cuando abres tres, el que coordina eres tú: recordar quién hace qué, revisar cada salida, decidir qué se integra.
Multica sustituye ese trabajo de memoria por un sistema de registro único. Todas las tareas, de humanos y de agentes, en el mismo tablero. Todas las ejecuciones registradas. Todo el trabajo pasa por revisión antes de integrarse.
La frase que mejor resume su postura es de su propia documentación: «Work lands in review, not in main. You decide what ships». El agente propone; la persona decide.
Cómo funciona: el ciclo de vida de una tarea
El flujo es deliberadamente parecido al de un gestor de proyectos clásico, y esa es la idea:
- Enqueue. Creas una incidencia y se la asignas a un agente.
- Claim. El agente la reclama. Deja de estar disponible para otros.
- Start. El demonio local ejecuta el CLI correspondiente en tu máquina, junto a tu código.
- Complete o fail. El agente abre un pull request con el trabajo, o reporta el bloqueo y por qué.
Durante todo el proceso el agente comenta en la incidencia igual que lo haría un compañero: actualiza el estado, avisa de bloqueos, deja registro. Los registros de ejecución guardan cada llamada a herramienta, cada comando y cada error con su marca de tiempo.
La pieza que hace esto posible es un demonio local: un proceso que corre en tu máquina, detecta qué CLIs de agente tienes instalados y ejecuta las tareas ahí, hablando con el servidor por WebSocket. Tu código no sale de tu equipo.
Skills y Squads: las dos ideas propias
Casi todo lo anterior es gestión de proyectos aplicada a agentes. Estas dos ideas son lo que Multica aporta de suyo.
Skills
Una skill es un problema resuelto convertido en manual reutilizable. Resuelves una migración complicada una vez, la empaquetas, y a partir de ahí cualquier agente del equipo la reutiliza.
Es la diferencia entre un equipo que aprende y uno que repite los mismos errores. Para una empresa de cero empleados, es probablemente la función más interesante: cada problema que resuelves se convierte en capacidad permanente en lugar de evaporarse al cerrar la terminal.
Squads
Un squad es un grupo de agentes y personas con un líder que reparte el trabajo. En vez de asignar tarea por tarea, delegas en el grupo y el líder enruta.
Es el mecanismo para que el modelo aguante cuando crecen los agentes: sin él, el humano vuelve a ser el cuello de botella que se quería eliminar.
La arquitectura, sin misterio
| Pieza | Tecnología |
|---|---|
| Interfaz web | Next.js 16 |
| Servidor | Go 1.26 con router Chi y WebSocket |
| Base de datos | PostgreSQL 17 con pgvector |
| Ejecución local | Demonio propio que lanza los CLIs de agente |
| Escritorio | Electron (macOS, Windows, Linux) |
| Móvil | React Native / Expo (iOS) |
Se puede usar de tres formas: la nube en multica.ai, las aplicaciones de escritorio, o autoalojado con Docker Compose o Helm. El control de acceso tiene tres roles —owner, admin y member— con ámbitos que definen qué agentes puede ejecutar cada persona.
Estado del proyecto: joven, y en movimiento
| Métrica | Valor |
|---|---|
| Estrellas | 45.924 |
| Forks | 5.837 |
| Incidencias abiertas | 1.337 |
| Watchers | 164 |
| Creación del repositorio | 13 ene 2026 |
| Última versión | v0.4.25 |
| Agentes compatibles | 20 |
Datos de la API de GitHub el 14 de agosto de 2026. Son una captura puntual y cambian a diario.
Una tabla es una foto fija. Para ver el pulso del proyecto hace falta mirarlo en el tiempo:
Actividad semanal desde el despegue
Dos señales distintas: lo que escribe el equipo (commits) y lo que reclama la comunidad (incidencias abiertas). Semana a semana, del 29 de marzo al 9 de agosto de 2026.
stats/participation y búsqueda de incidencias). La última semana está incompleta. No es volumen de búsquedas: Google Trends no publica datos de un término tan nuevo, así que se mide la actividad observable del proyecto.La curva cuenta tres cosas que la tabla no puede.
El pico de ambas series cae en la semana del 12 de abril: 308 commits y 181 incidencias abiertas a la vez. Ese es el momento en que el proyecto se hace visible y la comunidad entra en masa.
Después, los commits bajan de 300 a una banda estable de 90–170 por semana. No es abandono: es el paso de la sacudida inicial a un ritmo sostenido, con releases casi diarios.
Y lo más revelador: las incidencias no bajan con los commits. Se mantienen entre 75 y 135 semanales durante cuatro meses. Traducido: hay gente usándolo de verdad y encontrando cosas, no solo mirando el repositorio. Es la diferencia entre una estrella y un despliegue.
Tres lecturas de esta tabla, y las tres importan.
Primera: es un proyecto de siete meses. El repositorio se creó el 13 de enero de 2026. Casi 46.000 estrellas en ese tiempo es una tracción notable, pero una estrella no es un despliegue en producción.
Segunda: la versión es v0.4.25. No ha llegado a la 1.0. En el mundo del software eso significa que la API puede cambiar sin previo aviso y que la compatibilidad hacia atrás no está garantizada. Publican versiones casi a diario: la anterior era del día previo.
Tercera: 1.337 incidencias abiertas. En un proyecto joven y muy usado esto es normal, pero conviene leerlo junto a lo anterior: hay mucha superficie funcional moviéndose deprisa.
La letra pequeña: «open source», pero con condiciones
Aquí está el hallazgo que no aparece en los titulares y que sí debería pesar en tu decisión.
La web de Multica se presenta como «an open-source platform». El archivo de licencia cuenta algo más matizado: es la Apache 2.0 con condiciones adicionales añadidas por delante. No es Apache 2.0 a secas.
Las dos restricciones relevantes:
- No puedes usar el código para ofrecer un servicio alojado a terceros —SaaS, servicio gestionado o componente de una oferta comercial— sin una licencia comercial. El uso interno dentro de tu organización sí está permitido.
- No puedes quitar ni modificar el logotipo, el nombre del producto ni los avisos de copyright si usas la interfaz derivada del código original, salvo renuncia escrita.
El detalle revelador: GitHub no consigue clasificar esa licencia. La API devuelve NOASSERTION y la etiqueta como «Other», precisamente porque las condiciones añadidas la sacan de las licencias estándar.
Que quede claro lo que esto no significa: no es una trampa ni descalifica el proyecto. Es un modelo cada vez más común, y para el uso que hará la inmensa mayoría —montarlo en tu propia empresa— no cambia absolutamente nada. Puedes inspeccionar el código, modificarlo, autoalojarlo y mantener un fork.
Pero si tu plan era construir un producto encima y vendérselo a terceros, tienes que hablar con ellos primero. Y si comparas licencias entre herramientas, conviene saber que esta no es equivalente a una MIT o una Apache limpias.
Multica frente a Paperclip
Es la comparación inevitable, porque en nuestro análisis de Paperclip ya aparecía Multica como su competidor funcional más directo. Con las dos sobre la mesa, la diferencia es de metáfora, y la metáfora determina para quién sirve cada una.
| Paperclip | Multica | |
|---|---|---|
| Metáfora | La empresa autónoma | El equipo mixto |
| Unidad básica | El organigrama | El tablero de tareas |
| Énfasis | Misión, presupuestos, gobierno | Tareas, skills, revisión |
| El humano | Gobierna desde arriba | Trabaja en el mismo tablero |
| Licencia | MIT | Apache 2.0 con condiciones |
Paperclip modela una compañía de agentes con jerarquía y presupuesto. Multica modela un equipo donde personas y agentes comparten el mismo tablero y las mismas reglas.
Ninguna es mejor en abstracto. La pregunta correcta es qué eres tú: si diriges una operación donde los agentes ejecutan y tú gobiernas, la metáfora de la empresa encaja. Si sigues trabajando mano a mano con ellos y quieres verlo todo en un sitio, encaja la del equipo.
Cuándo tiene sentido y cuándo no
Aquí conviene ser concreto, porque la respuesta honesta es «depende de cuántos agentes uses».
Tiene sentido si ejecutas dos o más CLIs de agente a la vez, si quieres convertir soluciones en skills reutilizables, si necesitas que quede rastro de qué hizo cada agente y por qué, o si trabajas con más personas y queréis un tablero común.
No lo tiene si usas un solo agente —la terminal te sobra y montar una plataforma es coste sin beneficio—, si necesitas gobernanza empresarial con campos personalizados, roles granulares y auditoría formal, o si tu operación no tolera una API que aún puede cambiar.
Sobre el coste: la plataforma no cobra por asiento. El gasto variable sigue siendo lo que pagues por inferencia a los CLIs que hay debajo, más la infraestructura si te lo autoalojas. Multica no reduce tu factura de tokens; organiza lo que haces con ellos.
Una advertencia que merece estar aquí y no en la letra pequeña: al ser un proyecto en 0.x, un análisis independiente de versiones anteriores documentaba fallos de seguridad y condiciones de carrera ya corregidos, pero el patrón es el esperable en software que se mueve tan rápido. Si lo pones en una operación crítica, actualiza a menudo y sigue su repositorio.
Lo que esto significa para una empresa de cero empleados
Si operas solo con agentes, tu límite real no es cuántos puedes pagar. Es cuántos puedes supervisar.
Un agente cabe en tu cabeza. Tres ya no. Y cuando dejas de saber qué está haciendo cada uno, la ganancia de productividad se convierte en riesgo: código que se integra sin revisar, trabajo duplicado, decisiones tomadas sin que te enteres.
Multica ataca precisamente ese límite, y lo hace con la herramienta menos glamurosa que existe: un tablero de tareas con revisión obligatoria. No es la parte emocionante del asunto. Es la que decide si tu operación escala o se te va de las manos.
Hay un riesgo simétrico, y conviene nombrarlo: convertir la automatización en burocracia. Si cada paso interno se materializa en proceso, tablero y revisión, el coste de supervisar puede acabar superando lo que ahorras. La capa de gestión tiene que pesar menos que el trabajo que gestiona.
Metodología: repositorio oficial multica-ai/multica, API de GitHub, archivo LICENSE, web oficial multica.ai y una guía técnica independiente. Cifras del 14 de agosto de 2026; son capturas puntuales y no equivalen a usuarios activos ni a despliegues en producción. Las descripciones de funciones proceden de la documentación del propio proyecto y no se han auditado de forma independiente.
¿Quieres montar una operación con agentes sin perder el control de lo que hacen? En ceroempleados.com encontrarás los recursos, casos reales y metodología para hacerlo.
