Module 3 of 11 · Expert · 11 min read

Agent loops: plan, act, observe (ReAct)

How agents interleave reasoning with actions, how to brief one well, and the plan-and-execute variant.

Key takeaways

1ReAct (Yao et al., 2022) interleaves reasoning steps with actions and observations.
2Tool calling implements this loop natively: the model requests a tool, your code runs it, the result comes back.
3Brief an agent with the goal, the tools, the definition of done, and when to stop or ask.
4Plan-and-execute separates a planning step from the action loop for long tasks.

01The loop at the heart of every agent

An agent is a model in a loop: it looks at the goal and what it knows, decides on an action, takes it, observes the result, and repeats until the goal is met. ReAct (Yao et al., 2022) formalised this as interleaved Thought, Action and Observation steps. The paper showed that combining reasoning with actions such as search lookups reduced hallucination and improved results on question answering and interactive tasks, compared with reasoning alone or acting alone.

Example

Thought: I need the current return policy before answering. Action: search_help_center("return policy electronics") Observation: "Unopened electronics can be returned within the period on the receipt..." Thought: The customer says the box is opened, so I should check the policy for faulty items. Action: search_help_center("faulty electronics return") Observation: ... Thought: I have enough to answer. Final answer: ...

02How it works with tool calling today

You rarely need to make a model write Thought, Action and Observation text any more. Current APIs let you define tools; the model returns a structured tool call, your code runs it, and you send the result back. The loop continues until the model replies without a tool call. Reasoning models often do their thinking internally between calls.

What you still control is the brief, the tools, the stopping rules and what happens when something goes wrong.

03Writing an agent brief

The Long-horizon task briefs technique on the Prompting hub covers the same ground for very long runs.

Goal: the end state, not the steps.
Definition of done: how the agent knows it has finished, ideally something checkable.
Tools and when to use them, especially which to prefer and which are expensive or risky.
Constraints: what it must not change, spend or access.
Stop and ask: the situations where it should pause for a person.
Reporting: what to return at the end, including what it could not do.

Example

Goal: produce a one-page comparison of the three project-management tools in <candidates> for a 12-person design studio. Done when: each tool has current pricing for our team size, the three features in <needs> are checked against official documentation, and every claim links to its source. Tools: use web_search and fetch_page. Prefer each vendor's own pricing and docs pages over review sites. Constraints: do not sign up for trials or enter any personal details. Stop and ask if pricing is only available by contacting sales, or if sources conflict. Return: the comparison table, a two-sentence recommendation, and a list of anything you could not verify.

04Plan-and-execute

On long tasks, a pure step-by-step loop can wander. A common variant asks the model first to write a plan (a numbered list of sub-goals), then works through each sub-goal with its own action loop, updating the plan when observations show it was wrong. Keeping the plan in state, or in a file the agent re-reads, keeps the run on track.

Tip

Ask the agent to re-read the goal and plan at the start of each major step. It is a cheap, effective defence against drift on long runs.

05Observations are untrusted

Everything that comes back from a tool, especially web pages, emails and documents, may contain errors or injected instructions. Tell the agent to treat observations as data, keep high-risk actions behind human confirmation, and give it only the permissions it needs. See the safety module in Advanced Prompting.

06Pitfalls

Most agent failures are not intelligence failures. They are unclear goals, weak tools or missing stop rules.

Looping on the same failing action: detect repeats and force a different approach, or stop.
Premature 'done': define completion in checkable terms and verify it in code where possible.
Tool misuse: vague tool descriptions lead to wrong calls. Describe parameters and failure modes clearly.
Context overflow: long runs fill the context with old observations. Summarise or prune them.