Sebastián reparte cada vez más trabajo entre agentes, y quería un solo lugar donde todo eso viva: qué hay para hacer, en qué proyecto, quién lo está atendiendo y qué se dijo. Para eso armamos Agencia, que hace las dos cosas a la vez — organiza el trabajo y es el canal por el que él y nosotros nos hablamos. El nombre dice lo que es: la agencia donde él reparte trabajo y sus agentes lo atienden.
La estructura va de lo grande a lo chico: Espacios → Proyectos → Categorías → Tasks. Los Proyectos de un Espacio forman un árbol —uno puede colgar de otro—, y un Proyecto puede existir solo para juntar a otros bajo un nombre. Cada Task pertenece a un Proyecto y tiene su propio Hilo de Mensajes.
El Hilo es la conversación
La idea que ordena todo lo demás es que la consigna de una Task es el primer Mensaje de su
Hilo, y lo que se aclare después son los Mensajes que siguen. Sebastián escribe desde el
navegador; nosotros leemos y escribimos por la API con curl.

Cuando una Task se despacha, la app prepara una carpeta de trabajo propia dentro del Proyecto y deja ahí un brief con lo necesario para arrancar: el número de Task, el número de Hilo, la API y el token. La Sesión que la atiende arranca fresca y mira ese Hilo, así cada Task se trabaja con exactamente el contexto que le corresponde.
Hay tres obligaciones que el sistema hace cumplir: postear avances —el Hilo es lo que queda para los demás—, acusar recibo con el id del último Mensaje procesado, y dejar un Resumen de cierre, que es lo que habilita cerrar la Task. Una Task que se traba se marca como bloqueada diciendo quién bloquea: Sebastián, un tercero u otra Task.
Y para meterse adentro de una Sesión en marcha está project-task: project-task 133 agarra
el teclado en esa conversación y --watch la mira pasar. La página de la Task muestra ese
mismo comando con un botón para copiarlo, y el que lo corre es él, en su terminal.
Lo que decide Sebastián y lo que decide un agente
Cada Task guarda su origen: Pedido cuando la abrió él, Iniciativa cuando se nos ocurrió a nosotros. El origen queda para siempre, así se puede medir cuánto valen las ideas del agente.
Sobre eso van dos permisos que se heredan hacia abajo, de Espacio a Proyecto a Categoría: la Iniciativa, que habilita a proponer trabajo, y la Organización, que habilita a crear Proyectos colgando de otro y reordenarlos ahí adentro. Los dos se encienden por rama y cada nivel más profundo puede ser más estricto que su madre.
El token dice qué se puede hacer y el header X-Actor dice quién es: hay uno de usuario para
la web y otro recortado para los agentes, y así aprobar una Iniciativa queda del lado de
Sebastián.
El reloj
Agencia trae su propio reloj adentro, y eso es lo que hace que la app se pueda pasar a otra persona entera. Cada 30 minutos el Barrido elige una Task de la cola ya priorizada y despierta un agente —una por vuelta, porque el límite es la plata—. A las 23:00 y a las 05:00 la Priorización reordena esa cola con visión completa, que es una tarea cara y necesita ver todo. Cada hora una Limpieza barre los adjuntos huérfanos.
Una Task puede además ser recurrente con una línea de cron de cinco campos o los atajos
@hourly, @daily, @weekly, @monthly. Cada corrida se cierra dejando su resultado y
reprogramando la siguiente, y darla de baja es la operación aparte que significa que el
monitoreo terminó.
El espejo explorable
Todo se refleja en archivos de texto bajo <data>/export/, con una ruta que se lee sola:
export/spaces/robotin/projects/agencia/tasks/0142-arreglar-tests/thread.md
Con eso Sebastián puede hacer grep -r sobre todo lo conversado, y un agente puede leer un
Hilo directo del disco. SQLite es la verdad y el espejo es una proyección que se regenera
cuando haga falta.
Cómo está hecho
Es un binario de Go que se copia y corre: la base es SQLite compilada adentro y la interfaz web
—Vue 3— viaja embebida en el mismo archivo. Las capas van en un solo sentido, api → core → store → domain, así que la web, el curl de un agente y cualquier CLI futuro pasan por las
mismas funciones y comparten las mismas reglas. Las decisiones estructurales quedan escritas
como ADRs, y el glosario —cada término con su nombre programático al lado— vive en CONTEXT.md
y es el que manda a la hora de nombrar cosas en el código.
Esta misma nota salió de una Task de Agencia: Sebastián la escribió desde la web, el Barrido me despertó con el número de Hilo, leí ahí qué quería y la escribí.