Lesson 30.1 taught the loop to stop. Lesson 30.2 taught it where it must ask first. This lesson gives both of those decisions teeth — numbers the system enforces even when the agent wants to continue.

A stop condition without a budget is a wish. "Stop when you have enough evidence" means nothing to a loop at 2 a.m. on its fortieth retry. Budgets turn intentions into exits the infrastructure can actually trigger.

The six numbers every loop carries

Every agent run should start with six limits written down before the first model call. They are cheap to set and expensive to skip:

Read the table as a hierarchy. Steps bound the loop. Tool calls bound the expensive part of the loop. Time bounds the run the queue can see. Spend bounds the bill. Retries bound the repeat-fail mode from Lesson 30.1. Escalation answers the question every other row raises: *stopped — now what?*

An exit ramp is a stopped run that lands somewhere useful: partial state saved, a missing-information note attached, the owner notified. A run that times out and vanishes — no state, no note, no owner — did not exit. It crashed.

Borrowed machinery: queues, cron, retries, monitoring

You already own the enforcement machinery from Part VII. Budgets plug directly into it:

• Queues hold the run and its state. A research job enters the queue with its budget attached (max steps, owner, output path). The worker loads the budget with the job — the agent never sets its own limits mid-run.
• Cron starts runs on schedule but never supervises them. A nightly source check that starts at 6 a.m. still needs a time budget and a step cap, because cron will happily start tomorrow's run on top of today's stuck one.
• Retries belong to the infrastructure, not the agent's optimism. Put the retry policy in the worker — two retries with backoff, then escalation — so the tenth identical tool call is structurally impossible rather than merely discouraged.
• Monitoring and logs make budgets visible. Log steps used, tool calls made, elapsed time, and spend per run. Alert the owner when runs repeatedly hit their caps: a loop that always stops at max steps is telling you the budget is wrong or the task is too big.

The shape looks like this:

cron / event → queue (job + budget + owner)
  → worker runs loop (counts steps, calls, time, spend)
  → budget hit or task done → save state + note
  → review queue / owner notified → logs + metrics updated

The agent decides the next *work* step. The worker enforces the *boundaries*. Never let the component that wants to continue also be the component that decides whether it may.

Worked example: five sources, one packet, or an honest stop

Return to the source researcher from Lesson 30.1. Its budget table makes the assignment concrete:

LOOP BUDGET — source-researcher v1
Max steps: 10 (5 sources + assess + save + margin)
Max tool calls: 6 (5 fetches + 1 spare retry)
Time budget: 10 minutes wall-clock
Model-spend budget: $0.50 per run
Retry limit: 1 retry per source, then mark source missing
Escalation: park packet + missing-info note in review queue, notify owner
Success: one evidence packet with ≥3 sourced items, saved to packets/YYYY-MM-DD.md

Now run it twice. First, the good day: five fetches succeed, assessment finds four solid items, the packet is written at step 7, well inside every cap. The leftover budget is not wasted — it is proof the task fits.

Second, the bad day: two sources are down. Each gets one retry, then is marked missing. Assessment finds only two usable items — below the three-item bar. The loop does not invent a third source, widen the list, or retry all night. It stops at step 6 and writes the missing-information note: "Packet incomplete: sources 3 and 4 unreachable after 1 retry each; 2 of 3 required items present; needs owner decision." That note *is* the output. An honest stop beats a fabricated packet every time.

That is the rule to internalize: five sources and one packet, or a named gap. The loop never has a third option called "keep trying until it looks done."

Practical exercise: write a loop-budget table

Take the same agent from Lesson 30.1's exercise and give it numbers:

1. Copy the six-row budget table above and fill in a value for each row. Keep first budgets tight — you can loosen them after three clean runs, never before. 2. Add a success line (file, fields, minimum counts) and an escalation line (queue location + named owner). 3. Connect each row to Part VII machinery: which queue holds the job, what schedule starts it, where retries live, where logs and alerts go.

Finish line: a LOOP-BUDGET.md (or a budget section in your agent card) with all six numbers, a success definition, and an escalation path.

Verify: simulate two runs on paper — one where everything works, one where two tools fail. Confirm both runs terminate, both save something inspectable, and neither exceeds any number in the table.

Common failure mode: generous budgets that never bind ("max 500 steps, just in case"). A budget ten times larger than the task needs is not safety — it is permission to burn money quietly. Start tight, widen with evidence.

Check your understanding

1. Name the six loop budgets. Which one directly prevents the repeat-fail mode? 2. Why should retry policy live in the worker rather than in the agent's own judgement? 3. What makes an exit ramp different from a crash? List the three things a stopped run must leave behind. 4. In the five-source example, why is the missing-information note a successful output rather than a failure? 5. Your loop keeps hitting its step cap. Name two possible causes and what you would change for each.