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.

La interfaz de Agencia

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í.