The plan, act, observe, reflect loop

By the end, you can

• Explain the plan, act, observe and reflect cycle and identify when each step should invoke a human gate (LA-11 O1).
• Distinguish single-agent orchestration from agentic prompting, and say why a fixed prompt chain is not an agent (LA-11 O3).

Before you start

This is the first lesson of Local AI Agents: Advanced, and it assumes you have completed Local AI Agents (LH-01). In particular it builds on that course's bounded-agent vocabulary, its tool-loop lab, and its stop-rules lesson — the difference between an action an agent may take automatically and one that is approval-required is used here without re-teaching it. This lesson does not run a model. It sets up the loop that the next two lessons bound with budgets and terminate with stop rules, and it draws the line between an agent and a prompt chain that only looks like one.

A prompt chain is not an agent

It is easy to build something that calls a model several times in a row — summarise, then classify, then draft a reply — and call the result an agent. It usually is not one. The distinction is not about how many model calls there are; it is about who decides the sequence.

Anthropic's engineering guidance draws the line precisely: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." A summarise-then-classify-then-draft chain has its steps fixed in advance by the author's code. The model fills in each step, but it never chooses what the next step is. That is a workflow, and workflows are often the right tool — they are more predictable and easier to test than an agent.

An agent is the case where that control moves to the model at run time. The same guidance describes it plainly: "Agents are typically just LLMs using tools based on environmental feedback in a loop." The two load-bearing words are *feedback* and *loop*. The model acts, sees what happened, and decides the next action from that observation rather than from a script — and it keeps doing so until some condition ends the loop. Single-agent orchestration is the design of that loop: one model, driving its own next step, inside boundaries you set.

The four steps: plan, act, observe, reflect

The loop is easiest to reason about as four named steps that repeat. The naming here follows the reasoning-and-acting pattern set out in the ReAct paper, which interleaves the model's reasoning with its actions rather than treating them as separate phases.

Plan and reflect are both reasoning; act and observe are both contact with the outside world. Interleaving them — rather than planning the whole task once and then executing blindly — is exactly what lets an agent recover when the world does not match the plan.

• Plan. The model states, in the open, what it intends to do next and why. In ReAct's framing, these reasoning traces let the model "induce, track, and update action plans as well as handle exceptions." A plan is not a fixed script for the whole task; it is the model's current best next move, revisable the moment an observation contradicts it.
• Act. The model takes exactly one concrete action — a single tool call, a single query. Actions are what let the model, in the paper's words, "interface with external sources, such as knowledge bases or environments, to gather additional information." An action is the only step that changes anything or learns anything new.
• Observe. The action's result comes back — the tool output, the error, the empty set — and becomes part of what the model sees on the next turn. This is the *environmental feedback* that separates an agent from a chain: the next plan is written against this result, not against an assumption made before the run.
• Reflect. The model reads the observation against the goal and the boundaries and decides what the loop does next: continue with an adjusted plan, stop because the task is done, or stop because it cannot safely continue. Reflection is where the loop's exits live, and it is the step the next two lessons build stop rules and budgets into.

Where each step meets a human gate

A human gate is a point where the loop pauses and hands control to a person before proceeding. LH-01 established which actions are approval-required; this lesson places those gates onto the loop's four steps, because each step can invoke one for a different reason.

Not every task gates at every step — a fully read-only research loop may gate at none. The point is that the gate is a property of the step and the classification, decided before the run, not a reaction the model improvises when it happens to feel unsure.

• At plan. The model's stated next move is out-of-scope or approval-required under the task's classification. The gate fires before the action, not after — the point of gating at plan time is that the risky thing has not happened yet.
• At act. Even an in-scope action can carry a side effect that policy always reviews — a filesystem write, a shell command, a network call to a new host. The gate here is on the *kind* of action, independent of the model's confidence that it is correct.
• At observe. The result reveals something that changes the task's risk: a document that turns out to contain sensitive data, a tool that returned far more than expected. A person decides whether the run should continue now that the ground has shifted.
• At reflect. The model concludes the task is done, or concludes it must stop. Completion of a consequential task, and any stop that needs a human to pick up the pieces, both belong to a person rather than to the model's own sign-off.

Why the loop is not just a longer prompt

The reason to build the loop at all — rather than write one very detailed prompt — is recovery. A single long prompt commits to a plan before it has seen anything. The moment reality diverges (a source is empty, a format changed, a search returned nothing), that plan has no way to notice: it produces an answer built on an assumption that the run itself already disproved. The loop's observe-and-reflect steps are the structural fix. Because each action's result is fed back before the next plan, a broken assumption surfaces as an observation the model must account for, instead of a silent error that rides through to the output.

That same autonomy is also the loop's cost, and it is why the rest of this module exists. Anthropic's guidance is direct about the trade-off: "The autonomous nature of agents means higher costs, and the potential for compounding errors." A loop that can adapt can also loop uselessly, spend without bound, or compound one wrong step into several. Building the loop is Lesson 1; bounding it so those failure modes cannot run away is Lessons 2 and 3.

A worked example: the loop over a bounded local task

Take a bounded task from LH-01's world: summarise this week's support tickets from a local export file, using a model running on your own machine.

Written as a fixed chain — read, then summarise, always — the zero-row case produces a confident summary of nothing. Written as a loop, the empty observation reaches a reflect step that can choose to stop. Same model, same tool: the difference is entirely in who decides the next step.

• Plan: "Read the export for the target week, then summarise the themes." Stated before acting.
• Act: one call to the file-reading tool for that week's file.
• Observe: the tool returns the rows — or returns zero rows, or an error.
• Reflect: if rows came back, plan the summary and continue; if zero rows came back, stop and hand back rather than summarising nothing and calling it done — the empty result is exactly the kind of exception the reflect step exists to catch.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The reference automations in the exercise are described in prose rather than shown as diagrams, so nothing depends on seeing an image. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and announced by screen readers, and the knowledge check uses native radio-button inputs with a visible question and options, posting its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Building effective agents — Anthropic Engineering. Distinguishes workflows (LLMs and tools orchestrated through predefined code paths) from agents (LLMs that dynamically direct their own processes and tool usage), and describes an agent as typically an LLM using tools based on environmental feedback in a loop.
2. ReAct: Synergizing Reasoning and Acting in Language Models — Shunyu Yao and colleagues. Interleaves reasoning traces and task-specific actions so that reasoning traces induce, track and update action plans and handle exceptions, while actions interface with external sources to gather additional information.