Colas de trabajo para agentes: Linear como tablero de tareas para IA
Una cola de trabajo para agentes es una lista de tickets que la IA toma uno a uno. Cómo armarla en Linear con delegación, vistas y revisión humana.
¿Qué es una cola de trabajo para agentes?
En una cola, las tareas esperan su turno y se procesan en orden. Para agentes de IA, la cola reemplaza la práctica de dar instrucciones sueltas en un chat, donde el encargo se pierde en el historial y nadie sabe qué se pidió ni qué quedó hecho.
Una cola útil tiene cuatro propiedades:
- Cada tarea es un registro. Tiene identificador, descripción, estado y dueño.
- El orden es visible. Se sabe qué sigue y qué depende de qué.
- El resultado vuelve al mismo lugar. El agente deja su avance, el enlace a su código o una nota de bloqueo en la tarea.
- Hay una persona responsable. La cola no decide por sí sola; alguien revisa y acepta.
¿Cómo se arma esa cola en Linear?
Según la documentación de Linear, los agentes funcionan como usuarios de la aplicación: un administrador los instala, elige a qué equipos tienen acceso y, desde ahí, cualquier persona con acceso a esos equipos puede interactuar con ellos. Hay dos formas de darles trabajo: delegarles un issue o mencionarlos con @ en un comentario o en una descripción. Linear también permite instalar agentes de terceros o crear uno propio con su plataforma para desarrolladores.
La pieza clave es la delegación. Según la documentación, delegar es darle un issue a un agente manteniendo a una persona como asignada: la persona sigue siendo responsable del trabajo y el agente contribuye en su nombre. Se hace eligiendo al agente en el menú de asignación, y se puede cambiar o quitar en cualquier momento con la opción “No agent”.
| Forma de involucrar al agente | Para qué sirve |
|---|---|
| Delegar el issue | Encargarle una tarea completa mientras una persona sigue como responsable |
| Mencionarlo con @ | Pedirle algo puntual en un comentario o en una descripción |
| Regla de triage (Business o Enterprise) | Delegar automáticamente los issues que cumplen una regla |
Un issue delegado sigue apareciendo en la vista “My Issues” de la persona asignada, así que el responsable no pierde de vista lo que se hace en su nombre. Para armar la cola, Linear ofrece vistas personalizadas que se pueden filtrar por delegado y reportes (Insights) que se pueden segmentar por delegado. Con eso, “la cola” es una vista: los issues delegados a un agente, ordenados por prioridad y agrupados por estado.
Dos detalles de la documentación que conviene saber antes de montarla. Los agentes no cuentan como asientos facturables, pero el proveedor de cada agente puede tener su propio precio, así que revisa sus condiciones antes de instalarlo. Y recuerda que el agente solo puede recibir issues de los equipos a los que el administrador le dio acceso al instalarlo.
¿Qué ve el agente cuando le delegas un ticket?
Linear permite a administradores y líderes de equipo escribir una “guía adicional” en Markdown que los agentes reciben al trabajar en issues. Puede ser de todo el workspace o de un equipo; si existen ambas, manda la del equipo. Sirve para decir en qué repositorio trabajar, cómo citar el issue en commits y PRs, o qué revisión hace falta. La documentación aclara que cómo aplica el agente esa guía depende de su integración.
Si construyes tu propio agente, la documentación para desarrolladores describe el ciclo: al delegar o mencionar al agente, Linear crea una sesión (AgentSession) y envía un webhook. El agente debe confirmar con una primera actividad en pocos segundos; después reporta su progreso con actividades como pensamientos, acciones y una respuesta final. Si necesita aclaración, emite una petición de información y la persona responde. Las sesiones muestran estados visibles para los usuarios, entre ellos pending, active, awaitingInput, error y complete.
Para los agentes de programación que se conectan por otra vía, Linear tiene además un servidor MCP oficial; si quieres entender el protocolo, lee MCP explicado para diseñadores.
¿Qué debe tener un ticket listo para un agente?
Un ticket que un agente puede tomar bien responde cuatro preguntas:
- ¿Qué se quiere? Un objetivo en una frase, no un tema.
- ¿Cómo sé que está hecho? Criterios de aceptación verificables: un test que pasa, una pantalla que cumple una regla.
- ¿Qué puedo tocar? Carpetas, archivos o módulos permitidos.
- ¿Qué hago si me atoro? Por ejemplo: dejar una nota de bloqueo y cambiar el estado, en lugar de improvisar.
Si el ticket es “mejorar el registro”, el agente va a inventar lo que quiere decir “mejorar”. Si dice “agregar validación de correo al formulario de registro, con el mensaje de error del diseño en Figma y tests para tres casos”, tienes una tarea que se puede revisar.
¿Cómo se ordena la cola?
Un orden simple funciona mejor que uno complicado:
- Bloqueos primero. Lo que desbloquea a otros va arriba.
- Tareas independientes juntas. Así se pueden paralelizar sin pisarse.
- Revisiones antes que nuevas tareas. Un PR esperando revisión frena todo el flujo.
Y limita el tamaño de la cola. Cincuenta tickets para agentes producen cincuenta resultados que nadie revisa. Un límite práctico es que la cola nunca tenga más trabajo del que una persona puede revisar en un día.
¿Cuándo NO conviene?
- Cuando la tarea no tiene criterios de aceptación. El agente entrega algo, pero nadie sabe si sirve.
- Cuando el trabajo cambia cada hora. La cola se vuelve obsoleta y los agentes trabajan sobre supuestos viejos.
- Cuando nadie revisa. Una cola sin revisión solo acumula trabajo sin validar.
Ejemplo
Ejemplo ilustrativo: un equipo de producto tiene cinco issues delegados a agentes. Tres son independientes: ajustar un estado vacío, agregar un test de accesibilidad y actualizar un texto de ayuda. Dos dependen de una decisión de diseño que aún no está lista, así que quedan en espera con una nota que explica qué falta. Cada agente toma su issue y deja un enlace al PR y un resumen de lo que probó. La vista personalizada filtrada por delegado muestra cuánto tiene cada agente, y la persona asignada revisa primero los PR que destraban a otros; solo después abre el issue de la decisión pendiente.
El blog de Fernando tiene un caso de dos agentes coordinados con tickets en archivos, Hice que Claude Opus 4.8 gestionara a otro agente de IA mientras yo trabajaba. Para la capa que decide quién toma cada tarea, lee orquestación de agentes. Para mantener los cambios de cada agente aislados, git worktrees para agentes.
Errores comunes
- Dar tickets sin criterios de aceptación.
- Dejar que todos los agentes tomen lo que quieran, sin límites de carpeta.
- Usar la cola como buzón de ideas. Lo que no está listo debe quedarse en un borrador, no en la cola.
- Medir el éxito por cuántos tickets cerraron los agentes. Lo que importa es cuántos se aceptaron tras revisión.
- Dejar issues delegados sin una persona asignada que responda por el resultado.
- Instalar un agente sin revisar qué permisos y qué equipos se le concedieron.