[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

AI Agent Reasoning Lussen in 2026: ReAct versus ReWOO versus Plan-en-uitvoeren

Deel 1 van de serie ‘Engineering the Agentic Stack’

Een agent reasoning loop bepaalt hoe een systeem plannen uitvoert, hulpprogramma’s aanroept, resultaten leest en beslist wanneer het moet stoppen. Die controleflow beïnvloedt de kosten, latency, en de herstelcapaciteit wanneer een hulpprogramma onverwachte output retourneert.

In deze post worden de drie belangrijke AI agent loop patronen die in 2026 van belang zijn vergeleken: ReAct, ReWOO en Plan-and-Execute. Het voorbeeld dat wordt gebruikt, is een Market Analyst Agent die ik in LangGraph heb ontwikkeld; de volledige code is te vinden op GitHub.

Dit vormt de binnenste laag van de serie. De latere componenten voegen de staat toe waarvan de lus weer wordt hervat, de hulpmiddelen die kunnen worden opgeroepen, het beleid rondom die oproepen, de runtime die een uitvoering in leven houdt, en de harness controlemechanismen die bepalen of het werk daadwerkelijk voltooid is.

TL;DR: ReAct is flexibel maar duur, ReWOO is snel wanneer de workflow voorspelbaar is, en Plan-and-Execute is geschikt voor meerdere stappen tellende analyses. Een productieomgeving met AI agent kan per verzoek door verschillende reasoning-lussen heen navigeren, door gebruik te maken van gedeelde staat en gecontroleerde LangGraph-nodes, zodat elke taak de lus krijgt die past bij zijn structuur.


De lus controleert de kosten, latency, en het herstelproces

Een bruikbare agent heeft meer nodig dan alleen een goede prompt. Zijn controlegrafiek moet reasoning, hulpprogramma’s en geheugen met elkaar verbinden, terwijl fouten worden afgehandeld.

De reasoning loop bepaalt wanneer de model plannen maakt, een hulpprogramma aanroept, het resultaat leest en stopt. Een slechte keuze zorgt voor onnodige model oproepen en latency. Dit kan er ook toe leiden dat de agent niet in staat is om herstel te bewerkstelligen na een onverwachte tool result.

Drie AI agent reasoning patronen

Reasoning Vergelijking van patronen

ReAct: denken, handelen, observeren, herhalen

ReAct (Yao et al., 2022) vormt het oorspronkelijke patroon voor interactieve agents. Het voert een lus uit:

  1. Gedachte: de agent genereert een “gedachte” om het doel te analyseren en de volgende stap te plannen.
  2. Actie: op basis van deze gedachte roept het een hulpmiddel aan.
  3. Observatie: de agent leest het resultaat, waardoor zijn begrip wordt bijgewerkt voor de volgende gedachte.

ReAct Patroon

Voordelen:

Nadelen:

Ideaal voor: exploratieve taken, foutopsporing, situaties waarin je niet kunt voorspellen wat er vervolgens gaat gebeuren.

ReWOO: plan alles van tevoren

ReWOO (Reasoning Zonder observatie) is een efficiëntere variant van ReAct. Het trucje bestaat erin reasoning los te koppelen van de uitvoering van de tool: in plaats van bij elke actie te stoppen om deze te observeren, plant ReWOO de hele reeks tool calls in één keer.

  1. Plan: één LLM-aanroep schrijft het volledige plan van tool calls, waarbij variabele placeholders worden gebruikt#E1, #E2) voor uitvoer die nog niet bestaat.
  2. Worker: een niet-LLM executor die de geplande hulpprogramma’s sequentieel of parallel uitvoert en zo de placeholders invult.
  3. Solver: een laatste LLM aanroep die de verzamelde observaties verwerkt en het antwoord genereert.

ReWOO-patroon

Voordelen:

Nadelen:

Ideaal voor: snelle snapshots, statuscontroles en dashboards. Alles waarbij de tools zich voorspelbaar gedragen.

Plan-en-uitvoeren: een hybride aanpak

Plan-en-uitvoeren het bevindt zich tussen de twee. Het artikel beschrijft een eenvoudige indeling die de meeste moderne agents hebben overgenomen:

  1. Planning fase: de agent genereert eerst een plan dat de taak opsplitst in kleinere ondertaken.
  2. Uitvoerfase: de agent voert vervolgens die ondertaken uit.

Het oorspronkelijke artikel richtte zich op zero-shot prompting. Moderne frameworks-oplossingen zoals LangGraph hebben dit uitgebreid tot een volledig orchestration-patroon dat rekening houdt met sequentiële uitvoering en keuzes per stap model (een krachtige reasoning model voor planning, en een goedkopere variant voor de uitvoering).

Plan-en-uitvoerpatroon

Voordelen:

Nadelen:

Ideaal voor: complexe meestapige analyses, onderzoekstaakken en alles wat aan het eind synthese vereist.

Kies op basis van waar het plan kan mislukken

FunctieReAct (2022)Plan-and-Execute (2023)ReWOO (2023)
KernfilosofieImproviseerder: handel eerst, en beslis vervolgens wat er daarna moet gebeuren op basis van het resultaat.Architect: maak een volledig ontwerp, voer dit uit en bekijk daarna de resultaten.Optimalisator: schrijf een “script” met variabelen en voer deze allemaal tegelijk uit.
WorkflowIteratieve lus: Denken → Actie → Observatie.Tweefasenproces: Fase 1 (Planning), Fase 2 (uitvoering).Gescheiden: Planner genereert een graaf van tool calls; de workers voeren ze uit.
AnpassingsvermogenHet hoogste niveau: kan na elke tool call de richting veranderen.Medium: plandit doorgaans pas opnieuw na het voltooien van een reeks stappen.Laagst: wordt meestal gevolgd door het initiële script, tenzij de Solver faalt.
EfficiëntieLaag: hoge token-gebruikskracht; de volledige geschiedenis moet voor elke stap opnieuw worden gelezen.Medium: bespaart tokens doordat er tijdens de uitvoering geen heroverweging van het proces plaatsvindt.Hoog: minimaal aantal LLM aanroepen; uitvoering van de tool kan worden geparalleleerd om de snelheid te verhogen.
Bestemd voorOpen einde exploratie of taken waarbij de resultaten onvoorspelbaar zijn.Langdurige taken die een stabiel doel vereisen (bijvoorbeeld het schrijven van een artikel).Gestructureerde, herhaalbare workflows-operaties (bijvoorbeeld het controleren van het weer in 5 steden).

De tabel vormt een uitgangspunt, en niet het benchmark resultaat. Gebruik ReAct wanneer elke observatie de volgende actie kan veranderen. Gebruik de Plan-and-Execute-anpak wanneer de algemene taak kan worden opgedeeld, maar de afzonderlijke stappen nog steeds feedback nodig hebben. Gebruik ReWOO wanneer afhankelijkheden al voor de uitvoering bekend zijn en een mislukte invoer de daaropvolgende oproepen kan stoppen. Meet alle drie de benaderingen in uw eigen hulpmiddelen latency, model, taakset en herprobeerbeleid, voordat u uitsluitend op basis van kosten een keuze maakt.

Een werkvoorbeeld: de Market Analyst Agent

Om dit concreet te maken, heb ik een Marktanalist Agent die alle drie de patronen in één codebase gebruikt voor een marktonderzoekstaak.

Het maakt gebruik van LangGraph voor orchestration. Omdat alle drie de patronen dezelfde state-object delen, kan de router per verzoek bepalen welk patroon moet worden uitgevoerd:

Architectuur voor planning en uitvoering

Definitie van de staat

De gedeelde staat bevat alles wat de agent in alle modi nodig heeft:

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

Patroon 1: Implementatie volgens het plan-en-uitvoeren-model

Plan-and-Execute is de ideale oplossing voor taken die een meervoudige synthese vereisen. Het belangrijkste is om planning en de uitvoering van elkaar te scheiden: eerst een solide model voor het initiële plan, gevolgd door een ReAct-lus om elke stap uit te voeren, waarbij ruimte blijft om react te doen tot tool results.

Hoe dit overeenkomt met het patroon:

  1. Eén voorafgaande planning fase. Één enkele LLM oproep genereert het volledige plan als een lijst met beschrijvingen van de stappen.
  2. Output die wordt geleid door een schema, waardoor het plan vóór uitvoering wordt gevalideerd.
  3. Er vindt nog geen uitvoering van tools plaats. De planner beslist alleen wat er gedaan moet worden, maar niet hoe.
  4. Menselijk leesbare stappen. Elke stap is tekst die door een executor zal worden geïnterpreteerd.
# 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
    }

Dat llm.with_structured_output(PlanOutput) De regel is Schema-gestuurd Reasoning (SGR), wat ik al heb behandeld. een eerdere post. Het schema stelt de applicatie in staat om een ongeldig plan af te wijzen voordat LangGraph de gevalideerde velden gebruikt om conditionele randen te genereren.

Patroon 2: uitvoering van ReAct

Zodra het plan is opgesteld, de executor voert elke stap uit als een afzonderlijke eenheid. ReAct loop. Dit is fase 2: elke stap is voldoende klein zodat een cyclus van Denken-Handelen-Observeren gefocust blijft, en de agent kan react naar wat de tool teruggeeft.

Hoe het ReAct-gedeelte wordt afgestemd:

  1. Iteratieve uitvoering. Eén stap tegelijk, met observatiefeedback.
  2. De Thought-Action-Observation-lus wordt uitgevoerd binnen create_react_agent.
  3. De resultaten van de vorige stap worden als context gebruikt voor de huidige reasoning.
  4. De agent kiest de benodigde hulpmiddelen op basis van de beschrijving van de stap.
  5. Het kan zijn aanpak halverwege een stap aanpassen, afhankelijk van wat een hulpmiddel teruggeeft.
# 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,
    }

Dit is de kern van het Plan-en-Execute-proces: een krachtige model stelt het plan op, waarna ReAct elke stap uitvoert met maximale aanpasbaarheid.

Patroon 3: ReWOO voor snelle snapshots

Voor snelle briefingen negeert ReWOO de gecombineerde reasoning en voert de tools parallel uit. De planner genereert van tevoren een gecompileerd script van tool calls, zodat de worker dit kan uitvoeren zonder verdere betrokkenheid van LLM.

De vorm ervan:

  1. Drie fasen (Planner → Worker → Solver), zonder lussen.
  2. Referentie naar Tool calls #E1, #E2 placeholders voor resultaten die nog niet beschikbaar zijn.
  3. Er is geen LLM tijdens de uitvoering. De worker gebruikt enkel de beschikbare tools.
  4. De afzonderlijke tools worden parallel uitgevoerd.
  5. Aan het eind vindt één syntheseoproep plaats, waarbij alle gegevens tegelijk worden verwerkt.

Fase 1: ReWOO planner (creëert van tevoren de volledige uitvoeringsgraaf)

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: ReWOO worker (voert tools uit zonder LLM reasoning)

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: ReWOO solver (synthetiseert alle resultaten in één LLM aanroep)

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 plant elke tool call van tevoren en slaat de afhankelijkheden op in placeholders zoals #E1 en #E2. De executor kan onafhankelijke aanroepingen parallel uitvoeren, zonder de model te vragen wat er vervolgens moet gebeuren. Een laatste model-aanroep combineert de resultaten, waardoor de voorspelbare kosten van workflows laag blijven.

Waar elk patroon de model aanroept

De drie patronen verschillen in wanneer en hoe ze LLM aanroepen:

PatroonLLM aanroepen tijdens uitvoeringToestandsupdatesBelangrijk codepatroon
Plan-en-Uitvoeren1 voor planning + 1 per stapSequentiële voltooiing van stappenplanner_node() → lus: executor_node()reporter_node()
ReAct (binnen elke stap)Meerdere per stap (denk-handelcyclus)Opgehoopte berichtgeschiedeniscreate_react_agent() loopt intern totdat de stap is voltooid
ReWOO1 voor planning + 0 tijdens uitvoering + 1 voor syntheseParallelle hulpprogramma-completierewoo_planner_node()rewoo_worker_node()rewoo_solver_node()

Wat er tussen hen verschilt, is wat planner genereert. Dat bepaalt alles in de volgende stappen van het proces.

  1. Plan-and-Execute genereert stapbeschrijvingen die door mensen gemakkelijk gelezen kunnen worden:

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

    De executor leest elke beschrijving en beslist welke hulpprogramma’s er moeten worden opgeroepen. Het is flexibel, maar kost een LLM oproep per stap.

  2. ReAct beschikt niet over een vooraf vastgesteld plan. Het maakt gebruik van iteratieve reasoning:

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

    Meerdere aanroepen van LLM per stap passen zich aan aan de waarnemingen en kosten doorgaans meer dan de twee geplande modi.

  3. ReWOO genereert expliciete, uitvoerbare tool call specificaties:

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

    De worker draait blind, zonder enige LLM-invloed. Alle model-aanroepen vinden plaats binnen de planner en de solver, waardoor het aantal model-aanroepen voorspelbaar is.

Geheugen- en toestandsstroom:

Alles samenbrengen: het netwerk aansluiten

Hieronder zie je hoe de drie patronen samen bestaan binnen één LangGraph-systeem. Ze delen één AgentState en bevinden zich in één enkele graaf. Een router kiest voor elk verzoek de juiste route, zodat dit één agent is met drie uitvoeringsmodi, in plaats van drie agents die apart functioneren.

LangGraph houdt de configuratie declaratief:

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
    )

Automatische patroonselectie met router

Om de juiste lus te kiezen voor elke aanvraag, heb ik een router-classifier toegevoegd. Deze maakt gebruik van Schema-Guided Reasoning om de classificatie betrouwbaar te houden:

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)

Nu dit is geïmplementeerd, hoeven gebruikers geen modus meer te kiezen. De router stuurt “huidige prijs” automatisch door naar ReWOO en “beleggingsthese” naar Plan-and-Execute.

Belangrijkste conclusies

  1. ReAct biedt de meest frequente feedbackpunten, ten koste van herhaalde model oproepen.
  2. ReWOO vermindert model heen-en-weerreizen wanneer de tools betrouwbaar zijn en de afhankelijkheden voorspelbaar.
  3. Plan-and-Execute is geschikt voor complexe analyses die vóór uitvoering kunnen worden opgesplitst, maar toch stapsgewijs feedback vereisen.
  4. Een router kan per verzoek kiezen tussen deze methoden, zodat gebruikers dit niet zelf hoeven te doen.
  5. De lus heeft opgeslagen staat nodig om een onderbreking of herstart van een worker te overleven. Dit is het onderwerp van Deel 2.

De volledige implementatie, inclusief de router en de gedeelde staat, bevindt zich in de Marktanalist Agent repository.

De volgende laag is het geheugen

Deel 2, AI Agent Memory Architectuur in 2026, Het scheidt de herstartbare checkpoints van de kennis en projectdocumenten die zich op een cross-session niveau bevinden. Zonder deze state-laag werken de hierboven genoemde router en executor alleen wanneer er maar één proces en één context window actief zijn.

Referenties


de code van de Market Analyst Agent is beschikbaar GitHub indien u wilt meelezen.

Reeks: Het ontwerpen van de Agentic-stack