Patrón de descomposición de tareas: dividir lo complejo

Esencia del patron

Task Decomposition es un patron que permite que un agente divida una tarea compleja en subtareas mas pequenas antes de la ejecucion.

Cuando usarlo: cuando una tarea compleja no puede completarse de forma fiable en un solo paso y hay que dividirla en subtareas.

En lugar de resolver todo de una vez, el agente:

• analiza la tarea
• define pasos
• los ejecuta en secuencia

Cada paso es una subtarea separada.

Problema

Imagina que el agente recibe una tarea:

"Prepara un reporte mensual de ventas."

En la practica, no es un solo paso, sino una secuencia de subtareas:

• recopilar datos
• limpiarlos y validarlos
• calcular metricas
• redactar la conclusion

Sin un plan explicito, una tarea compleja se vuelve opaca rapidamente: se pierden pasos y la logica se rompe.

Si el agente intenta hacerlo todo "en una sola pasada", normalmente aparece caos:

• faltan pasos intermedios
• orden de ejecucion incorrecto
• mezcla entre planificacion y ejecucion
• control de errores debil

Ese es el problema: sin estructura, es facil ejecutar una tarea compleja de forma inestable y con errores.

Solucion

Task Decomposition agrega una etapa separada de planificacion antes de ejecutar.

Analogia: es como armar muebles con instrucciones. Sin instrucciones, es facil confundir el orden o saltarse una pieza. Con instrucciones, cada paso es transparente y el error es mas facil de encontrar.

Principio clave: primero plan, luego acciones. Eso hace que el proceso sea controlable.

Para evitar que el agente salte directo a la respuesta final, decomposition-policy fija:

• que subtareas son obligatorias
• en que orden deben ejecutarse
• cuando hay que hacer re-plan

El proceso controlado se ve asi (como en el diagrama):

1. Goal: aclarar objetivo y restricciones
2. Plan: dividir la tarea en subtareas y dependencias
3. Ejecucion de pasos (Step 1..N / Execute): ejecutar subtareas segun el plan
4. Combine Results: unir resultados de los pasos en uno solo
5. Done: producir el resultado final

El guardado intermedio de resultados (checkpoint) ocurre dentro de la etapa de ejecucion.

Task Decomposition ayuda a:

• aumentar la previsibilidad
• no perder etapas importantes
• localizar errores en un paso concreto
• obtener resultados mas estables en tareas largas

Funciona mejor si:

• hay limites claros de pasos y dependencias
• cada paso tiene un criterio de finalizacion
• hay reglas de re-plan cuando cambian las condiciones
• la etapa de ejecucion no salta el plan aprobado

Incluso si el modelo "quiere" dar una respuesta final de inmediato, decomposition-policy devuelve el proceso a pasos estructurados.

Como funciona

Task Decomposition no ejecuta los pasos por si mismo.

Solo define que subtareas hay que ejecutar, y cada una puede ejecutarse mediante un bucle ReAct separado.

Es decir, el agente primero construye un plan y luego normalmente resuelve las subtareas de forma secuencial, paso a paso.

En codigo se ve asi

steps = plan(goal)

for step_no, step in enumerate(steps, start=1):
    result = execute(step, context=context)  # cada paso ve resultados de pasos anteriores
    if not result.ok:
        return stop_or_replan(step_no=step_no, reason=result.error)
    context.append(result.data)

return build_final_output(context)

El agente divide la tarea en subtareas y las ejecuta en secuencia.

Como se ve durante la ejecucion

Goal: preparar un reporte mensual de ventas

Plan:
1. recopilar datos de ventas
2. limpiar datos
3. calcular metricas clave
4. construir graficos
5. escribir conclusion

Execute step 1: el sistema llama fetch_sales_data(month)
Observe: datos en bruto recibidos
Entre pasos: raw_data se vuelve entrada para la limpieza

Execute step 2: el sistema llama clean_sales_data(raw_data)
Observe: datos limpios y validados
Entre pasos: clean_data se vuelve entrada para calcular metricas

Execute step 3: el sistema llama calculate_metrics(clean_data)
Observe: metricas calculadas

Execute step 4: el sistema llama build_charts(metrics)
Observe: graficos construidos

Execute step 5: el sistema compone resumen
Observe: reporte final listo
Stop: despues del paso final, el ciclo termina

Cada paso se ejecuta por separado, y el resultado intermedio se vuelve entrada para la siguiente etapa.

Cuando encaja - y cuando no

Encaja

No encaja

Porque el plan puede ser inexacto o innecesario.

Cuando usar Task Decomposition (vs otros patrones)

Usa Task Decomposition cuando primero necesites dividir un objetivo grande en subtareas mas pequenas y ejecutables.

Prueba rapida:

• si necesitas "primero dividir una tarea compleja en subtareas" -> Task Decomposition
• si necesitas "despues de cada paso decidir que hacer luego" -> ReAct Agent

Como combinar con otros patrones

• Task Decomposition + ReAct - cada subtarea se ejecuta paso a paso para controlar mejor los errores.
• Task Decomposition + Routing - para cada subtarea se selecciona automaticamente el ejecutor mas adecuado.
• Task Decomposition + Orchestrator - el Orchestrator gestiona dependencias y paralelismo para que el plan se ejecute sin bloqueos.

Diferencia con ReAct

ReAct ayuda a ejecutar un paso.

Task Decomposition define que pasos hay que ejecutar en absoluto.

Resumen

Ventajas y desventajas

FAQ

Q: Siempre se necesita un plan?
A: No. Para tareas simples, puede ser innecesario.

Q: El agente puede cambiar el plan?
A: Si. Si aparecen datos nuevos durante la ejecucion o falla uno de los pasos, el agente puede revisar el plan inicial: agregar nuevas subtareas, cambiar el orden o crear un plan nuevo antes de las siguientes acciones.

Q: Task Decomposition funciona sin ReAct?
A: Si. La planificacion de subtareas puede hacerse por separado, por ejemplo si cada paso tiene un Workflow fijo. Pero en tareas mas complejas, cada subtarea suele ejecutarse con un bucle ReAct.

Que sigue

Task Decomposition permite dividir una tarea en pasos.

Pero que hacer si hay que elegir entre varios agentes?