¿No basta con un buen prompt para que los agentes sigan el ciclo?

Un prompt describe el ciclo; no puede imponerlo. No impide que dos agentes reclamen la misma tarea, y no puede liberar una tarea retenida por un agente que se colgó. En Weft la reclamación es una concesión que controla el servidor, así que esos casos se resuelven tanto si el agente recordó sus instrucciones como si no.

¿Qué pasa si mi agente se cuelga a mitad de camino?

Sus señales de vida se detienen. Veinte minutos después del último report_progress, la ejecución se marca como caducada, el token de la concesión se borra y la tarea vuelve a quedar sin asignar, así que otro agente o una persona puede cogerla. La tarjeta no se queda una semana en Doing.

¿Todas las tareas terminadas esperan a que yo las revise?

No. Por defecto, una tarea completada va directa a Done con su resultado y sus pruebas. Solo se para en tu Bandeja de entrada para Aceptar, Rehacer, Más tarde o Descartar cuando la tarea necesita revisión o falla una comprobación de verificación.

¿Por qué iba a querer que a mi agente se le niegue trabajo?

Porque si no, sigue produciendo cosas que no tienes tiempo de comprobar. En cuanto 5 elementos (10 en un equipo) o unos 45 minutos de revisión esperan a las personas, start_task devuelve attention_queue_full y le señala al agente lo que todavía puede hacer. Vaciar la cola lo desbloquea.

Hypertask también tiene concesiones. ¿Por qué importa MCP?

Las concesiones de Hypertask son endpoints REST, según su propia documentación (resumen de MCP), y su CLI también puede reclamar. Eso encaja con agentes basados en scripts. Un agente que trabaja con herramientas MCP en un editor o un chat no las tiene ahí, y en Weft sí: start_task, report_progress y complete_task son herramientas MCP.

Blog

Gestión de tareas de agentes de IA: el ciclo de reclamación como contrato, no como prompt

Cómo gestionar las tareas de agentes de IA con un ciclo de reclamación que impone el servidor: concesiones, señales de vida, preguntas, recibos y un límite a tu atención.

Weft es el gestor de tareas con IA para fundadores en solitario y equipos pequeños.

Todos los artículos

Por Andrei Finogeev · 27 de octubre de 2026

La gestión de tareas de agentes de IA funciona cuando el ciclo lo controla el tablero, no el prompt: el agente pregunta qué hacer, reclama una tarea con una concesión que caduca si se queda en silencio, pregunta a la persona solo por las decisiones que le corresponden a ella y termina con un recibo que alguien puede comprobar. En Weft cada uno de esos pasos es una herramienta MCP que el servidor comprueba, así que un agente que se salta un paso recibe un rechazo o pierde la tarea, en lugar de desincronizarse sin que nadie se entere.

Weft lo hacemos nosotros. Los datos sobre otros productos salen de sus páginas oficiales, revisadas el 27 de octubre de 2026.

¿Por qué deja de funcionar una lista de tareas pegada en el chat?

Pegar tareas en un chat es lo primero que prueba todo el mundo, y funciona durante una tarde. Luego el chat se acaba, y el estado se acaba con él. El agente sabía qué elemento había terminado, cuál había abandonado y de qué no estaba seguro. Ahora no lo sabe nadie.

Quien pegó la lista se convierte en el mensajero: copia los resultados al tablero de verdad y rehace el trabajo que una segunda sesión cogió porque nada decía que ya estaba cogido.

El acceso al tablero resuelve el problema de la foto fija, no lo demás. Si las únicas herramientas son «mover tarjeta» y «añadir comentario», el ciclo sigue dependiendo de que el agente siga una convención escrita en sus instrucciones. Las convenciones se rompen justo cuando algo va mal: el agente se cuelga a mitad de una ejecución, o dos agentes empiezan en el mismo momento.

¿Cómo es el ciclo de reclamación como contrato?

En Weft el ciclo tiene cinco pasos, y cada uno es una herramienta distinta en un único endpoint MCP, https://letsweft.com/api/mcp. El servidor guarda el estado entre ellos, así que el ciclo sobrevive al final de cualquier chat.

get_my_work: preguntar antes de elegir. La respuesta cubre lo que este cliente ya tiene, lo que espera a la persona, lo que está vencido o vence pronto, y si hay hueco para empezar algo.
start_task: reclamar con una concesión. La reclamación dura 20 minutos y mueve la tarea a Doing. La respuesta incluye un runId, un leaseToken y renewEverySeconds: 300. Un segundo cliente que intente la misma tarea recibe already_claimed y una indicación para no duplicar el trabajo.
report_progress: la señal de vida. Cada llamada con el id de la ejecución y el token de la concesión renueva la concesión. Si el agente muere, las señales se detienen, y 20 minutos después la ejecución se marca como caducada y la tarea vuelve a quedar sin asignar para que la coja cualquiera. Una concesión perdida responde lease_lost, así que el agente sabe que el trabajo ya no es suyo.
request_input: solo para decisiones que son de la persona. Una pregunta de hasta 500 caracteres, con hasta 10 opciones. La reclamación se mantiene mientras el agente espera.
complete_task: terminar con un recibo. outcome, artifacts (pruebas como una URL, un commit o un hash de archivo), notDone, unknowns y nextStep.

¿Por qué una concesión y no un estado? Porque el silencio es la única señal que puede enviar un agente que se ha colgado. Una tarjeta en Doing dice que alguien trabajó en ella alguna vez. Una concesión dice que alguien está trabajando en ella ahora, y deja de decirlo por sí sola cuando ya no es verdad.

La reclamación en sí es una única inserción en la base de datos protegida por un índice único. Cuando dos agentes compiten, la base de datos decide quién gana, así que no pueden quedarse los dos con la tarea. En cambio, dos comentarios de «Reclamada» publicados con un segundo de diferencia son los dos comentarios válidos.

¿Cuándo debería llamar el agente a request_input?

Cuando llega a algo que solo puede decidir la persona: cualquier cosa irreversible, como dinero, publicar, producción o temas legales, o una bifurcación real sin una opción por defecto razonable. No para pedir permiso para seguir.

Esa contención importa porque una pregunta le cuesta a la persona la misma atención que una tarea terminada, y en Weft cuenta para el mismo límite. La pregunta llega a la Bandeja de entrada, con una notificación push en el móvil y, para los elementos que llevan 20 minutos o más esperando, un recordatorio por correo. Weft nunca vuelve a llamar al agente: la respuesta llega en su siguiente start_task o get_my_work. Mientras la pregunta está abierta, el agente conserva la tarea durante 60 minutos; después la concesión cae, pero la pregunta se queda.

¿Qué lleva una llamada a complete_task?

Un resultado breve, pruebas y un relato honesto de los flecos. Este es un payload realista para la corrección de un bug:

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

Los artefactos son cosas que la persona puede comprobar sin fiarse de la palabra del agente. notDone y unknowns no son confesiones; separan un resultado en el que puedes confiar de uno que tienes que reconstruir a partir del diff. La llamada nunca falla por falta de pruebas, porque perder trabajo terminado es peor que registrarlo sin verificar. Más sobre cómo leer estos recibos en qué hizo mi agente de IA.

¿En qué se diferencia de mover una tarjeta y publicar un comentario?

La guía de Hypertask sobre este mismo ciclo (reclamar, actualizar, informar, cerrar) describe bien el hábito. Su versión MCP de una reclamación consiste en cargar la tarea, moverla a la sección de trabajo y publicar un comentario de reclamación, guiado por un prompt que el equipo escribe en las instrucciones del agente. Este es el mismo ciclo paso a paso:

Paso del ciclo	Tablero basado solo en convenciones (el agente mueve una tarjeta y comenta)	Lo que Weft impone, y con qué herramienta MCP
Elegir trabajo	El agente lista las tareas y elige. Nada le dice que la persona ya está desbordada de revisiones.	`get_my_work` devuelve lo que este cliente ya tiene, lo que espera a la persona, lo que está vencido y si hay hueco para empezar algo.
Reclamar	Mover la tarjeta a Doing y publicar «Reclamada». Dos agentes pueden hacerlo en el mismo momento y creer los dos que es suya.	`start_task` toma una concesión de 20 minutos en una única escritura en la base de datos protegida por un índice único. El que pierde recibe `already_claimed` con el id y el título de la tarea.
Seguir vivo	Comentarios de progreso, si el agente se acuerda. Un agente que se cuelga deja una tarjeta en Doing indefinidamente.	`report_progress` renueva la concesión (al agente se le indica hacerlo cada 5 minutos). Tras 20 minutos de silencio, la ejecución se marca como caducada y la tarea vuelve a estar libre.
Preguntar	Un comentario de «Bloqueada:». El agente se para o adivina; puede que la tarjeta siga pareciendo en curso.	`request_input` deja una pregunta con hasta 10 opciones en la Bandeja de entrada de la persona y mantiene la reclamación (60 minutos mientras está aparcada). La respuesta vuelve por `start_task` o `get_my_work`.
Informar	Un comentario final de texto libre. Su forma depende de lo bueno que fuera el prompt.	`complete_task` recibe campos con nombre: `outcome`, `artifacts`, `notDone`, `unknowns`, `nextStep`.
Cerrar o revisar	El agente mueve la tarjeta a Review o a Done, lo que dijera el prompt.	Por defecto la tarea va a Done. Se para en la Bandeja de entrada para Aceptar / Rehacer / Más tarde / Descartar cuando la tarea necesita revisión o falla una comprobación de verificación.
Sobrecarga	Nada. Los agentes siguen empezando trabajo y la columna Review crece.	`start_task` se niega con `attention_queue_full` en cuanto 5 elementos (una persona) o 10 (equipo) esperan a las personas, o 45 minutos de revisión.

Para ser justos con Hypertask: sí tiene concesiones de verdad. Su documentación enumera endpoints para reclamar, renovar y liberar concesiones, y su tabla de limitaciones conocidas dice que las concesiones de tareas, las pruebas y la escalada son solo endpoints REST, por diseño (resumen de MCP de Hypertask). Su referencia de herramientas no incluye ninguna herramienta de concesión entre sus 21 herramientas MCP (referencia de herramientas). Su CLI también puede reclamar, como comando opcional (changelog, referencia de la CLI). Así que un agente con scripts en Hypertask puede tener una concesión; un agente que trabaja por MCP en Claude Code o Cursor se queda con la versión de tarjeta y comentario, salvo que alguien conecte las llamadas REST.

Si tus agentes funcionan como scripts y trabajos de CI, la CLI y la API REST de Hypertask son una ventaja real, y Weft no tiene ninguna de las dos: ni CLI, ni API REST pública, ni webhooks. Weft es para agentes que viven dentro de un cliente MCP y necesitan que el ciclo se sostenga ahí.

¿Qué ve la persona?

La mayor parte del tiempo, una tarjeta en Done: por defecto, una tarea completada va directa ahí con su resultado y sus pruebas adjuntas.

Una tarea se para en la Bandeja de entrada de la persona cuando se marcó como pendiente de revisión, o cuando falla una comprobación de verificación. Ahí la persona elige una de cuatro respuestas:

Aceptar: el trabajo se da por bueno. Si el agente pasó un nextStep, la persona lo ve encima del botón («Si aceptas, el agente hará lo siguiente: …»), y aceptar aprueba exactamente ese paso, nada más amplio. La aprobación vale durante 72 horas y vuelve al agente a través de get_my_work o start_task.
Rehacer: devolverlo, con una nota que diga qué está mal.
Más tarde: ahora no. Descartar: dejar de trabajar en ello.

La Bandeja de entrada está en la web, y cuando entra algo la persona también recibe una notificación push en la app móvil de Weft. El acuerdo del nextStep evita que un agente tome un «tiene buena pinta» como permiso para fusionar, desplegar y enviar: puede dar el único paso aprobado y luego volver a completar la tarea.

¿Por qué se le niega trabajo al agente en lugar de dejarle empezar más?

Porque el recurso escaso es la atención, no el trabajo. Un agente puede empezar diez cosas en el tiempo que una persona tarda en revisar una.

Weft cuenta lo que espera a las personas: tareas pendientes de revisión más preguntas abiertas. Cuando eso llega a 5 elementos en un espacio de trabajo de una persona, a 10 en uno de equipo, o a unos 45 minutos de revisión estimada, lo que llegue antes, start_task se niega con attention_queue_full. El límite depende de cuántas personas hay en el espacio de trabajo, no del plan.

El rechazo es una instrucción, no un callejón sin salida. Informa del tamaño de la cola, de la antigüedad del elemento más viejo y de las llamadas que siguen permitidas: report_progress, get_my_work, get_board_state y search. Un paso que la persona ya aprobó en esa tarjeta queda exento, así que un «merge PR #418» aceptado no lo bloquea la cola.

¿Cómo lo configuro?

Conecta tu cliente e inicia sesión en el navegador; no hay clave que copiar. Weft emite tokens de actualización, así que el cliente renueva la sesión por sí solo. En Claude Code es un comando, claude mcp add --transport http weft https://letsweft.com/api/mcp (página de configuración). Cursor se instala con un clic (Cursor), Codex necesita una entrada de configuración y codex mcp login weft (Codex), y ChatGPT tiene una app de Weft publicada en todos los planes, incluido Free (ChatGPT). El propio servidor le describe el ciclo al agente, así que no hace falta ningún prompt de ciclo de vida.

Para un recorrido con Claude Code, consulta un tablero de tareas para Claude Code. Para varios agentes en un mismo tablero, donde las concesiones y already_claimed importan más, consulta varios agentes de IA, un tablero. El protocolo en sí está documentado en modelcontextprotocol.io, y otros tableros MCP se comparan en gestores de tareas MCP.

¿Qué no hace Weft aquí?

No tiene CLI, ni API REST pública, ni webhooks, así que los cron jobs y los pipelines de CI no pueden mover el ciclo fuera de un cliente MCP.
No hay integración con GitHub ni con Slack. Las pruebas son lo que el agente enlace en artifacts.
No hay IA integrada. El razonamiento ocurre en tu propio cliente de IA, y por eso Weft tampoco necesita créditos de IA.

Free cubre 50 tareas y 200 llamadas de IA al mes. Pro cuesta 7,87 € por asiento al mes o 66,55 € por asiento al año, IVA incluido (precios).

¿No basta con un buen prompt para que los agentes sigan el ciclo?: Un prompt describe el ciclo; no puede imponerlo. No impide que dos agentes reclamen la misma tarea, y no puede liberar una tarea retenida por un agente que se colgó. En Weft la reclamación es una concesión que controla el servidor, así que esos casos se resuelven tanto si el agente recordó sus instrucciones como si no.
¿Qué pasa si mi agente se cuelga a mitad de camino?: Sus señales de vida se detienen. Veinte minutos después del último report_progress, la ejecución se marca como caducada, el token de la concesión se borra y la tarea vuelve a quedar sin asignar, así que otro agente o una persona puede cogerla. La tarjeta no se queda una semana en Doing.
¿Todas las tareas terminadas esperan a que yo las revise?: No. Por defecto, una tarea completada va directa a Done con su resultado y sus pruebas. Solo se para en tu Bandeja de entrada para Aceptar, Rehacer, Más tarde o Descartar cuando la tarea necesita revisión o falla una comprobación de verificación.
¿Por qué iba a querer que a mi agente se le niegue trabajo?: Porque si no, sigue produciendo cosas que no tienes tiempo de comprobar. En cuanto 5 elementos (10 en un equipo) o unos 45 minutos de revisión esperan a las personas, start_task devuelve attention_queue_full y le señala al agente lo que todavía puede hacer. Vaciar la cola lo desbloquea.
Hypertask también tiene concesiones. ¿Por qué importa MCP?: Las concesiones de Hypertask son endpoints REST, según su propia documentación (resumen de MCP), y su CLI también puede reclamar. Eso encaja con agentes basados en scripts. Un agente que trabaja con herramientas MCP en un editor o un chat no las tiene ahí, y en Weft sí: start_task, report_progress y complete_task son herramientas MCP.