2026-01-31 · Actualizado 2026-07-14

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

AI Bucles de razonamiento de agente en 2026: ReAct frente a ReWOO y Plan-and-Execute

Parte 1 de la serie de ingeniería de la pila Agentic

Un agente reasoning loop gestiona la forma en que un sistema planifica sus acciones, invoca herramientas, procesa los resultados y determina el momento oportuno para detenerse. Dicho flujo de control influye directamente en los costes, en la latencia y en la capacidad de recuperación ante respuestas inesperadas por parte de las herramientas.

Este artículo compara los tres patrones AI agent loop que resultan esenciales conocer en 2026: ReAct, ReWOO y Plan-and-Execute. El ejemplo práctico que se utiliza es un Agente Analista de Mercados que desarrollé en LangGraph, cuyo código completo está disponible en GitHub.

Se trata de la capa interna de la serie. Las partes posteriores añaden el estado desde el cual reanuda el bucle, las herramientas que puede llamar, la política que rige dichas llamadas, el runtime encargado de mantener activa una ejecución, y los harness que realizan las verificaciones necesarias para determinar si el trabajo realmente se ha completado.

TL;DR: ReAct es flexible pero costoso, ReWOO es rápido cuando el flujo de trabajo es predecible, y Plan-and-Execute resulta adecuado para análisis de múltiples pasos. Un agente AI en entorno de producción puede alternar entre bucles de razonamiento por solicitud, aprovechando un estado compartido y nodos LangGraph con puntos de control, de modo que cada tarea reciba el bucle que se ajuste a su estructura específica.

El bucle controla el costo, la latencia y la recuperación

Un agente útil requiere algo más que un buen prompt. Su grafo de control debe ser capaz de vincular el razonamiento, las herramientas y la memoria, al mismo tiempo que gestiona las fallos.

El reasoning loop regula los momentos en que el modelo planifica una acción, invoca una herramienta, recibe el resultado y finaliza su ejecución. Una elección inadecuada genera llamadas al modelo innecesarias y aumenta la latencia. Además, puede impedir que el agente se recupere de un tool result inesperado.

Tres patrones de razonamiento de agente AI

ReAct: pensar, actuar, observar, repetir

ReAct Yao et al. (2022) presentan el patrón original para los agentes interactivos. Este funciona mediante un bucle:

1. Pensamiento: el agente genera un “pensamiento” para descomponer el objetivo y planificar el siguiente paso.
2. Acción: basándose en dicho pensamiento, llama a una herramienta.
3. Observación: el agente analiza el resultado, lo que actualiza su comprensión para el siguiente pensamiento.

Ventajas:

• Basarse en observaciones reales reduce la aparición de hechos inventados.
• El agente puede modificar su estrategia en tiempo real según lo que acaba de observar.
• El historial de llamadas a herramientas y de observaciones proporciona un rastro de ejecución concreto.

Desventajas:

• La historia se acumula y se vuelve a procesar en cada paso, por lo que la latencia y el costo aumentan a medida que crece la longitud del bucle.
• Es una práctica ineficiente cuando el tool calls podría haberse planificado de antemano, y es precisamente en este ámbito donde ReWOO brinda una solución especializada.
• Al no existir una condición de parada ni un límite de pasos, el bucle seguirá ejecutándose indefinidamente.

Ideal para: tareas exploratorias, depuración y situaciones en las que no se puede predecir qué ocurrirá a continuación.

ReWOO: planificar todo de antemano

ReWOO (Reasoning Without Observation) es una versión más eficiente de ReAct. La clave está en desacoplar el razonamiento de la ejecución de herramientas: en lugar de detenerse para observar cada acción, ReWOO planifica toda la secuencia de tool calls en una sola pasada.

1. Plan: una llamada a LLM escribe el plan completo de tool calls, utilizando marcadores de posición variables (#E1, #E2) para aquellos resultados que aún no existen.
2. Worker: un ejecutor que no es LLM ejecuta las herramientas planificadas de forma secuencial o paralela, rellenando los marcadores de posición.
3. Solver: una llamada final a LLM procesa las observaciones recopiladas y genera la respuesta.

Ventajas:

• Se realizan menos llamadas repetidas al modelo que con ReAct, siempre que el plan inicial siga siendo válido.
• Menor latencia. No es necesario volver a enviar el historial en cada paso.
• El planificador puede ser ajustado por separado, sin necesidad de contar con un entorno en tiempo real.

Desventajas:

• Es frágil cuando las herramientas presentan comportamientos inesperados. El plan parte de la premisa de que todo funciona correctamente.
• Requiere flujos de trabajo predecibles.
• Sin una lógica de recuperación explícita, un plan defectuoso sigue ejecutándose.

Ideal para: capturas rápidas, verificaciones de estado y paneles de control. Cualquier escenario en el que las herramientas se comporten de forma predecible.

Planificar y ejecutar: un enfoque híbrido

Planificación y ejecución se encuentra entre los dos. El artículo describe una división sencilla que han adoptado la mayoría de los agentes modernos:

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

El artículo original se centraba en el prompting de tipo zero-shot. Técnicas modernas como frameworks, por ejemplo LangGraph, han evolucionado este enfoque hasta convertirlo en un patrón de orquestación completo que permite una ejecución secuencial y la selección de modelos específicos para cada paso (un modelo de razonamiento potente para la planificación y uno más económico para la ejecución).

Ventajas:

• Razonamiento jerárquico que imita la forma en que un experto humano desglosa un proyecto.
• Es posible volver a planificar: se puede pausar el proceso y reevaluarlo si el resultado de una fase es inesperado.
• Especialización del modelo: el planificador puede ser costoso, mientras que el ejecutor puede ser económico.
• Complejidad limitada, con un checkpoint claro tras cada paso.

Desventajas:

• Mayor latencia que ReWOO, ya que los pasos se ejecutan de forma secuencial.
• Más estado por gestionar.
• Es un exceso para consultas puntuales.

Ideal para: análisis complejos de múltiples pasos, tareas de investigación y cualquier caso que requiera síntesis final.

Elegir según el punto en el que puede fallar el plan

La tabla constituye un punto de partida, y no un resultado de benchmark. Se debe emplear ReAct cuando cada observación pueda influir en la acción siguiente. Aplicar el enfoque Plan-and-Execute cuando la tarea general pueda descomponerse, pero los pasos individuales sigan requiriendo retroalimentación. Utilizar ReWOO cuando las dependencias se conozcan antes de la ejecución y una entrada defectuosa pueda interrumpir las llamadas posteriores. Es necesario medir los tres enfoques teniendo en cuenta la latencia de la herramienta, el modelo, el conjunto de tareas y la política de reintentos, en lugar de basarse únicamente en el costo.

Ejemplo práctico: el agente Market Analyst

Para concretar esto, he desarrollado un Agente Analista de Mercado que emplea los tres patrones en una misma base de código, para una tarea de investigación de mercado.

Utiliza LangGraph Para la orquestación, los tres patrones comparten el mismo objeto de estado, lo que permite al router seleccionar cuál de ellos ejecutar para cada solicitud:

Definición de estado

El estado compartido captura todo lo que el agente necesita entre los diferentes 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 tipo planificar-y-ejecutar

Plan-and-Execute es la opción adecuada para tareas que requieren una síntesis de múltiples pasos. La clave está en mantener separados el proceso de planificación y la ejecución: se utiliza un modelo potente para elaborar el plan inicial, y posteriormente un bucle ReAct que permite ejecutar cada paso con la flexibilidad necesaria para react y tool results.

Cómo se alinea con el patrón:

1. Una única fase de planificación inicial. Una sola llamada a LLM genera todo el plan en forma de lista de descripciones de pasos.
2. Salida guiada por esquemas, que valida el plan antes de su ejecución.
3. Todavía no hay ejecución de herramientas. El planificador solo decide qué se debe hacer, no cómo.
4. Pasos legibles para humanos. Cada paso es un texto que será interpretado por el ejecutor.

# 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)

    # Ask for a typed plan and validate it before execution.
    # The API can still fail, so production code also handles that exception.
    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
    }

Eso llm.with_structured_output(PlanOutput) La línea correspondiente es el Razonamiento Guiado por Esquema (SGR), el cual ya abordé en un artículo anterior. El esquema permite a la aplicación rechazar un plano mal formado antes de que LangGraph utilice los campos validados para generar aristas condicionales.

Patrón 2: ejecución de ReAct

Una vez que existe el plan, el ejecutor procesa cada paso como una iteración independiente de ReAct. Esta es la Fase 2: cada paso es lo suficientemente pequeño como para que el ciclo de Pensamiento-Acción-Observación mantenga su enfoque, y el agente puede react actuar en función de los resultados que devuelva la herramienta.

Cómo se alinea la parte ReAct:

1. Ejecución iterativa. Un paso a la vez, con retroalimentación basada en observaciones.
2. El bucle Pensamiento-Acción-Observación se ejecuta en el interior create_react_agent3. Los resultados del paso anterior se incorporan como contexto para el razonamiento actual.
3. El agente selecciona las herramientas en función de la descripción del paso.
4. Puede cambiar de enfoque a mitad de paso según los resultados 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 básico de Planificar y Ejecutar: un modelo potente elabora el plan y, a continuación, ReAct ejecuta cada paso con una adaptabilidad total.

Patrón 3: ReWOO para capturas rápidas

Para las reuniones informativas rápidas, ReWOO omite el razonamiento entrelazado y ejecuta las herramientas de forma paralela. El planificador emite de antemano un script compilado con tool calls, y el trabajador lo ejecuta sin necesidad de ninguna otra intervención de LLM.

La forma de este:

1. Tres fases (Planificador → Trabajador → Resolutor), sin bucles.
2. Referencia Tool calls #E1, #E2 marcadores de posición para resultados que aún no existen.
3. No se produce ningún LLM durante la ejecución; el trabajador simplemente ejecuta las herramientas.
4. Las herramientas independientes se ejecutan en paralelo.
5. Una llamada de síntesis al final, que procesa todos los datos a la vez.

Fase 1: Planificador ReWOO (crea de antemano el grafo de ejecución completo)

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 ReWOO (ejecuta herramientas sin realizar razonamiento 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: Solucionador ReWOO (sintetiza todos los resultados en una única llamada a 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}

ReWOO planifica cada tool call con antelación y almacena las dependencias en marcadores de posición como #E1 y #E2El ejecutor puede realizar llamadas independientes de forma paralela sin tener que preguntar al modelo qué hacer a continuación. Una última llamada al modelo combina los resultados, lo que permite mantener costos bajos en flujos de trabajo predecibles.

Dónde cada patrón llama al modelo

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

Lo que difiere entre ellos es el resultado que genera el planificador. Él es quien determina todo lo que ocurre a continuación en el flujo de trabajo.

1. Plan-and-Execute genera descripciones de pasos legibles para el usuario:

   # 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 ejecutor lee cada descripción y decide qué herramientas llamar. Es flexible, pero implica un costo de una llamada LLM por paso.

2. ReAct no dispone de un plan inicial. Utiliza un 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
   ]

   Las múltiples llamadas a LLM por paso se adaptan en función de las observaciones y, por lo general, tienen un costo superior al de los dos modos planificados.

3. ReWOO genera especificaciones explícitas y ejecutables de tool call:

   # 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 trabajador se ejecuta de forma automática, sin ninguna intervención de LLM. Todas las llamadas al modelo tienen lugar dentro del planificador y el resolutor, lo que permite predecir con precisión el número de dichas llamadas.

Flujo de memoria y estado:

• Plan-and-Execute: el estado recorre los movimientos plan → current_step_index → research_data.
• ReAct: el estado se acumula en el messages array (el historial completo de la conversación).
• ReWOO: el estado evoluciona a través de rewoo_plan, con result campos rellenados por el trabajador.

Integrándolo todo: conectando el grafo

Aquí se muestra cómo los tres patrones coexisten en un único sistema LangGraph. Comparten una AgentState y coexisten en un único grafo. Un router elige la ruta para cada solicitud; por lo tanto, se trata de un único agente con tres modos de ejecución, y no de tres agentes separados.

LangGraph mantiene la definición de conexiones 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 de patrones mediante un router

Para seleccionar el bucle adecuado para cada solicitud, he incorporado un clasificador de enrutador. Este utiliza el Razonamiento Guiado por Esquema para garantizar la fiabilidad de 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 implementado, los usuarios no tienen que seleccionar ningún modo. El router dirige automáticamente el dato “precio actual” a ReWOO y la “tesis de inversión” a Plan-and-Execute.

Conclusiones clave

1. ReAct proporciona los puntos de retroalimentación más frecuentes, pero a costa de realizar llamadas al modelo de forma repetida.
2. ReWOO reduce los viajes de ida y vuelta del modelo cuando las herramientas son fiables y las dependencias son predecibles.
3. Plan-and-Execute es adecuado para análisis complejos que pueden descomponerse antes de su ejecución, pero que aún requieren retroalimentación en cada paso.
4. Un router puede elegir entre ellos según cada solicitud, por lo que los usuarios no tienen que hacerlo.
5. El bucle necesita un estado almacenado para seguir funcionando tras una interrupción o un reinicio del trabajador. Ese es el tema de la Parte 2.

La implementación completa, incluido el enrutador y el estado compartido, se encuentra en el Repositorio de agentes analistas de mercado.

La siguiente capa es la memoria

Parte 2, AI Arquitectura de memoria de agente en 2026, Separa el checkpoints reutilizable de los conocimientos entre sesiones y de los documentos del proyecto. Sin esa capa de estado, el enrutador y el ejecutor mencionados anteriormente solo funcionan mientras permanezcan activos un proceso y una ventana de contexto.

Referencias

• ReAct: Sinergizar el razonamiento y la acción en los modelos de lenguaje (Yao et al., 2022) ReWOO: Desacoplamiento del razonamiento de las observaciones para modelos de lenguaje aumentados eficientes (Xu et al., 2023)
• Prompting de tipo “planificar y resolver”: Mejora del razonamiento sin entrenamiento previo Chain-of-Thought mediante modelos de lenguaje grandes (Wang et al., 2023)
• Repositorio de agentes analistas de mercado

El código del agente Analista de Mercado está aquí GitHub Si deseas seguir leyendo al mismo tiempo._

Serie: Ingeniería de la pila Agentic

• Parte 1: AI Bucles de razonamiento de agente en 2026 (esta publicación) Parte 2: AI Arquitectura de memoria de agente en 2026 — checkpoints, almacenes vectoriales y memoria de documentos Parte 3: AI Agente Tool Use en 2026 — MCP, CLI, habilidades, ejecución de código y ACI Parte 4: AI Seguridad de agentes en 2026 — barreras de seguridad, permisos, sandboxes, HITL y delimitación de alcance de MCP
• Parte 5: Agentes AI de ejecución prolongada Runtime en 2026 — sesiones, sandboxes, checkpoints, mecanismos de aprovechamiento y formas de despliegue
• Parte 6: Harness Engineering para agentes AI (próximamente) — comprobaciones de aceptación, trazas, intentos de reintentar, transferencias de control y el ciclo asociado al modelo