The Agentic Loop for FDEs

If you took the Claude Code Masterclass you have already seen the agentic loop from the point of view of a developer using one. This lesson is the same loop from a different seat — yours as an FDE, deploying one inside a customer's system — and it is the small difference in that seat that this part of the course is actually about.

If you haven't done that course, the agentic loop lesson there is the fullest treatment and you can come back here afterwards; what follows is enough to keep going.

The loop, briefly

Every modern agent runs the same three phases on repeat, and the names are not important but the sequence is. It gathers — it reads what it needs to decide. It acts — it writes, calls, queries. It verifies — it reads what it just did and asks whether that was the thing.

1. Step 1

   Gather

   Read files, call retrieval, inspect state. The agent is collecting the context it needs to pick a next move — not committing to one yet.

2. Step 2

   Act

   Edit a file, run a command, call an API, update a record. One tool call, chosen because the gather phase said it was the right one.

3. Step 3

   Verify

   Read the result. Did the test pass, did the write take, does the ledger balance, is the page rendering? If yes, done. If no, back to gather with what you learned.

The thing that makes this a loop rather than a pipeline is that each phase chooses the next step based on what the previous step returned. A chain has its steps written down before the run starts; an agent has a graph of possible steps and walks a different path through it every time. That one distinction is why an agent can recover from a failure without human intervention, and also why it can get stuck in ways a chain never would.

What changes when the customer owns the data

Every lesson in a typical agents tutorial runs the agent against a toy repo, a mock database, a public API. What the tutorial does not have to think about is that the next tool call is going to touch a real customer's data, and the next one after that is going to touch it again.

As an FDE three things change about the loop the moment it crosses that boundary.

The verify phase stops being optional. In a demo you can let the loop stop whenever the output looks reasonable. In production the output has to match something — a count in a system of record, a ledger that balances, a field that was blank and is now populated with the right value. If there is no verify step the agent will happily end a loop halfway through a job and the only person who finds out is the customer.

The act phase has a blast radius. The tool the agent reaches for at the bottom of the gather phase is doing something to the customer's data. Reads are cheap to be wrong about. Writes are not. This is why so much FDE work goes into shaping the tools the agent is allowed to call — a topic the next lesson is dedicated to — rather than the prompt.

The gather phase is on a clock. The customer is paying for latency as well as for model tokens, and a loop that reads twelve documents to make a decision a human would make from one summary is honest, slow and the wrong economics. Scoping what gathering looks like is part of the design, not something the model gets to decide freely.

Stopping conditions

An agent that cannot stop itself is not something you ship. The cheapest thing you can get wrong as an FDE is omitting a stopping condition, because it is invisible until it is not.

Four stopping conditions are worth naming explicitly, and you want all four on a production loop.

A wall-clock timeout covers the case where a tool hangs or the agent is looping in a way nothing else catches. It fires without regard for what the loop is currently doing, which is both its virtue and its limitation — it is a safety net, not a scoping instrument.

A tool-call budget is the one that matters most when the tools at the end of the loop write. An agent that can call a write tool five hundred times before anyone reviews is not a feature, and the fix is a hard cap. In the invoice-reclassification example, the cap is small and your operations team decides what it is.

A Stop hook is the general-purpose off switch: a check the agent runs before every turn, which can inspect the current state and declare the loop done, or require a human to take over. Loop detection — the same tool called with the same arguments three times in a row — belongs here.

A user abort is the one the end user controls. The UI has to make stopping a running agent as cheap as starting one, because the first time a loop goes somewhere the user did not expect, the ability to stop it is what earns their trust the second time.

Where this leaves you

You have one more mental model than the developer seat gave you: the same loop, but against data you did not create and do not own, with a stopping condition for every way it could go wrong. Everything else in this part builds on this — the next lesson is about the tools the agent is allowed to reach for, which is where most of your FDE design work actually lives.