Workflows agénticos: Orquestación de pipelines de IA de múltiples pasos

Una sola llamada a un LLM puede responder una pregunta. Lograr que se realice un trabajo real requiere una secuencia orquestada de llamadas.

Por qué los LLM de una sola llamada no son suficientes

Lanza una tarea compleja a un LLM en un solo prompt y te enfrentarás a barreras predecibles.

La tarea necesita información externa. El modelo tiene que buscar en una base de datos, llamar a una API o leer archivos que no tiene en su contexto. La tarea tiene dependencias. El paso 2 depende de la salida del paso 1, y no puedes especificar ambos por adelantado porque aún no sabes qué producirá el paso 1. La tarea necesita verificación. El modelo escribe código, pero tú quieres ejecutarlo y ver si funciona antes de continuar. Una sola llamada no puede ejecutar y validar su propia salida. Y la tarea es demasiado grande para una sola pasada. Un informe de investigación implica reunir fuentes, esquematizar, redactar secciones, verificar datos y revisar. Ningún prompt único produce una calidad publicable.

Estos no son problemas de capacidad del modelo. Son problemas arquitectónicos. La solución es la orquestación: dividir la tarea en pasos y gestionar el flujo entre ellos.

Qué son los workflows agénticos

Un workflow agéntico es un sistema donde un LLM se ejecuta en un bucle. Observa el estado actual, decide qué hacer a continuación, realiza una acción, observa el resultado y repite hasta que la tarea esté terminada.

El bucle agéntico mínimo:

while not task_complete:
    # 1. Observe: gather current state and available information
    observation = get_current_state()

    # 2. Reason: LLM decides what to do next
    action = llm.decide(
        task=original_task,
        history=action_history,
        observation=observation,
        available_tools=tools
    )

    # 3. Act: execute the chosen action
    result = execute(action)

    # 4. Update: record what happened
    action_history.append((action, result))

    # 5. Check: is the task done?
    task_complete = llm.evaluate_completion(action_history)

Dibujado como un bucle, se ve así:

Eso parece sencillo. La parte difícil son los patrones que utilizas dentro del bucle y cómo manejas los fallos inevitables.

Patrones clave

ReAct (reasoning + acting)

Es el patrón más común. El modelo alterna entre pensar (razonamiento sobre qué hacer) y actuar (llamada a herramientas). Cada paso de razonamiento es explícito en la salida, lo que hace que las decisiones del agente sean transparentes y fáciles de depurar.

Thought: I need to find the quarterly revenue for Acme Corp. Let me search the database.
Action: search_database(query="Acme Corp quarterly revenue 2025")
Observation: [Results: Q1: $12M, Q2: $14M, Q3: $13M, Q4: $16M]
Thought: I have all four quarters. Total annual revenue is $55M. Now I need to compare
         with the previous year.
Action: search_database(query="Acme Corp quarterly revenue 2024")
Observation: [Results: Q1: $10M, Q2: $11M, Q3: $11M, Q4: $13M]
Thought: 2024 total was $45M. Year-over-year growth is 22.2%. I can now write the summary.
Action: write_report(content="...")

Esa cadena de razonamiento explícito es tanto su fortaleza como su carga. Cuesta tokens pensar en voz alta, pero a cambio obtienes trazas de decisión auditables. Aquí se puede ver en la realidad: ejecuciones ReAct registradas de un agente de clips de video, reproducidas con el pensamiento real, las llamadas a herramientas y los resultados:

Cada consulta de película pasa por un bucle de búsqueda web, búsqueda en YouTube, localización de marcas de tiempo y creación del clip antes de finalizar; la ejecución fuera de alcance (una canción) es rechazada en el primer paso. Este es el patrón ReAct haciendo exactamente lo que describe la traza anterior, con herramientas en vivo.

Plan-and-execute (Planificar y ejecutar)

En lugar de decidir un paso a la vez, el agente genera primero un plan completo y luego ejecuta cada paso. Esto funciona mejor para tareas donde la estructura general es predecible y se desea minimizar las llamadas al modelo.

# Phase 1: Planning
plan = llm.generate_plan(task)
# Output: ["1. Fetch data from API", "2. Clean and transform",
#          "3. Run analysis", "4. Generate charts", "5. Write report"]

# Phase 2: Execution
for step in plan:
    result = execute_step(step, context=previous_results)
    if needs_replanning(result):
        plan = llm.replan(task, completed_steps, result)

La replanificación es la parte que la mayoría de la gente omite y luego lamenta. Los planes rígidos se rompen al primer contacto con la realidad. Un buen agente de planificación y ejecución detecta cuándo un paso falla o produce una salida inesperada y regenera el resto del plan.

Reflection (Reflexión)

Después de generar una salida, una segunda llamada al LLM (o el mismo modelo con un prompt diferente) critica el resultado. La crítica se retroalimenta en un paso de revisión.

draft = llm.generate(task)
for i in range(max_iterations):
    critique = llm.critique(draft, criteria=quality_criteria)
    if critique.score >= threshold:
        break
    draft = llm.revise(draft, critique.feedback)

Este patrón es sorprendentemente efectivo para tareas de escritura, generación de código y cualquier salida donde la calidad pueda ser evaluada. Dos pasadas con reflexión superan consistentemente a una sola pasada, incluso cuando la pasada única utiliza un prompt más detallado.

Tool chaining (Encadenamiento de herramientas)

El agente orquestas múltiples herramientas en secuencia, donde la salida de cada herramienta alimenta a la siguiente. A diferencia del simple function calling, el agente decide en tiempo de ejecución qué herramientas encadenar y en qué orden.

Task: "Summarize the top 3 Hacker News stories about AI"
1. web_search("Hacker News top stories AI") → URLs
2. fetch_page(url_1) → article text
3. fetch_page(url_2) → article text
4. fetch_page(url_3) → article text
5. summarize(articles) → final summary

Frameworks

Algunos frameworks empaquetan estos patrones en componentes reutilizables.

LangGraph modela los workflows como grafos dirigidos con estado. Los nodos son pasos de procesamiento (llamadas a LLM, uso de herramientas, lógica condicional). Las aristas definen el flujo. El estado se pasa entre nodos y se persiste, lo que permite construir interrupciones de human-in-the-loop y workflows de larga duración.

CrewAI define agentes como roles con historias de fondo, metas y herramientas. Múltiples agentes colaboran con patrones de delegación definidos. Es ideal para simular workflows de equipo como investigador, redactor y editor.

AutoGen es el framework de Microsoft para conversaciones multi-agente. Los agentes se comunican a través de mensajes, lo que permite una colaboración al estilo de un chat grupal en tareas complejas.

El SDK de agentes de Anthropic es un SDK de Python ligero enfocado en el bucle agéntico central con uso de herramientas, transferencias entre agentes y guardrails. Mínima abstracción, máximo control.

La elección correcta depende de tu complejidad. Para agentes sencillos que usan herramientas, un bucle agéntico básico (o un SDK ligero) suele ser suficiente. Para workflows complejos de múltiples agentes con ramificaciones y persistencia, LangGraph o frameworks similares basados en grafos valen lo que pesan.

Manejo de errores y reintentos

Los sistemas agénticos fallan de maneras en que las llamadas únicas a un LLM no lo hacen.

Las herramientas fallan. Las API agotan el tiempo de espera, las bases de datos devuelven errores, las operaciones de archivos fallan. Cada llamada a una herramienta necesita un bloque try/catch con un mensaje de error significativo que se retroalimente al agente. Ocurren bucles infinitos. El agente repite la misma acción esperando un resultado diferente. Establece límites máximos de iteración y detecta patrones de repetición. Ocurre el desbordamiento de contexto. Los agentes de larga duración acumulan un historial que supera los límites de contexto, por lo que necesitas resúmenes del historial antiguo o un enfoque de ventana deslizante (sliding-window). Los costos se disparan. Un agente que no converge sigue consumiendo créditos de API, así que establece un límite de presupuesto por tarea.

# Practical error handling in an agent loop
MAX_ITERATIONS = 20
MAX_COST = 5.00  # dollars

for i in range(MAX_ITERATIONS):
    if total_cost > MAX_COST:
        return fallback_response("Budget exceeded")

    try:
        action = llm.decide(state)
        result = execute(action, timeout=30)
    except ToolError as e:
        state.add_observation(f"Tool failed: {e}. Try an alternative approach.")
        continue
    except TimeoutError:
        state.add_observation("Action timed out. Simplify the approach.")
        continue

    state.update(action, result)
    if is_complete(state):
        return state.final_output

Evaluación y observabilidad

No puedes mejorar lo que no puedes medir. Los workflows agénticos necesitan algunas cosas.

Tracing. Cada llamada al LLM, invocación de herramienta y punto de decisión debe registrarse con marcas de tiempo, entradas, salidas y conteo de tokens. LangSmith, Arize y Braintrust manejan esto. Evaluación a nivel de paso. No evalúes solo la salida final. Evalúa los pasos intermedios. ¿Eligió el agente la herramienta correcta? ¿Leyó correctamente la salida de la herramienta? Seguimiento de costos por tarea. Conoce exactamente cuántos tokens consume cada workflow para identificar patrones costosos. Pruebas de regresión. Construye una suite de pruebas de tareas con comportamientos esperados y ejecútala cada vez que cambies prompts, herramientas o la lógica de orquestación.

Ejemplos del mundo real

Un agente de investigación. Dado un tema, el agente busca en la web, lee múltiples fuentes, identifica hallazgos clave, cruza referencias de afirmaciones y produce un informe estructurado con citas. Eso son de 10 a 30 llamadas a herramientas entre pasos de búsqueda, obtención y análisis.

Un revisor de código. El agente lee el diff de un pull request, elige los archivos a revisar, busca patrones comunes (problemas de seguridad, problemas de rendimiento, violaciones de estilo), ejecuta las pruebas pertinentes y produce una revisión estructurada con comentarios integrados. Se integra con Git, ejecutores de pruebas y herramientas de análisis estático.

Triage de atención al cliente. El agente lee un ticket entrante, busca en la base de conocimientos artículos relevantes, verifica el estado y el historial de la cuenta del cliente, clasifica el problema y, o bien responde automáticamente, o lo deriva al equipo humano adecuado con un resumen adjunto.

Cuándo es excesivo

No todo necesita un agente. Si una tarea se puede realizar con un solo prompt bien diseñado, añadir una capa de orquestación solo te aporta latencia, costo y nuevos modos de fallo sin ningún beneficio.

Usa workflows agénticos cuando la tarea genuinamente requiera múltiples pasos con uso de herramientas externas, cuando los pasos tengan dependencias que no puedas resolver en una sola llamada, cuando la tarea se beneficie de la autocorrección mediante la reflexión, o cuando necesites la aprobación de un human-in-the-loop en pasos intermedios.

Quédate con las llamadas únicas cuando la tarea esté bien definida y sea autónoma, cuando todo el contexto necesario quepa en un solo prompt, cuando la latencia importe más que la calidad (los bucles agénticos son lentos) y cuando los modos de fallo de la orquestación de múltiples pasos no valgan la pena por la mejora de calidad.

La sobrecarga de los sistemas agénticos es real. Pero para tareas complejas de múltiples pasos que tienen que interactuar con el mundo exterior, son la única arquitectura que realmente funciona.