Chapter 9: Understanding the agentic loop
The introduction distinguishes the familiar internal SPAL loop from broader agentic looping used for long-horizon goals and multi-agent collaboration.
After this chapter you will be able to
- Internal and extended agentic loops. Distinguish the internal SPAL loop from looping patterns that extend outside an agent, and explain why those broader patterns matter for goal-driven agents.
- Three agentic loop layers. Describe the internal SPAL loop as an agent’s core layer, which lets it iterate, discover, reason, and execute tasks toward goals, and identify the task loop and meta loop as two further layers that extend its work.
- Inner loop sequence. Trace how the level-1 loop starts with a goal, senses its current state, plans and takes an action with tools, evaluates the result, updates its state, and repeats if the goal has not been met.
- Agent driven iteration. Distinguish the agent’s decisions during the loop from the developer’s setup of the goal, tools, and boundaries.
- External task loop purpose. Explain how layer 2 moves goal, plan, state, and decision outside the agent so it can work toward long-horizon goals across multiple short-horizon cycles.
- Meta loop control. Explain that a meta-agentic loop uses an agent or agents to control internal layer-1 or layer-2 processes, unlike a layer-2 loop, which is often directed by code.
- Orchestration and collaboration forms. Distinguish orchestration from collaboration by where the deciding agent sits: a single delegating agent contains the decide, state, and plan elements in orchestration, whereas decision agents become part of the loop in collaboration.
- Reliable loop control factors. Explain why managing state between iterations, defining termination conditions, and connecting external tools distinguish a productive loop from one that consumes tokens without progress.
- External loop control architecture. Describe how code outside the agent controls the deep research workflow, beginning with a long-horizon goal and creating, updating, or checking state and plan objects.
- Shared research state and plan. Describe how ResearchState and ResearchPlan persist outside the agent’s execution and are shared across iterations. Explain that the state accumulates information while the plan holds a strategy that is updated from observations.
- Selective agent context. Explain how to_context turns accumulated state and plan into a dictionary string the agent can consume, and why controlling that context helps manage the context window and maintain focus.
- Research agent search setup. Describe when the research agent's tools are set up and how the example connects it to search.
- Iteration body and state updates. Trace how an iteration uses the current state and plan as context for a Runner.run() call, then parses the agent’s output to update the state.
- Structured iteration control signals. Explain why ResearchIteration uses strongly typed output and describe how its fields inform the loop controller about findings, next steps, and completion.
- Layered termination decisions. Explain that the termination gate runs at the end of each iteration and combines defensive limits, goal and quality checks, and stagnation detection rather than relying on a single stop condition.
- Defensive production limits. Justify setting both a maximum iteration count and a token or cost ceiling, even when the agent appears capable of deciding when to stop.
- Detecting stalled progress. Distinguish stagnation from obvious failure and describe how comparing consecutive iteration summaries can trigger an exit.
- Recent findings context limit. Explain why to_context passes only the last five findings to the agent and what tradeoff that makes.
- Follow-up question ordering. Distinguish how popping follow-up questions from the front versus the end changes the loop’s exploration pattern.
- Separate research and synthesis roles. Explain why a separate synthesis agent compiles the report after the research loop rather than having the research agent write it during its last iteration.
- Synthesis inputs and report caveats. Describe what the synthesis agent receives and how those inputs affect the final report.
- Discovery and refinement tasks. Explain why a loop suits tasks that discover needed information or sources during execution, or improve an output through repeated drafts.
- Queued and conditional work. Describe how a queue of items or a next action that depends on the previous result can justify an agentic loop.
- Single-pass loop avoidance. Explain when to avoid an agentic loop and what unnecessary iteration costs.
- Repetitive task loop workflow. Describe how a repetitive task agent works through a defined queue, processing one item per iteration, tracking progress, and stopping when the queue is empty or another termination condition is met. Distinguish this pattern from a research agent’s exploration.
- External state without planning. Explain where the task loop keeps its state and decision flow, and why this variation does not need an external plan.
- Orchestrator control and delegation. Explain how a layer-3 orchestrator controls the plan, state, and decisions while delegating individual tasks to specialized worker agents and evaluating their results.
- Adaptive replanning from worker results. Describe how worker findings can cause the orchestrator to revise its plan during the loop.
- Collaborative loop structure. Describe how peer agents take turns contributing to shared work and collectively decide when the goal is met, without a single orchestrator directing the content.
- Researcher critic synthesizer roles. Explain how a researcher, critic, and synthesizer use the shared state to improve an output across rounds.
- Collaboration versus orchestration choice. Distinguish when to use collaboration rather than orchestration, including what to try when the choice is uncertain.
What it builds on
- Thinking like agents: Sense-plan-act-learn (chapter 1) · Introduces the sense-plan-act-learn pattern.
- Using MCP servers for agents (chapter 3) · using MCP servers with agents
Section by section
Introduction
The introduction distinguishes the familiar internal SPAL loop from broader agentic looping used for long-horizon goals and multi-agent collaboration.
- Internal and extended agentic loops: Distinguish the internal SPAL loop from looping patterns that extend outside an agent, and explain why those broader patterns matter for goal-driven agents.
Why it matters: This distinction sets up why the chapter looks beyond an individual agent’s familiar loop.
Key terms: SPAL, sense-plan-act-learn, internal agent loop, agentic looping, long-horizon, goal-driven agents
9.1 Peeling back the three agentic loop layers
Introduces the internal SPAL loop as an agent’s core layer and identifies the task and meta loops as two layers that extend its work.
- Three agentic loop layers: Describe the internal SPAL loop as an agent’s core layer, which lets it iterate, discover, reason, and execute tasks toward goals, and identify the task loop and meta loop as two further layers that extend its work.
Why it matters: This gives you a basic map of the three layers before the book explains each one.
Key terms: internal loop, SPAL, task loop, meta loop
9.1.1 Layer 1: The inner loop (sense-plan-act-learn)
This section explains how an agent’s inner loop cycles through sensing, planning, acting, evaluating, and deciding whether to continue.
- Inner loop sequence: Trace how the level-1 loop starts with a goal, senses its current state, plans and takes an action with tools, evaluates the result, updates its state, and repeats if the goal has not been met.
Why it matters: The sequence shows how one action’s result informs the agent’s next decision. - Agent driven iteration: Distinguish the agent’s decisions during the loop from the developer’s setup of the goal, tools, and boundaries.
Why it matters: This distinction explains why the cycle is more than a developer-scripted while loop. - Core loop elements: Explain the roles of the goal, plan, tools, internal state, and stopping decision in the level-1 loop, and why the decision matters.
Why it matters: These roles clarify what the inner loop needs to make progress and stop appropriately.
Key terms: level-1 agentic loop, internal state, termination condition, agentic, while loop, boundaries, goal, plan, tool, state
9.1.2 Layer 2: The task loop
This section explains how an external task loop lets one agent pursue long-horizon goals by keeping plans and state beyond its short-lived internal cycle.
- External task loop purpose: Explain how layer 2 moves goal, plan, state, and decision outside the agent so it can work toward long-horizon goals across multiple short-horizon cycles.
Why it matters: It explains how one agent can make progress on a goal that outlasts any single internal cycle. - Reasons for external persistence: Justify why the system persists plans and state externally rather than relying on a general-purpose LLM for a long-running task.
Why it matters: These limitations explain why a long task needs more than a longer sequence of internal agent cycles. - Programmatic outer loop: Describe the general character of layer-2 mechanisms and the roles of code and the agent within that wrapper.
Why it matters: It distinguishes an outer loop that coordinates the agent from another long-running thought process inside the agent.
Key terms: layer-2 agentic loop, goal-plan-state-decision, short-horizon goals, long-horizon goals, context window, long-running iterations, externalizing the agent’s plan and state, programmatic, deterministic constructs, decision, tool
9.1.3 Layer 3: The meta loop
This section defines the agent-controlled meta loop and distinguishes its orchestration and collaboration forms.
- Meta loop control: Explain that a meta-agentic loop uses an agent or agents to control internal layer-1 or layer-2 processes, unlike a layer-2 loop, which is often directed by code.
Why it matters: The controlling agent is what makes this a meta loop rather than just another task loop. - Orchestration and collaboration forms: Distinguish orchestration from collaboration by where the deciding agent sits: a single delegating agent contains the decide, state, and plan elements in orchestration, whereas decision agents become part of the loop in collaboration.
Why it matters: The distinction helps you recognize whether subagents serve one delegating agent or participate in the decision loop.
Key terms: meta-agentic loop, layer-1, layer-2, meta layer, orchestration-controlled meta loop, collaboration of agents, delegating agent, delegation subagents, decide, state, and plan
9.2 Layer 2: Looping with a deep research agent
This section introduces deep research as a layer-2 agentic loop and explains why external control of state, tools, and stopping decisions matters.
- Deep research loop purpose: Describe a deep research agent as a layer-2 agentic loop that searches extensively to pursue a longer-horizon, in-depth research goal.
Why it matters: It clarifies the kind of task this loop is meant to handle. - Reliable loop control factors: Explain why managing state between iterations, defining termination conditions, and connecting external tools distinguish a productive loop from one that consumes tokens without progress.
Why it matters: These controls help prevent repeated work and runaway token costs. - External loop control architecture: Describe how code outside the agent controls the deep research workflow, beginning with a long-horizon goal and creating, updating, or checking state and plan objects.
Why it matters: It locates control of the loop in the surrounding workflow rather than entirely inside the agent.
Key terms: deep research agent, layer-2 agentic loop, longer-horizon, state between iterations, termination conditions, external tools, runaway cost generator, code external to the agent, state, plan objects
9.2.1 Creating the initial state and plan
This section introduces the shared research state and plan used across loop iterations and explains how to pass selected parts of them to the agent.
- Shared research state and plan: Describe how ResearchState and ResearchPlan persist outside the agent’s execution and are shared across iterations. Explain that the state accumulates information while the plan holds a strategy that is updated from observations.
Why it matters: Shared state and an evolving plan let successive research iterations build on what came before. - Selective agent context: Explain how to_context turns accumulated state and plan into a dictionary string the agent can consume, and why controlling that context helps manage the context window and maintain focus.
Why it matters: Passing a focused view of accumulated research prevents earlier findings from crowding the agent’s context.
Key terms: ResearchState, ResearchPlan, external state, shared memory, to_context, context window
9.2.2 Adding the tools
This section describes setting up search tools for a research agent and notes that the agent can use other MCP services and tool sources.
- Research agent search setup: Describe when the research agent's tools are set up and how the example connects it to search.
Why it matters: The research agent needs its search connection configured before it can use that source. - Tool source flexibility: Explain why the example's single search source does not limit the tools a research agent can use.
Why it matters: The example's one search connection is not a restriction on the agent's possible sources or tasks.
Key terms: STDIO, MCP server, Brave Search, BRAVE_API_KEY, .env file, tools, MCP server sources, search, analysis, aggregation
9.2.3 Understanding iteration body output
This section explains how each research-agent iteration produces structured output that updates loop state and helps determine whether another iteration is needed.
- Iteration body and state updates: Trace how an iteration uses the current state and plan as context for a Runner.run() call, then parses the agent’s output to update the state.
Why it matters: This connects an agent’s work in one cycle to the state used by the loop. - Structured iteration control signals: Explain why ResearchIteration uses strongly typed output and describe how its fields inform the loop controller about findings, next steps, and completion.
Why it matters: Reliable fields give the controller usable signals for continuing or ending research. - SDK managed output typing: Describe how the Agents SDK handles a strongly typed output format without requiring it to be spelled out in the agent instructions.
Why it matters: Keeping output typing with the SDK avoids unnecessary instruction changes as the model evolves.
Key terms: iteration body, Runner.run(), state/plan, ResearchIteration, strongly typed output, loop controller, follow_up_questions, goal_satisfied, subtopic updates, Agents SDK
9.2.4 The termination gate
Explains how a termination gate uses layered conditions to decide whether a research-agent loop should continue or stop.
- Layered termination decisions: Explain that the termination gate runs at the end of each iteration and combines defensive limits, goal and quality checks, and stagnation detection rather than relying on a single stop condition.
Why it matters: Different stopping conditions catch different reasons a loop should end. - Defensive production limits: Justify setting both a maximum iteration count and a token or cost ceiling, even when the agent appears capable of deciding when to stop.
Why it matters: Explicit ceilings prevent an unproductive loop from becoming an open-ended production cost and latency problem. - Detecting stalled progress: Distinguish stagnation from obvious failure and describe how comparing consecutive iteration summaries can trigger an exit.
Why it matters: A loop can look productive while merely repeating itself, so it needs a way to stop when further iterations add no value.
Key terms: termination gate, hard limit, budget limit, goal satisfaction, quality threshold, stagnation detection, maximum iteration count, cost ceiling, tokens, latency
9.2.5 Coding the deep research loop
This section assembles the deep research loop and explains three design choices: limiting findings in context, ordering follow-up questions, and cleaning up the MCP server.
- Research loop assembly: Describe the components brought together in the deep research loop and what the agent instructions establish, without claiming that this code produces the formatted report.
Why it matters: It clarifies what this loop handles and where report generation begins. - Recent findings context limit: Explain why to_context passes only the last five findings to the agent and what tradeoff that makes.
Why it matters: A research loop must leave context-window space for the agent’s reasoning and tool results. - Follow-up question ordering: Distinguish how popping follow-up questions from the front versus the end changes the loop’s exploration pattern.
Why it matters: A small change in question ordering changes how the research explores possible directions. - MCP server lifecycle: Explain why the research loop connects to its MCP server inside an async context manager.
Why it matters: Reliable cleanup prevents one research run from interfering with the next.
Key terms: loop controller, agent instructions, plan, state, stop condition, to_context, findings, context window, follow_up_questions, breadth-first exploration
9.2.6 Synthesizing the final output
The section explains how a separate synthesis agent turns a completed research loop’s findings into a report.
- Separate research and synthesis roles: Explain why a separate synthesis agent compiles the report after the research loop rather than having the research agent write it during its last iteration.
Why it matters: Separating the jobs lets the research agent focus on discovery and the synthesis agent focus on a coherent report. - Synthesis inputs and report caveats: Describe what the synthesis agent receives and how those inputs affect the final report.
Why it matters: The report can draw on the complete research record and accurately signal when the research was cut short.
Key terms: research agent, synthesis agent, separation of concerns, findings, all findings, final status, context window pressure, caveat
9.2.7 When to use an agentic loop
This section gives criteria for deciding when an agentic loop helps and when a single pass is better.
- Discovery and refinement tasks: Explain why a loop suits tasks that discover needed information or sources during execution, or improve an output through repeated drafts.
Why it matters: These are signs that another pass can add information or improve the result. - Queued and conditional work: Describe how a queue of items or a next action that depends on the previous result can justify an agentic loop.
Why it matters: Repetition can be useful even when the task is not research or drafting. - Single-pass loop avoidance: Explain when to avoid an agentic loop and what unnecessary iteration costs.
Why it matters: Avoiding an unnecessary loop keeps a straightforward task faster and cheaper.
Key terms: iterative discovery, progressive refinement, multisource aggregation, batch processing, conditional branching, single pass, latency, cost
9.2.8 Building a repetitive task loop agent
This section explains how a repetitive task loop processes a defined queue and why it does not need an external plan.
- Repetitive task loop workflow: Describe how a repetitive task agent works through a defined queue, processing one item per iteration, tracking progress, and stopping when the queue is empty or another termination condition is met. Distinguish this pattern from a research agent’s exploration.
Why it matters: This pattern fits jobs made up of many similar, known items. - External state without planning: Explain where the task loop keeps its state and decision flow, and why this variation does not need an external plan.
Why it matters: A predefined queue provides the order of work without a separate plan.
Key terms: repetitive task completion, task queue, progress tracker, termination condition, state, decision flow, external plan
9.3 Layer 3: Multi-agent orchestration loops
This section explains how an LLM-driven orchestrator manages a multi-agent loop, why it can adapt its plan, and when its extra cost is justified.
- Orchestrator control and delegation: Explain how a layer-3 orchestrator controls the plan, state, and decisions while delegating individual tasks to specialized worker agents and evaluating their results.
Why it matters: It clarifies which decisions belong to the orchestrator and which work belongs to its agents. - Adaptive replanning from worker results: Describe how worker findings can cause the orchestrator to revise its plan during the loop.
Why it matters: Replanning is the advantage of the meta loop when the right set of tasks is not known at the start. - Orchestration cost tradeoff: Justify when to use an orchestrator rather than a layer-2 loop with hardcoded task dispatch.
Why it matters: The flexibility of an orchestrator is worth paying for only when the task needs it.
Key terms: layer-3 meta loop, orchestrator agent, worker agents, handoff mechanism, global plan and state, dynamically replan, subtasks, decomposition, worker’s findings, orchestrator overhead
9.4 Building collaborative agentic loops
This section explains how peer agents collaborate through shared state and review, and when that pattern is preferable to orchestration.
- Collaborative loop structure: Describe how peer agents take turns contributing to shared work and collectively decide when the goal is met, without a single orchestrator directing the content.
Why it matters: This distinguishes collaboration from a loop in which one agent delegates and controls the work. - Researcher critic synthesizer roles: Explain how a researcher, critic, and synthesizer use the shared state to improve an output across rounds.
Why it matters: The roles show why adversarial review can improve work that a lone agent might leave insufficiently checked. - Nested self revision option: Describe how a collaborative loop can let an agent revise its own work before passing it to a critic.
Why it matters: Collaboration need not require every contribution to pass immediately to a different agent for critique. - Collaboration versus orchestration choice: Distinguish when to use collaboration rather than orchestration, including what to try when the choice is uncertain.
Why it matters: Choosing the simpler pattern first avoids collaboration overhead unless cross-review improves the result.
Key terms: layer-3 meta loop, collaboration loop, shared state, turn manager, researcher-critic-synthesizer triad, adversarial validation, layer-2 agent loop, layer-3 collaboration meta loop, critic agent, orchestration
9.5 Exercises
Six exercises ask the reader to build and compare research, task, orchestration, and collaboration loops.
9.6 Summary
Summarizes how to design a goal-directed agentic loop, control its iterations safely, and apply it to research and repetitive tasks.
Where this is used later
- Architecture overview (chapter 10) · Introduces agentic loops as a framework for iteration.
- (chapter intro) (chapter 10) · The task loop provides the earlier iteration capability mentioned here.
- Tips for building a deep research agent system (chapter 11) · The earlier deep research loop provides context for repeating research when the current results are insufficient.
- Summary (chapter 11) · Introduces a deep research agent loop.
- The five failure modes of capable-but-not-cognitive agents (chapter 10) · The agentic loop that iterates through a task.
Concepts explained in this chapter
- ReActReAct is an agent reasoning technique that interleaves verbal reasoning with tool actions and observations in a feedback loop.
- stopping criterionA stop condition is a rule that determines when an iterative agent process must terminate.
- stagnationStagnation detection is the identification of repeated iterations whose outputs do not meaningfully change.
- task loopA task loop is a repeated sequence of task execution attempts that continues until a completion condition or stopping condition is reached.
- meta loopA meta loop is an agent-controlled runtime loop in which an agent manages decisions, state, planning, delegation, and continuation across subtasks.
- collaboration patternA reusable design in which multiple peer agents share state, contribute to a task, critique or refine one another's work, and collectively determine completion.
- agent orchestrationAn orchestrator is an agent that maintains a plan, delegates subtasks to worker agents, evaluates their results, and decides how execution continues.
- workerA worker agent is an agent specialized in performing delegated tasks or a defined set of tools for an orchestrator.
- asyncio.gatherA Python asyncio function that concurrently schedules awaitable objects and returns their results together.
- parallelismThe concurrent execution of independent workloads or subtasks to reduce elapsed processing time.
- retryA retry is a repeated attempt to perform an API operation after an earlier attempt fails or does not complete successfully.
- iteration limitA fixed maximum number of iterations that an iterative agent process may execute.
- context window managementContext window management is the architectural practice of controlling which conversation, tool, retrieval, and shared-state information is included within a model's context window.
- deep research agentA deep research agent is an AI agent designed to conduct multi-step information gathering, analysis, and synthesis over an extended task horizon.
- structured dataData organized according to an explicit format or schema that makes its contents and relationships readily evaluable.
- function_tool decoratorA decorator or helper that exposes a programming-language function as an agent-callable tool and generates its structured tool description.
- shared state objectA data object containing information that multiple agents can read and update during collaborative execution.
- MCP serverAn MCP server is a service that exposes tools, prompts, and resources to AI applications through the Model Context Protocol.
- decompositionDecomposition is the process of dividing a complex whole into smaller constituent parts that can be handled or analyzed separately.
- toolA tool is an instrument or software capability that enables a person or system to perform a task, obtain information, or interact with resources.
- MCPServerStdioMCPServerStdio is a class that runs an MCP server locally through standard input and output while managing its subprocess lifecycle.
- PydanticPydantic is a Python library for defining typed data models and validating, parsing, and serializing data.
- actionAn action is an operation an AI agent performs that can affect its environment or internal state.
- separation of concernsSeparation of concerns is a software design technique that isolates distinct responsibilities so they can be developed and changed independently.
- state persistencePersistence is the continuation of a system's goal-directed operation across multiple steps or interactions.
- continuous improvementAn iterative improvement process in which an output is revised or enhanced across successive iterations.
- evaluatorLLM-as-judge is an evaluation technique in which a language model assesses another model's output against specified criteria.
← Chapter 8: Deploying agents and agentic systems
Chapter 10: Exploring the cognitive agent that thinks, monitors, and adapts →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.