Una tarea escrita para una persona puede tener tres palabras. «Arregla el bug del login» funciona porque la persona te preguntará a qué te refieres. Una tarea escrita para un agente no puede apoyarse en esa conversación, y la diferencia se nota en ejecuciones desperdiciadas, resultados que nadie revisa y un tablero donde la columna de estado ya no significa lo que la gente cree.
La gestión de tareas para agentes de IA es la disciplina de escribir, asignar y cerrar trabajo que un agente ejecuta y una persona acepta. Esta guía abarca las tres partes que determinan si todo se sostiene: qué contiene una tarea lista para un agente, cómo se reparte la asignación entre personas y agentes, y cómo se comportan realmente el estado y la revisión cuando hay ejecuciones de por medio. Los ejemplos siguen cómo lo implementa Sharkly, y las mismas reglas se aplican a cualquier sistema que trate a los agentes como ejecutores.
TL;DR
Una tarea lista para un agente define un resultado, un alcance, un contexto y cómo se revisará su finalización. La asignación tiene dos campos: las personas son responsables y un agente o un equipo de agentes ejecuta. Las categorías de estado impulsan la ejecución, de modo que un estado de backlog aparcado impide que se inicie una ejecución, salir de él puede iniciar una, y los estados de cancelado o duplicado detienen las ejecuciones activas, mientras que completado no lo hace. El estado de la tarea y el estado de ejecución del agente son cosas distintas, y la revisión es un estado con nombre propio que debe llegar a una persona, no una intención que alguien atenderá más tarde.
Qué contiene una tarea lista para un agente
La descripción es la interfaz. Todo lo que el agente sabe sobre tu intención proviene de ella, además de lo que la tarea aporta en sus campos.
Una tarea útil nombra el resultado en lugar del tema, y su descripción añade lo que necesitaría una persona nueva o un agente para ponerse en marcha:
- por qué importa el trabajo;
- qué queda dentro y fuera del alcance;
- archivos, enlaces, ejemplos o comportamientos observados relevantes;
- restricciones y decisiones ya tomadas;
- cómo se revisará la finalización.
Esa última línea hace más trabajo que todas las demás juntas. Es la diferencia entre un resultado que puedes aceptar en dos minutos y uno que tienes que reconstruir para entenderlo. Empieza con poco y ve refinando a medida que investigas el trabajo; una descripción de tarea puede mejorar sobre la marcha.
Los campos aportan el resto: tipo, estado, prioridad, fechas, etiquetas y un proyecto o sprint para dar contexto de planificación. La ejecución que se prepara para el agente puede incluir el título y la descripción, el estado y la prioridad actuales, el contexto del espacio y del sprint, los comentarios recientes —incluido el comentario que la activó—, las instrucciones y habilidades del agente, los repositorios, el entorno y la configuración de la ejecución. Unas descripciones pobres no se compensan con buenos modelos.
Asignación: dos campos, no uno
El error de diseño más habitual en la gestión de tareas para agentes es tener un único campo de asignado.
Manténlos separados. Las personas se asignan para la responsabilidad, y un espacio puede permitir una o varias. Un agente o un equipo de agentes se asigna al campo de ejecución, que se queda con selección única. Una tarea puede tener ambos a la vez, y cambiar el conjunto de personas no cambia al ejecutor, igual que asignar un agente no sustituye a las personas.
La ventaja es que ninguna tarea queda en manos de un bot. Cuando un resultado requiere una decisión, hay un nombre al que recurrir. Cuando un agente se equivoca, la conversación de revisión tiene un interlocutor. Nuestro recorrido por la gestión de proyectos con Claude Code muestra esa misma separación en una única tarea, desde el issue hasta el merge.
Los equipos de agentes ocupan ese mismo campo de ejecución, y la ejecución es líder primero: el agente líder arranca, lee el contexto y luego involucra a los miembros según haga falta. Usa un solo agente para trabajo bien definido y un equipo de agentes cuando el trabajo requiera coordinación.
Estado: la parte que controla la ejecución
El estado no es un adorno cuando hay agentes implicados. Cada estado visible pertenece a una categoría, y la categoría tiene un significado para el sistema.
| Categoría de estado | Qué significa | Efecto en las ejecuciones del agente |
|---|---|---|
| Backlog | Aparcado, no listo | Crear o asignar aquí no inicia ninguna ejecución |
| Sin empezar | Listo, sin comenzar | Mover aquí desde backlog puede iniciar al agente asignado |
| En curso | En progreso | Las ejecuciones continúan; varios estados pueden compartir esta categoría |
| Completado | Hecho, terminal | Es terminal, pero no cancela una ejecución ya activa |
| Cancelado | No continuará | Detiene las ejecuciones iniciadas para la tarea |
| Duplicado | Ya está representado en otro sitio | Detiene las ejecuciones iniciadas para la tarea |
Hay dos consecuencias que conviene interiorizar. El backlog es una zona de preparación real: prepara la tarea, adjunta el agente y no ocurrirá nada hasta que la muevas. Y marcar algo como completado no es lo mismo que detenerlo, así que cancela la ejecución que de verdad quieras detener.
La segunda regla es que el estado del ciclo de vida y el estado de trabajo del agente son independientes. Una tarea puede estar en un estado de tipo «en curso» mientras el agente trabaja, espera una respuesta humana, espera revisión humana o informa de un error. Estados de ejecución como en cola, enviado, en ejecución, completado, fallido y cancelado describen el avance de la ejecución y no mueven la tarea automáticamente. Confundir unos con otros es la razón por la que un tablero parece saludable mientras tres resultados siguen sin leerse.
Revisión: hacer explícito el traspaso
Los agentes terminan las ejecuciones en uno de dos lugares útiles: con un resultado o con una pregunta. Ambos deben llegar a una persona.
Esperar una respuesta humana, esperar revisión y el trabajo fallido o bloqueado son señales que requieren atención. Alimentan una cola personal y, en Sharkly, esa cola es la bandeja de entrada del agente, donde la persona responsable puede abrir la tarea, responder en contexto, revisar el resultado o decidir reintentar o reasignar el trabajo.
Los comentarios son la conversación duradera de la tarea. Úsalos para nuevo contexto, hallazgos de la revisión y decisiones, y mantén el objetivo estable y los criterios de aceptación en la descripción para que el requisito vigente siga siendo fácil de encontrar. Un comentario de un miembro en una tarea con un agente asignado y listo puede encolar otra ejecución, que es lo que hace que el feedback de la revisión continúe el trabajo en lugar de poner en marcha un segundo proceso. Las menciones cambian esto: mencionar a una persona o usar una mención general no inicia por sí mismo una ejecución del agente, y un comentario que menciona otros destinatarios sin el asignado suprime la ejecución predeterminada.
Antes de aceptar, lee las pruebas y no solo el diff. El registro de ejecución muestra por qué se encoló una ejecución, cuándo empezó y terminó, las llamadas a herramientas y los eventos del entorno de ejecución, el origen del disparo y los detalles del fallo. Aceptar es una persona que decide que el resultado es correcto, algo que ningún estado de ejecución puede hacer por ti. Descarga Sharkly si quieres que estos estados estén conectados entre sí en lugar de montarlos a mano.
Una plantilla de tarea que vale la pena copiar
Los equipos que escriben bien las tareas para agentes suelen acabar convergiendo en el mismo esqueleto. Guárdalo como fragmento y rellénalo; todo el proceso lleva unos tres minutos y te ahorra una ejecución desperdiciada.
Outcome: <what is true when this is done>
Context:
- Why this matters now
- Observed behavior, with the exact error or reproduction steps
- Files, links, or examples that are relevant
Scope:
- In: <the change you want>
- Out: <adjacent work the agent should not touch>
Constraints:
- Decisions already made, conventions to follow, things not to change
Review:
- How completion will be checked, and by whom
La línea de lo que queda fuera del alcance es la que se gana su sitio más rápido. Los agentes a los que se da un objetivo concreto y ningún límite tienden a mejorar cosas que no les pediste, y cada una de esas mejoras cuesta tiempo de revisión. Nombrar lo que hay que dejar en paz sale más barato que revisar todo lo que tocó.
Cinco errores que conviene evitar
- Un único campo de asignado. La responsabilidad y la ejecución se funden, y la propiedad del trabajo desaparece.
- Tratar una ejecución completada como un resultado completado. Que la ejecución termine no dice nada sobre si el cambio era correcto.
- Reintentar las ejecuciones fallidas por reflejo. Abre primero el registro. Errores del proveedor que parecen iguales a menudo requieren soluciones opuestas.
- Dejar que la revisión se acumule. Los resultados de agente sin revisar son una deuda que se acumula más rápido que las pull requests sin fusionar.
- Escribir tareas para quien ya sabe. Si los criterios de aceptación están solo en tu cabeza, el agente va a ciegas.
Preguntas frecuentes
¿Puede un agente cambiar el estado de una tarea? Dentro de unos límites. El flujo de trabajo del tipo de tarea restringe qué estados están disponibles, así que un agente solo puede seleccionar los estados que ese flujo permite.
¿Qué pasa si comento mientras hay una ejecución activa? Un comentario elegible puede encolarse para el siguiente ciclo de ejecución en lugar de iniciar un duplicado en paralelo, y los comentarios rápidos se agrupan para que no generen ejecuciones pendientes duplicadas.
¿Necesito un tipo de tarea aparte para el trabajo de agentes? Normalmente no. Usa un tipo aparte cuando el trabajo requiera un conjunto de campos o un flujo de trabajo claramente distintos, y etiquetas cuando solo necesites una clasificación ligera.
¿En qué se diferencia esto de la gestión de proyectos habitual? Las primitivas son las mismas; el rigor no. Nuestra guía sobre la gestión de proyectos con agentes de IA repasa qué cambia en cada primitiva cuando un ejecutor no puede hacer una pregunta aclaratoria en el pasillo.
