Design the Workflow and Control Loop

The real business problem

You built the tool layer in the last chapter. The agent can read the sales export, query the ledger and write a note. So you point it at a real task and watch. It calls one tool, gets a messy result, calls another, forgets what it already found, tries the same thing three times, then hands you a confident paragraph that turns out to be wrong.

The model was never the problem here. What is missing is the part that runs the agent. The loop that decides what to do next, remembers what already happened, retries the flaky steps, stops before it burns your budget, and checks the answer before it calls the job done.

That runner is the workflow, and it is where reliability lives. After this chapter you can take a raw model that “kind of works” and wrap it in a control loop that carries state, knows when to stop, and proves the outcome before you trust it. That is the difference between a demo and something you can run every morning without watching it.

The core idea

An agent works in a loop. Plan the next step, act on it with a tool, observe the result, decide whether to keep going or stop. Round and round until the goal is met.

Left alone, that loop has three ways to hurt you. It forgets what it learned two steps ago. It never stops. It declares victory the moment it produces text. A control loop is the small amount of engineering that fixes all three. It holds state, it caps the work, and it refuses to call anything done until the outcome is checked.

Write the loop’s job in one line. Keep taking sensible next steps toward a goal, remember the work so far, and prove the result before you hand it over.

A simple model

GOAL
|
v
PLAN —> ACT —> OBSERVE —> update STATE
^                              |
|                              v
|                        done enough?
|                         |        |
+--- no, under caps ------+        | yes
(retry / next step)           v
VERIFY
|       |
pass |       | fail
v       v
REPORT    STOP + escalate

Six moving parts do the real work. Plan, Act and Observe are the visible loop. State is the memory that survives between passes. The caps are the brakes. Verify is the proof. Take away the last three and you are left with the naive loop that forgets, runs forever and lies about being finished.

A concrete example

Take a data-to-decision agent. The goal is one sentence. “Look at last month’s numbers for this client and tell me whether to raise, hold or cut their retainer, with the reason.”

A single prompt cannot do this. The numbers live in a spreadsheet export and the billing system, not in the prompt. So the agent runs the loop.

• Plan. It needs revenue, hours logged and last quarter’s baseline.
• Act. Pull the revenue export.
• Observe. The file has two months in it, not one. It writes that fact into state.
• Plan. Filter to the right month, then pull the hours.
• Act and observe again, updating state after each step so it never re-reads what it already has.
• Decide. It has enough to form a view. Raise, hold or cut, with a number and a plain reason.

Then the part most people skip. Before it answers, it verifies. It re-adds the line items and checks the total against the figure it is about to quote. If the recomputed total does not match, that is not a formatting nit. It is a wrong answer, and the loop goes back a step instead of shipping it. Only a matched total earns the recommendation.

The implementation pattern

Five things turn the raw loop into something you can run every day.

1. Carry state, do not trust the transcript. Keep a running record separate from the chat history. The goal, the facts gathered so far, what has been tried, what failed. Pass a compact summary of that record into each step, not the entire history. If the agent cannot see what it already found, it repeats work and contradicts itself two steps later.

2. Retry with backoff, and know when to give up. Tool calls fail for boring reasons. A slow API, a rate limit, a dropped connection. Retry, but wait a little longer each time, and cap the attempts.

attempt 1 -> fail -> wait 1s
attempt 2 -> fail -> wait 4s
attempt 3 -> fail -> stop, record the reason, escalate

The other half of this is telling apart a flaky failure from a real one. A timeout is worth retrying. A missing file or a rejected login is not. Retrying a real error forever just wastes money on a call that will never work.

3. Delegate the hard sub-tasks. When one step is a big open-ended job of its own, like reading a 40-page contract or reconciling two ledgers, hand it to a sub-agent with its own small loop and a narrow goal. The main loop stays simple and just receives the answer. Do not delegate the easy steps. A sub-agent for a one-line lookup only adds cost and another thing that can fail.

4. Set stopping conditions before you run it. Every loop needs hard limits. A maximum number of steps, a maximum spend or token budget, and a wall-clock timeout. When any limit trips, the agent stops and reports where it got to. This is the difference between a run that costs 20 cents and one that quietly costs 40 dollars because it got stuck on an odd input. Numbers here are illustrative, but the shape is real. Set the ceiling on purpose, do not discover it on your bill.

5. Prove completion. The loop does not end when text appears. It ends when a check passes. The check depends on the task. Recompute the total and compare it. Confirm the file was actually written. Re-read the record you claim you updated and see the new value there. If the check fails, loop again or escalate to a person. Text is a claim. The check is the evidence, and evidence is the only thing worth trusting.

What breaks

Decision rules

Related lab

Data to Decision Agent. You will build the exact loop from the example above. An agent that pulls real numbers, forms a recommendation, and then verifies its own total before it is allowed to answer. You will set the step and cost caps, watch it retry a failing pull, and see the proof step reject an answer that does not add up. It is the shortest path from reading about the control loop to owning one.

Practical checklist

• You can state the goal and the stop condition in one sentence each.
• Your loop carries state between steps, not just the last message.
• Retries back off and give up after a fixed cap, and you tell flaky failures apart from real ones.
• There is a hard limit on steps, cost and time, set on purpose.
• The task counts as done only when a specific check passes, and you can name that check out loud.

What changes after this chapter

You stop shipping agents that produce text and start shipping agents that produce checked results. The loop is no longer a hopeful while-loop that runs until something appears. It is a controlled process with memory, limits and proof. The proof step is the whole point. It is what turns “the model wrote an answer” into “the work was done and I can show it.”

Next: Chapter 6, where the loop grows a longer memory and holds context across tasks that do not finish in a single run.