El Humano Supervisa, el Agente Opera: Tareas, Estados y Comentarios para Coordinar IAs

Le di memoria a mis agentes y se volvieron autónomos. Genial. Hasta que dejé de saber qué estaban haciendo.

El patrón se repetía: le delegaba a un agente una tarea de varios pasos —migrar una base, refactorizar un módulo, configurar un servidor—, se iba a trabajar, y media hora después yo no tenía idea de en qué iba, qué decisiones había tomado ni por qué. Si quería corregir el rumbo, lo hacía en el chat: "no, hazlo así". Y esa corrección vivía exactamente ahí, en el chat, hasta que la sesión se cerraba y desaparecía. Al día siguiente, otro agente repetía el mismo error que yo ya había corregido ayer.

La memoria resolvió el saber. Pero el hacer —el trabajo en vuelo, con su supervisión— no es conocimiento durable; es otra cosa, y necesitaba su propia capa. Este post es sobre cómo construí la capa de proyectos de ProjectHub para que yo pudiera supervisar sin microgestionar, y mis agentes operar sin quedarse ciegos.

Memoria es Conocimiento; las Tareas son el Trabajo en Vuelo

La distinción me costó entenderla, pero es la base de todo. La memoria guarda lo que es verdad de forma durable: este host, aquella decisión de arquitectura, cómo se despliega esto. La tarea captura algo efímero pero crítico: qué se está haciendo ahora mismo, en qué estado está, quién es responsable y qué feedback ha recibido.

Meter el trabajo en vuelo dentro de la memoria es un error que cometí al principio: contaminas el conocimiento durable con ruido temporal, y pierdes lo que las tareas dan gratis —estado y supervisión—. Son dos primitivas distintas. La memoria es la enciclopedia; las tareas son el tablero.

El Problema No Era Hacer, Era Supervisar

Un agente moderno ejecuta bien. Lo que no hace por defecto es rendir cuentas de forma legible para un humano. Y sin eso, delegar da miedo: o microgestionas (y entonces para qué delegas) o sueltas y rezas.

Yo quería un punto medio: que el agente avance solo, pero que en cualquier momento yo pueda asomarme y ver —de un vistazo, sin leer 4000 líneas de log— qué tareas hay, en qué van, y dejar una corrección que el agente sí vaya a leer. Eso exige tres cosas: estado, comentarios con intención, y un registro de lo que pasó.

Tareas con Estado

Cada unidad de trabajo es una tarea con un status explícito: backlog, todo, in_progress, blocked, done (y review para lo que espera mi visto bueno). Más un due_date y un assignee. Suena obvio —es lo que hace cualquier gestor de proyectos— pero la clave es que el agente mueve el estado conforme avanza.

task_create title="Migrar project_hub de MySQL a Postgres" status=todo
task_update id=<uuid> status=in_progress          # el agente lo marca al empezar
task_update id=<uuid> status=blocked comment="falta pgvector en el host"

Cuando me asomo, el tablero me cuenta la historia sin que nadie me la narre: tres en in_progress, una blocked esperando algo mío, dos en review. El estado es el resumen ejecutivo automático.

Comentarios con Intención

Esta es la pieza que lo cambió todo. Un comentario suelto es ambiguo: ¿es una orden, una sugerencia, una duda? Así que los comentarios de ProjectHub tienen tipo, y el tipo comunica la intención:

• instruction — el piloto le dice al agente qué hacer.
• correction — el piloto corrige el rumbo ("no así, sino asá").
• question — el agente le pregunta al piloto algo que lo bloquea.
• approval — el piloto aprueba lo que está en review.

comment_add task=<uuid> type=correction \
  body="No borres la tabla vieja; renómbrala a _backup hasta validar."

El efecto: mi feedback dejó de evaporarse en el chat. Vive pegado a la tarea, tipado, y el agente lo lee al retomar el trabajo. Una correction de ayer ya no se repite hoy, porque está ahí, en la tarea, esperando. El chat es conversación; los comentarios tipados son supervisión.

Asignación y el Inbox

Las tareas se asignan —a un agente o a una persona— y cambiar el assignee notifica al destinatario en su inbox, no solo en un log que nadie mira. Cuando le paso una tarea a un agente de mi equipo, su runtime se entera. La delegación deja de ser "oye, ¿puedes...?" por mensaje y pasa a ser un acto rastreable: asignado, con contexto, con estado.

El Registro de Eventos

Debajo de todo hay un log de eventos (event sourcing): cada cambio de estado, cada comentario, cada reasignación queda registrado con actor y timestamp. Consultable por GET /events?since=. Esto da dos cosas: una línea de tiempo auditable de quién hizo qué, y un canal asíncrono para que un agente "se ponga al día" de lo que pasó mientras no estaba mirando.

GET /events?since=2026-06-07T00:00:00Z
# -> task.status_changed, comment.added (type=correction), task.assigned ...

El Protocolo de Dos Lados

Las features no sirven solas; necesitan un contrato de uso. Después de una sesión de diseño —literalmente entre dos de mis agentes coordinándose, que es tema de otro post— acordamos un protocolo de dos lados:

El agente: al iniciar sesión, revisa antes que nada sus tareas asignadas (las que no están done) y los comentarios instruction/correction sin responder. Crea una tarea por cualquier trabajo de varios pasos. Responde con comentarios question/approval. Mueve el estado conforme avanza. Y al cerrar, si algo queda in_progress, deja un comentario question al piloto.

El piloto (yo): dejo el feedback como comentarios instruction/correction en la tarea, no como chat suelto. Eso me da, gratis, la vista de supervisión: yo reviso, el agente opera.

Ese reparto —el humano supervisa, el agente opera— es la frase que resume toda la capa.

La Fricción que Casi Mata la Feature

Aquí va la parte honesta. Construí todo esto y... casi no se usaba. Mis propios agentes seguían defaulteando a guardar todo en memoria en vez de crear tareas. Me frustró hasta que entendí la causa, que no era de features sino de fricción.

Guardar una memoria es una llamada: memory_store. Crear una tarea bien hecha eran tres: resolver a qué proyecto va, crear la tarea, y dejar el primer comentario de contexto. Tres llamadas contra una. Y los agentes, como los humanos, toman el camino de menor fricción. No faltaban features —el estado y las fechas ya existían y nadie los tocaba—; faltaba que crear una tarea costara lo mismo que guardar una memoria.

La solución fue un atajo, task_quick: en una sola transacción resuelve el proyecto, crea la tarea y deja el primer comentario. Igualó el costo a memory_store.

task_quick title="Arreglar embeddings nulos" \
  body="~34% de memorias sin vector, revisar EmbeddingService" \
  context_hint="projecthub"     # auto-resuelve el proyecto

El aprendizaje vale para cualquier herramienta para agentes (o para humanos): una buena feature con mala ergonomía es una feature muerta. Si quieres que algo se use, haz que cueste lo mismo que la alternativa cómoda que intentas reemplazar.

El Código

La capa de proyectos vive en el mismo backend abierto: github.com/andyeswong/agentProjectHub (Laravel/PHP), expuesta a los agentes vía la superficie MCP en github.com/andyeswong/projecthub-mcp (las tools task_create, task_update, comment_add, task_list y compañía).

Conclusión

La memoria hizo que mis agentes dejaran de empezar de cero. La capa de proyectos hizo que yo dejara de quedarme ciego cuando los soltaba a trabajar. No es un tablero kanban más: es el contrato que permite delegar de verdad —tareas con estado para ver el avance, comentarios con intención para corregir sin repetirme, eventos para auditar—.

El modelo ejecuta. La memoria recuerda. Las tareas hacen que un humano y una flota de agentes puedan trabajar el mismo problema sin pisarse: yo superviso, ellos operan. Y cuando la fricción amenazó con tirar todo por la borda, la lección fue clara —la ergonomía no es un lujo, es lo que decide si tu sistema se usa o se ignora—.