Saltar a contenido

Traducción automática

Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Bucles de razonamiento para agentes de IA en 2026: ReAct vs ReWOO vs Plan-and-Execute

Parte 1 de la serie Engineering the Agentic Stack

Construir agentes de IA útiles es ahora, sobre todo, una cuestión de diseño de sistemas, no de prompt engineering. La decisión más importante es el bucle de razonamiento del agente: cómo planifica el sistema, llama a herramientas, observa resultados y decide cuándo parar.

Este artículo compara los tres patrones de bucle para agentes de IA que merece la pena conocer en 2026: ReAct, ReWOO y Plan-and-Execute. El ejemplo de referencia es un agente de análisis de mercado que construí en LangGraph, con todo el código en GitHub.

Resumen: ReAct es flexible pero caro, ReWOO es rápido cuando el flujo de trabajo es predecible, y Plan-and-Execute encaja bien en análisis de varios pasos. Un agente de IA en producción puede enrutar entre bucles de razonamiento según cada solicitud, usando estado compartido y nodos de LangGraph con checkpoint para que cada tarea use el bucle que mejor encaja con su forma.

Por qué importan los bucles de razonamiento en agentes de IA

Hace un año, hacer útil a un LLM consistía sobre todo en cómo redactabas el prompt. Ahora va de diseño de grafos: cómo se conectan el razonamiento, el uso de herramientas y la memoria.

El bucle de razonamiento se sitúa en el centro de ese grafo. Decide cuándo piensa el modelo, cuándo llama a una herramienta y cuándo se detiene. Si eliges el incorrecto, gastas tokens de más en llamadas que no necesitabas, añades segundos de latencia por turno o tu agente se rompe en cuanto una herramienta devuelve algo que no esperaba.

Tres patrones de razonamiento para agentes de IA

Comparativa de patrones de razonamiento

ReAct: pensar, actuar, observar, repetir

ReAct (Yao et al., 2022) es el patrón original para agentes interactivos. Ejecuta un bucle:

  1. Thought: el agente genera un "pensamiento" para descomponer el objetivo y planificar el siguiente paso.
  2. Action: a partir de ese pensamiento, llama a una herramienta.
  3. Observation: el agente lee el resultado, que actualiza su comprensión para el siguiente pensamiento.

Patrón ReAct

Ventajas:

  • Anclar el proceso en observaciones reales reduce los hechos inventados.
  • El agente puede cambiar de estrategia sobre la marcha según lo que acaba de ver.
  • El "scratchpad" te deja una traza auditable del razonamiento.

Inconvenientes:

  • El historial se acumula y se vuelve a procesar en cada paso, así que la latencia y el coste crecen con la longitud del bucle.
  • Es ineficiente cuando las llamadas a herramientas podrían haberse planificado de antemano, que es precisamente el nicho que cubre ReWOO.
  • Sin una condición de parada o un límite de pasos, el bucle se ejecutará indefinidamente.

Mejor para: tareas exploratorias, depuración, situaciones en las que no puedes predecir qué viene después.

ReWOO: planificarlo todo por adelantado

ReWOO (Reasoning WithOut Observation) es un primo más eficiente de ReAct. La idea clave es desacoplar el razonamiento de la ejecución de herramientas: en vez de parar para observar cada acción, ReWOO planifica toda la secuencia de llamadas a herramientas en una sola pasada.

  1. Plan: una llamada al LLM escribe el plan completo de llamadas a herramientas, usando placeholders de variables (#E1, #E2) para salidas que todavía no existen.
  2. Worker: un ejecutor no basado en LLM ejecuta las herramientas planificadas en secuencia o en paralelo, rellenando los placeholders.
  3. Solver: una llamada final al LLM toma las observaciones recopiladas y redacta la respuesta.

Patrón ReWOO

Ventajas:

  • Aproximadamente 5 veces más eficiente en tokens que ReAct, porque te saltas el historial repetido de Thought-Action-Observation.
  • Menor latencia. No hay reenvío del historial en cada paso.
  • El planner puede ajustarse de forma independiente, sin entorno en vivo.

Inconvenientes:

  • Es frágil cuando las herramientas fallan. El plan asume que todo funciona.
  • Necesita flujos de trabajo predecibles.
  • Sin lógica de fallback explícita, un plan defectuoso sigue ejecutándose.

Mejor para: snapshots rápidos, comprobaciones de estado, dashboards. Cualquier cosa en la que las herramientas se comporten de forma predecible.

Plan-and-Execute: un híbrido

Plan-and-Execute se sitúa entre los dos. El artículo plantea una separación simple que la mayoría de agentes modernos ha adoptado:

  1. Fase de planificación: el agente genera primero un plan que divide la tarea en subtareas más pequeñas.
  2. Fase de ejecución: después, el agente lleva a cabo esas subtareas.

El artículo original se centraba en zero-shot prompting. Frameworks modernos como LangGraph lo han convertido en un patrón completo de orquestación con ejecución secuencial y elección de modelo por paso (un modelo fuerte de razonamiento para planificar, y uno más barato para ejecutar).

Patrón Plan-and-Execute

Ventajas:

  • Razonamiento jerárquico que refleja cómo un experto humano descompone un proyecto.
  • Permite replanificar. Puedes pausar y reevaluar si el resultado de un paso no era el esperado.
  • Especialización de modelos. El planner puede ser caro; el executor, barato.
  • Complejidad acotada, con un checkpoint claro después de cada paso.

Inconvenientes:

  • Más latencia que ReWOO porque los pasos se ejecutan secuencialmente.
  • Más estado que gestionar.
  • Excesivo para consultas de una sola vez.

Mejor para: análisis complejos de varios pasos, tareas de investigación, cualquier cosa que necesite síntesis al final.

Cómo elegir un bucle de razonamiento para agentes de IA

Feature ReAct (2022) Plan-and-Execute (2023) ReWOO (2023)
Core philosophy Improvisador: actúa y luego decide qué hacer según el resultado. Arquitecto: construye un plano completo, lo ejecuta y luego revisa. Optimizador: escribe un "script" con variables y lo ejecuta de una vez.
Workflow Bucle iterativo: Thought → Action → Observation. Dos etapas: Fase 1 (Planning), Fase 2 (Execution). Desacoplado: el Planner crea un grafo de llamadas a herramientas; el Worker las ejecuta.
Adaptability Máxima: puede cambiar de dirección tras cada llamada a herramienta. Media: normalmente replanifica solo después de completar un conjunto de pasos. Mínima: normalmente sigue el script inicial salvo que falle el Solver.
Efficiency Baja: alto uso de tokens; debe releer todo el historial en cada paso. Media: ahorra tokens al no "repensar" durante la ejecución. Alta: llamadas mínimas al LLM; puede paralelizar la ejecución de herramientas para ganar velocidad.
Best for Exploración abierta o tareas con resultados impredecibles. Tareas de largo recorrido que requieren un objetivo estable (p. ej., escribir un informe). Flujos estructurados y repetibles (p. ej., comprobar el tiempo en 5 ciudades).

1. ReAct: el patrón de "pensar sobre la marcha"

Cómo se siente: como una persona depurando un problema. "Voy a probar esto... vale, no ha funcionado, voy a probar otra cosa."

Fortaleza: maneja unknown unknowns. Si un resultado de búsqueda revela un tema nuevo, el agente puede pivotar en el siguiente paso.

Debilidad: tiende a entrar en bucle tras una acción fallida. Es el patrón más caro en tokens.

2. Plan-and-Execute: el patrón orientado a la misión

Cómo se siente: como un project manager. "Aquí está el plan de 5 pasos. Vamos a hacer los pasos del 1 al 5 y luego comprobamos si hemos terminado."

Fortaleza: mantiene al agente centrado en el objetivo de alto nivel. Mejores tasas de éxito en tareas largas y complejas.

Debilidad: si el paso 1 falla de una forma que rompe los pasos 2-5, el agente puede seguir ejecutando el plan roto antes de darse cuenta.

3. ReWOO: el patrón de compilador

Cómo se siente: como escribir un pequeño programa. "Necesito datos de Tool A y Tool B, y luego los combinaré en Tool C."

Fortaleza: mucho más rápido y barato. El plan se compila una vez con placeholders (#E1 para la salida de la primera herramienta), y luego se ejecuta sin más llamadas al LLM hasta la síntesis final.

Debilidad: ciego durante la ejecución. Si la primera herramienta dice "No encuentro a esa persona", el agente seguirá ejecutando los pasos siguientes que dependían de que esa persona existiera.

Cuál elegir

  • ReAct si el agente está conversando con un usuario y necesita reaccionar en el momento.
  • Plan-and-Execute si estás automatizando un trabajo largo y de varios pasos, como un informe de investigación.
  • ReWOO si tienes un pipeline predecible y quieres recortar tu factura de API en algo así como un 80%.

Un ejemplo práctico: el agente de análisis de mercado

Para aterrizar esto, construí un agente de análisis de mercado que usa los tres patrones en una sola codebase, sobre una tarea de investigación de mercado.

Usa LangGraph para la orquestación. Los tres patrones comparten el mismo objeto de estado, así que el router puede elegir cuál ejecutar según cada solicitud:

Arquitectura de Plan-and-Execute

Definición del estado

El estado compartido captura todo lo que el agente necesita en todos los modos:

class PlanStep(BaseModel):
    """A single step in the research plan."""
    step_number: int
    description: str
    tool_hint: str | None = None
    completed: bool = False
    result: str | None = None

class UserProfile(BaseModel):
    """Structured user context loaded from long-term memory."""
    risk_tolerance: str | None = None
    investment_horizon: str | None = None

class AgentState(BaseModel):
    """Main state for the Market Analyst Agent graph."""

    # Identity and profile context for memory-backed personalization
    user_id: str
    user_profile: UserProfile = Field(default_factory=UserProfile)

    # Message history with LangGraph's add_messages reducer
    messages: Annotated[list, add_messages] = Field(default_factory=list)

    # Execution mode (set by router)
    execution_mode: ExecutionMode | None = None

    # Plan-and-Execute state
    plan: list[PlanStep] = Field(default_factory=list)
    current_step_index: int = 0

    # ReWOO state
    rewoo_plan: list[ReWOOPlanStep] = Field(default_factory=list)

    # Research results
    research_data: ResearchData | None = None

    # HITL output
    draft_report: DraftReport | None = None
    report_approved: bool = False

Patrón 1: implementación de Plan-and-Execute

Plan-and-Execute encaja bien en tareas que necesitan síntesis en varios pasos. La clave es mantener separadas la planificación y la ejecución: un modelo potente para el plan inicial, y luego un bucle ReAct para ejecutar cada paso con margen para reaccionar a los resultados de las herramientas.

Cómo encaja con el patrón:

  1. Una fase inicial única de planificación. Una sola llamada al LLM produce el plan completo como una lista de descripciones de pasos.
  2. Salida estructurada mediante Schema-Guided Reasoning, que garantiza JSON válido.
  3. Sin ejecución de herramientas todavía. El planner solo decide qué hacer, no cómo hacerlo.
  4. Pasos legibles por humanos. Cada paso es texto que un executor interpretará.
# System prompt guides the LLM to think like a research analyst
# creating a strategic plan, not immediate tool calls
PLANNER_SYSTEM_PROMPT = """You are a senior investment research analyst.
Break down stock analysis requests into 4-6 research steps covering:
1. Current price and basic metrics
2. Recent news and announcements
3. Competitor analysis (if relevant)
4. Financial health assessment
5. Risk factors
6. Investment thesis synthesis

Output as JSON with step_number, description, and tool_hint."""

# Schema-Guided Reasoning: Enforce structure with Pydantic
class PlanOutput(BaseModel):
    """Structured output for the planner."""

    steps: list[PlanStep] = Field(description="Research steps to execute")
    ticker: str = Field(description="The stock ticker being analyzed")

def planner_node(state: AgentState) -> dict:
    """Generate a research plan from the user's request.

    This is Phase 1 of Plan-and-Execute: creating the high-level strategy.
    """

    # Use a powerful model for strategic planning
    llm = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0)

    # Apply Schema-Guided Reasoning to guarantee valid plan structure
    # This prevents common formatting errors that would break execution
    structured_llm = llm.with_structured_output(PlanOutput)

    # Context from long-term memory personalizes the plan
    profile_context = f"""
User Profile:
- Risk Tolerance: {state.user_profile.risk_tolerance}
- Investment Horizon: {state.user_profile.investment_horizon}
"""

    # Single LLM call creates the complete plan
    result: PlanOutput = structured_llm.invoke([
        SystemMessage(content=PLANNER_SYSTEM_PROMPT + profile_context),
        HumanMessage(content=f"Create a research plan for: {last_user_message}"),
    ])

    # State update: Store the plan and initialize tracking
    return {
        "plan": result.steps,           # The sequential steps to execute
        "current_step_index": 0,        # Start at step 0
        "research_data": ResearchData(ticker=result.ticker),  # Initialize data container
    }

Esa línea de llm.with_structured_output(PlanOutput) es Schema-Guided Reasoning (SGR), que traté en un artículo anterior. Forzar el esquema PlanOutput hace que el planner siempre devuelva una lista válida de pasos. LangGraph usa después esas salidas estructuradas para dirigir un flujo de control determinista mediante aristas condicionales.

Patrón 2: ejecución ReAct

Una vez existe el plan, el executor ejecuta cada paso como su propio bucle ReAct. Esta es la Fase 2: cada paso es lo bastante pequeño como para que un ciclo Thought-Action-Observation se mantenga enfocado, y el agente pueda reaccionar a lo que devuelva la herramienta.

Cómo encaja la parte ReAct:

  1. Ejecución iterativa. Un paso cada vez, con feedback de observación.
  2. El bucle Thought-Action-Observation se ejecuta dentro de create_react_agent.
  3. Los resultados de pasos anteriores se pasan como contexto para el razonamiento actual.
  4. El agente elige herramientas según la descripción del paso.
  5. Puede cambiar de enfoque a mitad del paso según lo que devuelva una herramienta.
# Tools available for the ReAct agent to choose from
TOOLS = [
    get_stock_snapshot,
    get_price_history,
    search_news,
    search_competitors,
    get_financials,
]

def executor_node(state: AgentState) -> dict:
    """Execute the current step using a ReAct agent.

    This is Phase 2 of Plan-and-Execute: adaptive execution of each planned step.
    Each step runs as a mini ReAct loop until completion.
    """

    # Get the current step from the plan
    current_step = state.plan[state.current_step_index]

    # Build context from what we've learned so far
    # This matters: each step builds on previous observations
    previous_context = ""
    for step in state.plan[:state.current_step_index]:
        if step.result:
            previous_context += f"\nStep {step.step_number}: {step.result}\n"

    # Create a ReAct agent for this step
    # LangGraph's create_react_agent implements the full Thought-Action-Observation loop:
    # 1. Agent generates a "thought" about what tool to call
    # 2. Agent calls the tool ("action")
    # 3. Tool returns result ("observation")
    # 4. Agent decides: call another tool or finish
    react_agent = create_react_agent(
        model=ChatAnthropic(model="claude-sonnet-4-5-20250929"),
        tools=TOOLS,
    )

    # Invoke the ReAct loop for this single step
    # The agent will loop internally until it completes the step
    result = react_agent.invoke({
        "messages": [
            SystemMessage(content=EXECUTOR_SYSTEM_PROMPT),
            HumanMessage(content=f"""Execute Step {current_step.step_number}:
{current_step.description}

Ticker: {state.research_data.ticker}
Previous findings: {previous_context}"""),
        ]
    })

    # Extract the final answer from the ReAct agent's message history
    # The last message contains the synthesis after all tool calls
    updated_plan = list(state.plan)
    updated_plan[state.current_step_index] = PlanStep(
        step_number=current_step.step_number,
        description=current_step.description,
        completed=True,
        result=result["messages"][-1].content,  # Final observation
    )

    # State update: Mark step complete and advance to next
    return {
        "plan": updated_plan,
        "current_step_index": state.current_step_index + 1,
    }

Ese es el flujo central de Plan-and-Execute: un modelo potente escribe el plan, y luego ReAct ejecuta cada paso con adaptabilidad total.

Patrón 3: ReWOO para snapshots rápidos

Para briefings rápidos, ReWOO se salta el razonamiento intercalado y ejecuta las herramientas en paralelo. El planner emite por adelantado un script compilado de llamadas a herramientas, y el worker lo ejecuta sin más intervención del LLM.

Su forma es esta:

  1. Tres fases (Planner → Worker → Solver), sin bucles.
  2. Las llamadas a herramientas referencian placeholders #E1, #E2 para resultados que todavía no existen.
  3. No hay LLM durante la ejecución. El worker simplemente ejecuta herramientas.
  4. Las herramientas independientes se ejecutan en paralelo.
  5. Una llamada de síntesis al final, sobre todos los datos de una vez.

Fase 1: planner de ReWOO (crea por adelantado el grafo completo de ejecución)

class ReWOOPlanStep(BaseModel):
    """A step in the ReWOO plan with variable placeholders.

    Key difference from Plan-and-Execute's PlanStep:
    - Contains actual tool_name and tool_args (not just description)
    - Uses variable references (#E1) for dependencies
    """
    step_id: str  # e.g., "#E1" - becomes a variable
    description: str
    tool_name: str     # Exact tool to call
    tool_args: dict    # May contain variable refs like {"price": "#E1"}
    depends_on: list[str] = []  # For dependency ordering
    result: str | None = None

class ReWOOPlanOutput(BaseModel):
    """Structured output for ReWOO planner."""
    steps: list[ReWOOPlanStep] = Field(description="Planned tool calls with variables")

def rewoo_planner_node(state: AgentState) -> dict:
    """Generate a complete plan of tool calls upfront.

    This is the key difference from Plan-and-Execute: instead of creating
    human-readable step descriptions, we create EXACT tool calls that
    the worker will execute blindly.
    """

    llm = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0)

    # Schema-Guided Reasoning ensures valid tool call specifications
    structured_llm = llm.with_structured_output(ReWOOPlanOutput)

    ticker = state.research_data.ticker if state.research_data else "UNKNOWN"

    # Single LLM call to plan ALL tool executions
    result: ReWOOPlanOutput = structured_llm.invoke([
        SystemMessage(content=REWOO_PLANNER_PROMPT),
        HumanMessage(content=f"""Create a ReWOO plan for: {query}

Ticker: {ticker}

Output tool calls with:
- step_id: Variable name (#E1, #E2, etc.)
- description: What this accomplishes
- tool_name: Exact tool from the list
- tool_args: Dictionary of arguments
- depends_on: List of step_ids this depends on"""),
    ])

    # State update: Store the complete execution plan
    # Worker will execute this without any LLM involvement
    return {"rewoo_plan": result.steps}

Fase 2: worker de ReWOO (ejecuta herramientas sin razonamiento del LLM)

def rewoo_worker_node(state: AgentState) -> dict:
    """Execute all planned tools in parallel (no LLM calls).

    This is the key efficiency: Worker is "dumb" - it just runs tools
    according to the plan. No LLM calls = massive token savings.
    """

    results = {}  # Store results keyed by step_id (e.g., "#E1": "$150.23")

    # Execute ALL independent steps in parallel using ThreadPoolExecutor
    # This is where ReWOO gets its speed advantage
    with ThreadPoolExecutor(max_workers=5) as executor:
        futures = {
            executor.submit(execute_tool, step): step
            for step in state.rewoo_plan
            if not step.depends_on  # Only independent tools for parallel batch
        }

        # Collect results as they complete
        for future in as_completed(futures):
            step = futures[future]
            results[step.step_id] = future.result()
            # No LLM reasoning here - just store the raw tool output

    # State update: Store results for the Solver phase
    return {"rewoo_plan": updated_steps}

Fase 3: solver de ReWOO (sintetiza todos los resultados en una sola llamada al LLM)

def rewoo_solver_node(state: AgentState) -> dict:
    """Synthesize all tool results into a flash briefing.

    This is the second efficiency gain: Instead of interleaving
    LLM calls with tool execution (like ReAct), we make ONE
    final synthesis call with all gathered data.
    """

    # Build context from ALL tool results at once
    tool_results = []
    for step in state.rewoo_plan:
        if step.result:
            tool_results.append(f"### {step.description}\n{step.result}")

    context = "\n\n".join(tool_results)

    # Single LLM call to synthesize everything
    structured_llm = llm.with_structured_output(FlashBriefingOutput)
    result = structured_llm.invoke([
        SystemMessage(content=REWOO_SOLVER_PROMPT),
        HumanMessage(content=f"Create a flash briefing from this data:\n\n{context}"),
    ])

    return {"draft_report": result}

La diferencia clave: ReWOO planifica por adelantado cada llamada a herramienta con placeholders (#E1, #E2), las ejecuta en paralelo sin llamadas al LLM entre medias y sintetiza los resultados en una sola llamada al final. Eso lo hace barato para flujos de trabajo predecibles.

Entender el código: en qué difiere cada patrón

Los tres patrones difieren en cuándo y cómo llaman al LLM:

Pattern LLM calls during execution State updates Key code pattern
Plan-and-Execute 1 para planificar + 1 por paso Finalización secuencial de pasos planner_node() → loop: executor_node() → reporter_node()
ReAct (within each step) Varias por paso (ciclos thought-action) Historial de mensajes acumulado create_react_agent() hace bucle internamente hasta completar el paso
ReWOO 1 para planificar + 0 durante la ejecución + 1 para síntesis Finalización paralela de herramientas rewoo_planner_node() → rewoo_worker_node() → rewoo_solver_node()

Lo que cambia entre ellos es lo que produce el planner. Eso decide todo lo que viene después.

  1. Plan-and-Execute crea descripciones de pasos legibles por humanos:

    # Planner output (list of PlanStep objects)
plan = [
    PlanStep(
        step_number=1,
        description="Get current price and key financial metrics",
        tool_hint="get_stock_price"
    ),
    PlanStep(
        step_number=2,
        description="Search for recent news and earnings",
        tool_hint="search_news"
    ),
    # ... more steps
]

    El executor lee cada descripción y decide a qué herramientas llamar. Flexible, pero cuesta una llamada al LLM por paso.

  2. ReAct no tiene un plan inicial. Usa razonamiento iterativo:

    # No planning phase - ReAct works step-by-step with accumulated messages
messages = [
    HumanMessage(content="Execute Step 1: Get current price"),
    AIMessage(content="I'll call get_stock_price"),
    ToolMessage(tool_call_id="1", content="$132.45"),
    AIMessage(content="Now I need metrics..."),
    # ... agent continues until step complete
]

    Varias llamadas al LLM por paso, adaptándose según las observaciones. El más flexible, el más caro.

  3. ReWOO crea especificaciones explícitas y ejecutables de llamadas a herramientas:

    # Planner output (list of ReWOOPlanStep objects)
rewoo_plan = [
    ReWOOPlanStep(
        step_id="#E1",
        tool_name="get_stock_price",
        tool_args={"ticker": "NVDA"}
    ),
    ReWOOPlanStep(
        step_id="#E2",
        tool_name="search_news",
        tool_args={"query": "NVDA earnings", "limit": 5}
    ),
    # ... all tool calls planned upfront
]

    El worker ejecuta a ciegas, sin intervención del LLM. Todo el razonamiento vive en el planner y en el solver. El más barato de los tres.

Flujo de memoria y estado:

  • Plan-and-Execute: el estado se mueve por plan → current_step_index → research_data.
  • ReAct: el estado se acumula en el array messages (todo el historial de la conversación).
  • ReWOO: el estado se mueve por rewoo_plan, con los campos result rellenados por el worker.

Juntándolo todo: cableado del grafo

Así es como conviven los tres patrones en un único sistema LangGraph. Comparten un solo AgentState y viven en un solo grafo. Un router elige la ruta según cada solicitud, así que esto es un agente con tres modos de ejecución, no tres agentes disfrazados de uno.

LangGraph mantiene el cableado de forma declarativa:

def create_graph(checkpointer=None):
    builder = StateGraph(AgentState)

    # Add nodes
    builder.add_node("router", router_node)
    builder.add_node("planner", planner_node)
    builder.add_node("executor", executor_node)
    builder.add_node("reporter", reporter_node)
    builder.add_node("rewoo_planner", rewoo_planner_node)
    builder.add_node("rewoo_worker", rewoo_worker_node)
    builder.add_node("rewoo_solver", rewoo_solver_node)

    # Define edges
    builder.add_edge(START, "router")
    builder.add_conditional_edges("router", route_after_router, {
        "planner": "planner",
        "rewoo_planner": "rewoo_planner",
    })

    # Deep Research path
    builder.add_edge("planner", "executor")
    builder.add_conditional_edges("executor", route_after_executor, {
        "executor": "executor",  # Loop back for more steps
        "reporter": "reporter",  # Done with plan
    })
    builder.add_edge("reporter", END)

    # Flash Briefing path (ReWOO)
    builder.add_edge("rewoo_planner", "rewoo_worker")
    builder.add_edge("rewoo_worker", "rewoo_solver")
    builder.add_edge("rewoo_solver", END)

    return builder.compile(
        checkpointer=checkpointer,
        interrupt_before=["reporter"],  # HITL pause for approval
    )

Selección automática del patrón con un router

Para elegir el bucle correcto para cada solicitud, añadí un clasificador router. Usa Schema-Guided Reasoning para mantener fiable la clasificación:

class ExecutionMode(str, Enum):
    """Execution mode for the agent."""

    DEEP_RESEARCH = "deep_research"  # Plan-and-Execute + ReAct (thorough)
    FLASH_BRIEFING = "flash_briefing"  # ReWOO (fast, token-efficient)

class RouterOutput(BaseModel):
    """Structured output for the router."""

    mode: ExecutionMode  # DEEP_RESEARCH or FLASH_BRIEFING
    ticker: str
    reasoning: str

ROUTER_SYSTEM_PROMPT = """Classify the user's request:

1. **deep_research**: Complex analysis requiring synthesis
   - Examples: "Analyze strategic risks", "investment thesis"

2. **flash_briefing**: Quick snapshots, simple data retrieval
   - Examples: "quick snapshot", "current price"

Default to deep_research if unclear."""

structured_llm = llm.with_structured_output(RouterOutput)

Con esto en su sitio, los usuarios no eligen un modo. El router envía "precio actual" a ReWOO e "investment thesis" a Plan-and-Execute por su cuenta.

Ideas clave

  1. ReAct es la opción por defecto cuando necesitas flexibilidad, a costa de tokens y latencia.
  2. ReWOO gana en velocidad y coste cuando las herramientas son fiables y los resultados predecibles.
  3. Plan-and-Execute es la elección correcta para análisis complejos que necesitan síntesis al final.
  4. Un router puede elegir entre ellos según cada solicitud, así que el usuario no tiene que hacerlo.
  5. La gestión del estado importa. El checkpointing de LangGraph es lo que hace posibles las interrupciones y la recuperación.

La implementación completa, incluido el router y el estado compartido, está en el repositorio del agente de análisis de mercado.

Qué viene después

La Parte 2, Arquitectura de memoria para agentes de IA en 2026, trata el contexto a corto plazo con checkpointing en PostgreSQL y el conocimiento a largo plazo en almacenamiento vectorial Qdrant. Eso es lo que hace posibles los flujos pause/resume y el aprendizaje entre sesiones.

Referencias

El código del Market Analyst Agent está en GitHub si quieres seguir la lectura.

Serie: Engineering the Agentic Stack