Cómo coordinar una flota de agentes de IA en un tablero de tareas

En cuanto pones a más de un agente de IA a trabajar sobre la misma lista de tareas, aparece un problema que un solo agente nunca tiene: dos agentes pueden ver la misma tarea lista e intentar reclamarla a la vez. Una app de tareas pensada para una persona que va tachando pendientes no tiene por qué resolver eso. Una app de tareas para agentes de IA sí.

El problema del doble reclamo

Si “reclamar una tarea” es solo un cambio de estado, dos agentes que consultan la misma cola en el mismo instante pueden verla disponible y empezar a trabajar los dos: esfuerzo desperdiciado en el mejor caso, resultados contradictorios en el peor. La solución no es una convención que los agentes deban respetar; es que el propio reclamo sea atómico, de modo que el intento del segundo agente simplemente no encuentre nada.

Cómo evita Done que una flota se estorbe

• next_task: una extracción atómica de la cola. Reclama la tarea lista de mayor prioridad y la devuelve; un segundo agente que la llame un instante después recibe la siguiente, nunca la misma.
• release_task: devuelve a la cola una tarea reclamada si un agente no puede terminarla ahora, en lugar de dejarla atascada en el limbo.
• fleet_status: una vista en vivo de cada tarea que un agente tiene reclamada, cuánto tiempo lleva con ella y si la reserva ya venció.
• Presupuestos de ejecución: start_run, check_budget y end_run limitan cuánto puede hacer cada sesión, para que un solo agente no consuma en silencio toda la cola.

¿Qué muestra realmente fleet_status?

Antes de tomar una tarea, un agente —o tú— puede llamar a fleet_status para ver exactamente qué está reclamado en toda la flota: qué tarea, qué agente, cuánto tiempo lleva reservada y si el reclamo venció (es decir, quien la tenía dejó de dar señales y la tarea vuelve a estar disponible). Es la misma visibilidad que querrías al entrar a una sala donde ya hay varias personas trabajando.

Cómo diseñar el flujo de una flota

No hay una única forma correcta. Algunas configuraciones usan un agente generalista en bucle que llama a next_task hasta vaciar la cola. Otras dividen por proyecto o por rol —un agente para el backlog de un proyecto concreto, otro para una cola de mantenimiento recurrente— y usan tokens limitados para que cada uno solo vea su carril. Los equipos que juntan los agentes de varias personas en un mismo tablero son los que más se apoyan en fleet_status, porque es justo el problema de visibilidad que crean los tableros compartidos.

Auditar lo que hizo la flota

Cada sesión de un agente corre como una ejecución, registrada con su propio presupuesto de llamadas a herramientas y de tiempo: start_run la abre, end_run la cierra con un resumen y un resultado, y check_budget le dice al agente (o a ti) cuánto queda del presupuesto de esa sesión antes de que se rechace por completo. Aparte, list_claude_shipped te da un listado limpio de todo lo que un agente marcó como hecho, del más reciente al más antiguo; útil para una reunión diaria, una retrospectiva o simplemente para responder “¿cuánto avanzaron los agentes esta semana?”.

Cuándo una flota no es la forma adecuada

La mayoría de la gente no necesita esto. Un solo agente conectado que avanza por la cola en orden de prioridad cubre bien el caso común, y fleet_status y la atomicidad de next_task no te cuestan nada si nunca usas un segundo agente. Este mecanismo se justifica específicamente cuando tienes varios agentes trabajando en paralelo, o cuando en el tablero de un equipo con plan Teams hay agentes de más de una persona trabajando en el mismo espacio de trabajo compartido.