Why Simple Loops Break

You already built a strong pattern:

question → model → maybe tool call → result → model again → final answer

That simple loop is perfect for many jobs: read a file, look up a time, answer from a few passages.

Now meet a job where that shape starts to crack.

One story: a refund helper

Person’s question: “Please refund order 4412.”

Your agent should:

1. Look up the order
2. If the amount is small → refund now
3. If the amount is large → wait for a human to say yes or no
4. Only then finish

                 look up order
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
     small amount            large amount
          │                       │
          ▼                       ▼
     refund now             WAIT for human
                                  │
                                  ▼
                            yes → refund
                            no  → stop

A straight “keep calling tools until done” loop does not match this picture well.

What still works with a simple loop

One main path. Finish in this program run. No long wait for a person.

Crack 1 — two paths (branching)

In the refund story, step 2 is a fork:

• Path A: refund now
• Path B: wait for a human

In a simple loop you hide that fork inside many if checks in one function. It works for a while. Then every new rule (“VIP customers skip approval”, “EU orders need a second check”) adds more ifs. The path becomes hard to see and hard to test.

You want the branches to be visible: “after lookup, go left or right.”

Crack 2 — wait for a human

Path B needs a pause.

The person (or a manager) is not inside your while loop. They may click “Approve” tomorrow.

A simple loop wants to finish now, in one run:

step 1 → step 2 → step 3 → done

If you stop the program to wait, you lose your place unless you invent save/resume yourself.

Example:

That “continue later” is not natural for a plain loop.

Crack 3 — memory scattered in the loop

While the loop runs, facts live in local variables and chat history:

• order id
• amount
• “waiting for human?”
• “already refunded?”

Easy to forget one update on one branch. Then the model sees a confused history and makes a wrong tool call.

You will want one clear place for those facts. That place is called state — next chapter.

Simple picture: loop vs what comes next

  Simple loop:   ● → ● → ● → ● → done

  Refund job:    ● → ● → ●
                      ↘     ↖
                        wait

Same tools. Same model. Different shape of control.

Worked walk-through

Order 4412 — amount $12 (small)

1. Look up order → $12
2. Branch: small → refund now
3. Final answer: “Refunded $12 for order 4412.”

Simple loop is fine.

Order 4412 — amount $900 (large)

1. Look up order → $900
2. Branch: large → must wait
3. Simple loop has no clean “sleep until Tuesday”
4. If you restart cold, you may look up again, or worse, refund twice

Here the simple loop breaks as a design — not because the model is “dumb,” but because the job needs pause + memory of where you stopped.

What we will build next (preview only)

This chapter only names the pain. Do not rush to a big framework. Learn the ideas first — they work in any language.

Words to keep

See it in Code

The Code panel runs a tiny refund helper. A small amount finishes in the loop. A large amount hits “need human approval” and stops — that is the crack. Check the Example console.