Cómo dividir una tarea grande en subtareas con IA

“Rediseñar el onboarding” no es una tarea con la que un agente de IA —ni la mayoría de las personas— pueda simplemente empezar. Es un objetivo disfrazado de tarea. La solución no es un mejor prompt; es convertir un elemento demasiado grande en varios concretos que un agente pueda reclamar, trabajar y terminar de a uno.

¿Por qué se estancan las tareas grandes?

Una tarea que en realidad son cinco suele quedarse arriba de la cola sin moverse, porque nada en ella dice qué hacer a continuación. Las personas la posponen; los agentes se paralizan ante la ambigüedad o, peor, adivinan, hacen algo que suena razonable e informan un resultado que técnicamente toca el título pero no da en el blanco. Descomponerla resuelve ambos problemas de la misma forma: reemplaza algo vago por varias cosas sin ambigüedad.

¿Cómo funciona decompose_task?

decompose_task divide una tarea en varias subtareas en una sola llamada, y cada una es una tarea real en sí misma: se puede asignar, programar y trabajar por separado. Apunta un agente a la tarea demasiado grande y pídele que primero la descomponga; recibes un conjunto de tareas hijas concretas en lugar de un párrafo con el que nadie va a hacer nada.

De subtareas a un plan

Las subtareas por sí solas no te dicen el orden ni la forma del trabajo. render_plan presenta los pasos de una tarea de tres formas a la vez: una lista de verificación en markdown que se lee de un vistazo, JSON estructurado para herramientas y un widget interactivo para los hosts MCP que lo muestran. Llámalo justo después de decompose_task o propose_plan para convertir un montón de subtareas en algo que se lea como un plan de verdad.

Marcar los pasos a medida que ocurren

set_step_status marca un paso como hecho o lo reabre y devuelve el plan actualizado: es la acción natural cuando le dices a un agente que un paso está terminado, o cuando lo marcas tú en el widget. Un detalle importante: si un agente marca un paso propio que no es agent_ok, igual pasa por la aprobación en lugar de cerrarse directamente. Descomponer no crea un atajo para saltarse la aprobación; solo hace que cada unidad de trabajo sea lo bastante pequeña para aprobarse rápido.

Propón el plan antes de comprometerte

Para cualquier cosa sustancial, la mejor secuencia no es descomponer y arrancar, sino descomponer, llamar a propose_plan y esperar. La tarea pasa a plan_proposed y sale de la cola de tareas listas hasta que llamas a approve_plan (empieza el trabajo) o reject_plan (vuelve a sin empezar, con tus comentarios incorporados). Revisas el enfoque antes de invertir esfuerzo, y ese es un lugar mucho más barato para detectar una suposición equivocada que cuando el trabajo ya está hecho.

Un ejemplo práctico

“Rediseñar el onboarding”, después de decompose_task, se convierte en: auditar el flujo actual, bocetar tres opciones, recibir comentarios, construir la ganadora y escribir la documentación. render_plan convierte esas cinco en una lista ordenada. propose_plan te permite aprobar ese orden —quizás adelantas “recibir comentarios”— antes de construir nada. Luego cada subtarea se reclama, se trabaja y se marca como hecha (o pasa a aprobación) por separado, en lugar de tener una tarea enorme sin tocar durante un mes.