A Practical Guide, Part 2 of 15: The Agent Loop: Perceive, Plan, Act, Reflect

Host: Exactly. Goal, tools, loop. Today is all about that third word, and the question running through the episode is simple: who is actually doing what, and how does the thing know when it's done?

Host: Picture a support agent asked to change a customer's flight. It doesn't know the booking, so it has to look it up. Let's follow that request, step by step.

Co-host: And the honest answer is it's way less mystical than people think. You send the model a message plus a list of tools it may use. A tool is just a described function, like look up booking or change seat.

Host: And here's the bit that surprises people. The model never runs the tool itself. It writes out a structured request, and your code, or Anthropic's servers, actually performs the operation and hands the result back.

Co-host: Right, the model is the one filling out the form. Somebody else has to walk it down to the office.

Host: So how does the cycle know when to stop? Anthropic's documentation describes the standard agent loop as a plain while loop that checks something called the stop reason, a short label the model attaches to say why it stopped writing. While that label says tool use, your code runs the tool and continues the conversation.

Co-host: So in our flight example: model asks to look up the booking, stop reason is tool use. My code queries the database, sends back the booking. Model asks to change the seat, same again. Then it writes a normal answer to the customer, the stop reason changes, and the loop exits.

Host: Which tells you where the responsibility sits. The model proposes; your code disposes.

Co-host: And that's a trade-off worth naming. Every round trip costs time and money, and every result you send back takes up room in the context window, which is the amount of text the model can hold in view at once. Long loops get expensive and cluttered.

Host: So what it means for you: if an agent did something it shouldn't, look at your own code first. The model only asked; something you built said yes.

Co-host: Okay, so that's the plumbing. But the plumbing doesn't tell the model how to think inside the loop.

Host: That's where a research pattern called ReAct comes in. Imagine a quiz question that needs two facts from two different places. A model answering from memory alone might confidently make up the second fact.

Co-host: Which is what we call hallucination: the model producing something fluent and plausible that just isn't true.

Host: ReAct has the model alternate. It writes a reasoning trace, then an action, then reads what came back, then reasons again. The traces help it keep track of its plan and update it, and the actions fetch information it doesn't have.

Co-host: Thought, action, observation, repeat. It's basically our while loop with the model narrating its intentions out loud.

Host: And the reported result is striking. On two question answering and fact checking tests, HotpotQA and Fever, the authors say ReAct overcame the hallucination and error snowballing common in chain-of-thought reasoning, just by giving the model a simple Wikipedia lookup.

Co-host: Chain of thought being where the model reasons step by step in text but never checks anything outside its own head. One early mistake, and every step after inherits it.

Host: Steelman it, and the case is strong: grounding each step in a real lookup is a sensible fix for confident guessing. Test it, and remember this is the paper's own reported result on specific benchmarks, and the agent is only as good as the source it looks things up in.

Host: In practice: when you design an agent, give it a way to check facts rather than recall them, and let it write down its plan between steps so you can read where it went wrong.

Co-host: So now the agent can act and observe. But what happens when it fails the whole task?

Host: Think of a junior developer whose code fails the tests. A good one writes a note: I forgot the empty list case. Next attempt, they read the note first. The Reflexion paper does roughly that with a model.

Host: After feedback, the agent writes a verbal reflection and stores that text in what the authors call an episodic memory buffer, a running log of past attempts, so later tries make better decisions. Crucially, without changing the model's weights.

Co-host: Weights being the billions of numbers learned in training that make the model what it is. Changing them is fine-tuning, which is slow and costly. Reflexion just changes what's in the notebook.

Host: And the headline: on the HumanEval coding benchmark it reports 91 percent pass at one, meaning the first answer passes the tests, against 80 percent for GPT-4, the previous best.

Co-host: Healthy caveat though, that's one benchmark, reported by the authors. Coding is also a friendly case, because tests give you a crisp yes or no.

Host: Which is the real lesson. Reflection is only as good as the feedback it reflects on. Anthropic describes Claude Code's loop as gather context, take action, verify the work, then repeat.

Co-host: And from building these, I'd rank the checks. Best are rules-based: tests pass, the file parses, the format's valid. Next is visual feedback, like rendering a page and looking at a screenshot. Weakest is asking a model to grade its own work, because a judge that shares your blind spots tends to share your mistakes too.

Host: Asking a model whether a model did well. I'm told this podcast is familiar with the arrangement.

Host: So, for you: before adding reflection, ask what concrete signal the agent can read. If you can write a rule that checks the work, do that first.

Co-host: There's also a smaller version of reflection, inside a single task, right?

Host: Yes. Back to our airline agent, halfway through a rebooking with a pile of policy rules. Anthropic built what it calls a think tool, an extra step where, once it has started responding, the model can pause and check whether it has what it needs to move forward.

Co-host: It's a tool that does nothing except give the model a scratchpad. Which, as an engineer, I find hilarious and also kind of brilliant.

Host: On a customer service benchmark called tau-bench, in the airline setting, the think tool with a tuned prompt scored 0.570 against a baseline of 0.370. In retail, the tool alone scored 0.812 against 0.783.

Co-host: So big help where the rules are knotty, a modest bump where things are simpler. And notice the airline gain came paired with an optimized prompt, so it's not the tool by itself.

Host: And Anthropic now recommends extended thinking, the model's built-in reasoning before it answers, instead of a separate think tool in most cases.

Co-host: Then the bigger failure: the agent isn't missing a fact, it's stuck, retrying the same broken step.

Host: One common design uses two loops. An outer loop keeps a ledger of the task: the facts, the guesses, the plan. An inner loop keeps a progress ledger: are we done, are we looping, who acts next. If progress stalls, control goes back out and the plan gets rewritten.

Co-host: Which is basically what a good manager does. Stop asking are you busy, start asking are we closer.

Host: In practice: give your agent a pause where the rules are dense, and a way to notice it's going in circles, with a step budget so a stuck loop ends instead of burning money.

Host: So the one takeaway: an agent is a loop your code runs. The model asks for actions, you execute them and feed back results, and the quality of what you feed back, real checks, real data, decides how well it plans and reflects.