Pipelines fijos frente a descomposición adaptativa

Cuando una tarea es demasiado grande para un solo prompt, debe descomponerla. Hay dos estrategias fundamentales, y elegir la adecuada es una competencia esencial de arquitectura.

• Pipeline fijo (encadenamiento de prompts): se codifica una secuencia de pasos conocida. El paso 1 alimenta al paso 2, que alimenta al paso 3.
• Descomposición adaptativa: el modelo decide qué hacer a continuación según lo que descubre y repite el proceso hasta alcanzar el objetivo.

Regla práctica: use pipelines fijos para pasos secuenciales conocidos y descomposición adaptativa para investigaciones abiertas. Esta lección precisa esa decisión.

Un pipeline fijo no es más que un encadenamiento de prompts: usted orquesta una secuencia determinista en su propio código. Conoce los pasos de antemano, así que los conecta explícitamente. Cada llamada realiza una tarea concreta y su salida se convierte en la entrada de la siguiente llamada.

Como usted controla el orden, el flujo es predecible, fácil de depurar y sencillo de analizar. No hay ramificaciones dirigidas por el modelo sobre qué hacer a continuación, sino únicamente el trabajo propio de cada paso.

Opte por un pipeline fijo cuando el trabajo tenga una estructura estable y conocida:

• Los pasos son los mismos en cada ejecución (extraer, después validar y después dar formato).
• El orden importa y rara vez cambia.
• Desea costes y latencia predecibles, además de una depuración sencilla.
• Cada etapa tiene una responsabilidad clara y acotada.

Un ejemplo clásico es la extracción de datos estructurados. Extraiga los campos, ejecute después una pasada de validación y reintento y, por último, añada la procedencia. Siempre realiza esas tres tareas, en ese orden; por tanto, encadénelas.

La descomposición adaptativa delega la planificación en el modelo. Usted le proporciona herramientas y un objetivo; el modelo inspecciona los resultados y elige la siguiente acción. Este es el bucle agéntico: envíe una solicitud, inspeccione stop_reason y, si es tool_use, ejecute las herramientas, añada los resultados al historial y repita hasta end_turn.

No puede conectar la ruta de antemano porque no la conoce: depende de lo que revele cada paso.

Elija la descomposición adaptativa para investigaciones abiertas cuya ruta no pueda conocerse de antemano:

• Depuración a partir de un síntoma impreciso: busca con grep, lee y después vuelve a buscar usos según lo que encuentra.
• Investigación en varias fuentes, donde las consultas de seguimiento dependen de las respuestas anteriores.
• Atención al cliente, donde la siguiente acción depende del resultado de una consulta.

Aquí, las ramificaciones SON el trabajo. Un pipeline rígido omitiría rutas o acabaría convertido en una cantidad inmanejable de condicionales.

El error más común en un bucle adaptativo durante el examen es terminarlo buscando en el texto del modelo palabras como «listo» o «terminado». No lo haga. Las decisiones las dirige el modelo; termine según el stop_reason de la API.

El bucle termina cuando stop_reason es end_turn. Mientras sea tool_use, debe continuar. Un límite de iteraciones es únicamente una red de seguridad, nunca el mecanismo de parada principal. Reserve el control codificado para las garantías, no para decidir cuándo se ha completado conceptualmente el trabajo.

Los sistemas reales combinan ambos enfoques. El flujo externo suele ser un pipeline fijo, pero una de sus etapas puede ser un bucle agéntico adaptativo. Así obtiene la previsibilidad del encadenamiento en el nivel macro y la flexibilidad allí donde realmente la necesita.

Ejemplo: un pipeline de extracción cuya etapa intermedia es un agente adaptativo de «resolución de ambigüedades» que puede llamar a herramientas de consulta un número desconocido de veces, rodeado por una etapa determinista de validación y formato antes y después.

La descomposición no se limita a pipelines frente a bucles: también consiste en dividir una tarea para proteger la atención del modelo. La revisión de código en varios archivos es el caso paradigmático.

Una sola pasada por muchos archivos diluye la atención y hace que se pasen por alto tanto los errores locales como los problemas de integración. La solución es una descomposición deliberada: primero, una pasada local por archivo y, después, una pasada independiente de integración entre archivos. Dos pasadas centradas superan a una sola pasada sin enfoque.

En un sistema multiagente de tipo hub-and-spoke, el coordinador descompone el objetivo, delega tareas a subagentes y, después, agrega los resultados. Se trata de una descomposición adaptativa en la capa de orquestación: el coordinador decide cómo dividir el trabajo en función de la solicitud.

Importante: los subagentes no heredan el historial de conversación del coordinador. Cada solicitud a un subagente debe incluir explícitamente todo el contexto necesario. Varias llamadas a Task en una misma respuesta se ejecutan en paralelo, lo que resulta útil cuando los subproblemas son independientes.

El trabajo adaptativo suele abarcar varias sesiones. Claude Code le ofrece --resume <name> para continuar una sesión con nombre y fork_session para crear una rama desde un punto compartido y explorar alternativas en paralelo.

Pero tenga cuidado: los resultados de herramientas reanudados pueden estar obsoletos si la base de código cambió desde entonces. A veces, una sesión nueva iniciada con un resumen estructurado es mejor que reanudar: obtiene el estado actual junto con el contexto sintetizado, sin arrastrar resultados de herramientas desactualizados.

Antes de construir, pregúntese:

• ¿Conozco de antemano los pasos y siguen un orden fijo? -> canalización fija / encadenamiento de prompts.
• ¿Depende el siguiente paso de lo que revelen los pasos anteriores? -> bucle agéntico adaptativo.
• ¿La mayor parte es fija, pero hay una etapa incierta? -> enfoque híbrido: encadene el flujo exterior e incorpore un bucle adaptativo.
• ¿Está revisando muchos archivos? -> descomponga el trabajo en una pasada por archivo y, después, una pasada entre archivos.

Y siempre: termine los bucles adaptativos según stop_reason, usando los límites de iteraciones solo como mecanismo de seguridad.

Ideas clave:

• Canalización fija (encadenamiento de prompts) para pasos conocidos y ordenados: predecible, fácil de depurar y económica.
• Descomposición adaptativa para investigaciones abiertas en las que el siguiente paso depende de lo que descubra.
• El enfoque híbrido es habitual: un flujo exterior fijo con una etapa adaptativa incorporada.
• Termine siempre los bucles adaptativos según stop_reason (end_turn); los límites de iteraciones son un mecanismo de seguridad, nunca el criterio principal de parada. Nunca analice el texto en busca de "done."
• Para revisar varios archivos, descomponga el trabajo en una pasada por archivo y, después, una pasada independiente entre archivos.
• Los subagentes no heredan el historial: transmita el contexto explícitamente. Reanude las sesiones con cuidado; una sesión nueva con un resumen estructurado puede ser mejor que resultados de herramientas reanudados y obsoletos.