Qué es Thulu

Thulu es un tablero de tareas con agentes. Cada tarea avanza por columnas (etapas), y cuando entra a una columna para la que tiene un agente asignado, Thulu arranca una corrida: el agente trabaja la tarea en su propio contenedor, sobre la rama task-<id> de cada repo de la tarea, y al final la rama se publica en GitHub y Thulu puede abrir un pull request por repo. Corre en tus servidores y habla con el modelo con tu propia key: cada workspace carga la suya (con Claude Code: Anthropic, Amazon Bedrock o Google Vertex) y el costo del modelo lo pagás aparte a tu proveedor.

Se instala en tu servidor con Docker Compose o Kubernetes. También existe una versión SaaS en octopus.misterd.dev, en beta cerrada por invitación. El modelo es el mismo en los dos casos.

Cómo encaja todo

Todo vive dentro de un workspace. Nada se comparte entre workspaces: un agente, una credencial o un tablero de uno no aparece en otro.

Workspace (miembros con rol: lector, desarrollador, administrador, dueño)
├── Motores de IA ......... clave del modelo, por perfil
├── Credenciales .......... GitHub, AWS, GCP, Figma y MCP externos
├── Proyectos ............. un repo de GitHub o una carpeta subida
│   ├── Plantilla de etapas   agente por defecto de cada columna de agente
│   ├── Script de arranque    cómo levantar la app en un sandbox
│   └── Entornos              dev, staging, prod (para Evidencia y métricas)
├── Tableros
│   └── Etapas (columnas) ... agente por defecto, avanzar, pushear, abrir PR, aprobaciones
│       └── Tareas .......... repos, agente por etapa, subtareas, hilos, casos TC-n
│           └── Corridas      una por cada vez que trabaja un agente
├── Agentes ............... etapas válidas, y por etapa: turnos, skills, MCP, prompt, auditor
├── Skills ................ instrucciones en markdown que se conceden por agente y etapa
├── MCPs .................. servidores de herramientas que el agente puede llamar
└── Evidencia ............. biblioteca de casos EV-n que corren solos por entorno

Qué pasa cuando una tarea entra a una columna

Movés la tarjeta (o la tarea avanza sola desde la columna anterior). Si la columna pide aprobación al entrar, la tarea espera ahí y la aprobación aparece en “Pendientes”.
Thulu busca el agente que la tarea tiene asignado para esa columna. Ese agente se copió de la “Plantilla de etapas” del proyecto cuando se creó la tarea, o lo eligió alguien en la propiedad “Agente”. Si no hay ninguno, la tarea queda quieta y la tarjeta lo dice (“Sin agente” o “No arrancó”, con el motivo). Las columnas de inicio y de fin nunca corren agentes.
Arranca la corrida (o espera en cola si no hay lugar): un contenedor nuevo con el agente, la rama task-<id> de cada repo, la descripción de la tarea y, para esa etapa, el prompt, las skills y los MCP que el agente tiene concedidos. Corre con la clave del perfil del agente o, si no eligió uno, con el perfil predeterminado del motor.

Una corrida en curso vista desde la tarea: estado, cuánto lleva, la última acción y las acciones para seguirla o frenarla.
Mientras trabaja, el agente puede hacer preguntas (llegan a “Pendientes”), pedir más turnos, levantar un sandbox para probar la app o filmar casos de prueba con el navegador, según los MCP que tenga.
Si el agente tiene auditor en esa etapa, otro contenedor revisa el trabajo al terminar y decide si sigue, si la tarea vuelve, si se frena o si al agente le faltan turnos. El auditor se prende por agente y etapa, puede correr en otro motor que el del agente, y un workspace nuevo no trae ninguno prendido.
Se commitea lo que quedó en la rama. En Docker lo hace Thulu, porque el agente ve el .git de sólo lectura; en Kubernetes el agente commitea y rebasea con git en su propia copia. Si la columna tiene “Pushear la rama”, Thulu la publica en GitHub con el token del proyecto, que nunca entra al contenedor del agente. Si tiene “Avanzar cuando el agente termina”, pasa la tarea a la columna siguiente. La columna con “Abrir un pull request” abre el PR de cada repo que todavía no lo tiene. El merge lo decide el equipo: por default ningún agente mergea.

Una tarea tiene, como mucho, un agente por columna. Otros agentes entran a la tarea cuando alguien los menciona con @ en un hilo de la tarea, o desde el chat lateral.

Quién decide qué

Pregunta	Dónde se define
Qué agente trabaja en una columna	La propiedad “Agente” de la tarea, que al crearla copia la “Plantilla de etapas” del proyecto. La plantilla se carga en el proyecto o desde “Agente por defecto” en el Comportamiento de la columna, y el agente tiene que tener esa columna en “Etapas válidas”.
Con qué modelo y qué clave	El perfil del agente, o el perfil predeterminado del motor en Configuración, “Motores de IA”.
En qué repo trabaja	Los proyectos vinculados a la tarea. Sin proyecto no hay rama ni PR.
Qué herramientas puede usar	Los MCP tildados en la pestaña “MCP” del agente, para esa etapa. Las tools de merge (`pr_merge`) y deploy no las concede ningún scope: un admin las nombra una por una.
Qué sabe y cómo trabaja	El prompt de la etapa y las skills concedidas para esa etapa, más las skills del sistema que traen sus MCP.
Cuántos turnos tiene	“Etapas válidas” del agente: 20 por defecto, 30 por mensaje en el chat.
Cuándo para y pide permiso	Las aprobaciones de la columna y las preguntas del agente. Las dos llegan a “Pendientes”.
Qué pasa después	Los switches de la columna: avanzar, pushear, abrir PR.

Pestaña Configuración de un agente con el perfil del motor, la entrega de skills y las etapas válidas En curso, Mención y Chat — Un agente con tres etapas válidas: la columna "En curso" y los modos "Mención" y "Chat".

Glosario

Término	Qué es	Dónde se configura
Workspace	El espacio de un equipo, con sus miembros, tableros, proyectos, agentes, skills y claves. En una instalación propia no hay límite de workspaces; en SaaS una cuenta puede ser dueña de hasta 2.	Menú de workspaces, arriba de la barra lateral. Workspaces y equipo
Proyecto	Un repo de GitHub clonado en Thulu, o una carpeta subida que Thulu aloja como repo, con su descripción (que va al prompt de los agentes), su plantilla de etapas, su script de arranque y sus entornos.	“Proyectos”. Proyectos
Tablero	Un conjunto de columnas por donde pasan las tareas. Un workspace nuevo trae uno con tres columnas.	“Editar tablero”. Tableros y etapas
Etapa	Una columna del tablero, con switches que dicen qué pasa al entrar y al salir. En el agente, “Mención” y “Chat” también cuentan como etapas.	“Comportamiento” de la columna. Tableros y etapas
Tarea	La unidad de trabajo: título, descripción en markdown, repos, agente por etapa, subtareas (un nivel, misma rama y PR) y dependencias.	“Nuevo” > “Tarea”. Tareas
Agente	Una definición del workspace: qué etapas puede trabajar, con qué modelo, con cuántos turnos, con qué prompt, skills y MCP en cada una.	“Agentes”. Agentes
Skill	Instrucciones en markdown que el agente lee cuando le sirven. Las del workspace se conceden por etapa; las del sistema (`octopus-*`) llegan con sus MCP.	“Skills”. Skills
MCP	Un servidor de herramientas: `octopus-api` (leer y escribir en Thulu), `argus-github`, `argus-browser`, `argus-sandbox`, `argus-cloud`, `argus-figma` (apagado por defecto), o uno propio. Todos menos `argus-sandbox` y el navegador por corrida pasan por el daemon, así el agente no ve sus URLs ni credenciales.	Pestaña “MCP” del agente. MCPs
Corrida	Una sesión de un agente sobre una tarea. Estados: corriendo, en cola, espera una respuesta, espera una aprobación, sin turnos, falló, frenada por el auditor, no arrancó.	Se ve en la tarea. Corridas de agentes
Auditor	Una segunda pasada, en otro contenedor, que revisa lo que hizo el agente en una etapa (5 turnos por defecto).	“Auditor por etapa” del agente. Agentes
Sandbox	Un contenedor aparte por tarea donde el agente corre la app, ejecuta comandos y comparte una URL de vista previa.	MCP `argus-sandbox` en la etapa y script de arranque del proyecto. Sandbox
Evidencia	La biblioteca de casos EV-n de aplicaciones web: un agente los graba una vez con el navegador y después Thulu los reproduce sin modelo en cada entorno, a mano, por horario, después de cada deploy o desde el CI.	“Evidencia”. Evidencia
Caso de prueba	Un caso TC-n dentro de una tarea, que un agente corre con el navegador y filma antes y después.	Bloque “Casos de prueba” de la tarea. Casos de prueba y videos
Pendientes	La bandeja con las preguntas de los agentes y las aprobaciones que esperan a una persona.	“Pendientes”. Pendientes
Hilo y mención	Un comentario en la actividad de la tarea; escribir `@agente` despierta a ese agente en el hilo.	Pestaña “Tarea”, actividad. Conversación e hilos
Motor de IA y perfil	El motor (Claude Code, Codex u OpenCode) y la clave con la que corre. El perfil predeterminado es el que usan los agentes que no eligen uno.	Configuración, “Motores de IA”. Credenciales y motores
Credencial	Un token de GitHub, AWS, GCP o Figma, o la credencial de un MCP externo, que usan los MCP y los proyectos.	Configuración, “Credenciales”. Credenciales y motores
Automatización	Una receta en YAML que se dispara por horario, evento, métrica o a mano y crea tareas, menciona agentes o llama APIs.	“Automatizaciones”. Automatizaciones
Workshop	Un catálogo chico de agentes y skills de ejemplo que se instalan con un plan previo, y la importación y exportación de agentes y skills en JSON entre workspaces.	“Workshop”. Workshop
Workspace operador	El workspace de quien opera la instalación. Sus admins ven Infraestructura, la lista de acceso a la beta y los MCP propios, y sólo su owner puede cargar un token de suscripción de Claude.	Variable `OCTOPUS_OPERATOR_WORKSPACE`. Configuración

Un workspace recién creado

Un workspace nuevo trae el tablero “Principal” con tres columnas (Backlog, En curso y Hecho, en el idioma de la interfaz mientras nadie las renombre), ningún agente y ninguna columna con agente por defecto. Podés crear tareas y moverlas, pero nadie las trabaja. El botón “Configuración inicial”, arriba a la derecha, lista lo que falta para que un agente trabaje: la clave del modelo, la credencial de git, el primer proyecto, un agente, una columna con agente por defecto y la plantilla de cada proyecto.

Página Configuración inicial con la lista de ítems, cada uno con su estado y un link a donde se completa — El checklist de Configuración inicial, en el orden en que conviene completarlo.

Para que un agente trabaje la primera tarea hacen falta cuatro piezas: la clave en “Motores de IA”, un proyecto con su repo, un agente con la columna en “Etapas válidas” y ese agente elegido para la columna, en “Agente por defecto” o en la “Plantilla de etapas” del proyecto. Si ya tenés un proyecto, al crear el agente Thulu ofrece ponerlo a trabajar en una columna del tablero por defecto. El recorrido completo, con cada pantalla, está en Flujos recomendados.

Relacionado

Flujos recomendadosSeis recorridos punta a punta con tiempo y esfuerzo.

Empezar en la versión SaaSEntrar a la beta cerrada con una invitación.

Instalación self-hostedInstalar Thulu en tu servidor.

Tableros y etapasQué hace cada opción de una columna.