Opening

A browser agent downloads bills from a supplier's portal. Every night it logs in, walks through the pages, and saves each invoice.

One night, the portal changed its next page button. It was still on the screen, but it didn't load anything.

Here's the next morning's trace. Step four hundred twelve, click next page. Okay. Read the page. Invoices one to twenty, of three hundred forty. Click again. Okay. Read again. Invoices one to twenty.

All the way to step two thousand three hundred eighteen.

Nobody wrote a bug into that loop. It simply had no end, other than when the model thinks it's done. And the model never thought so. In this lesson, you'll learn to spot this smell before the bill does, and what a real end looks like.

The diagnosis

Look at two details in that trace.

The click answers okay, even when nothing changes.

And reading the page always shows the same first twenty invoices. The evidence that the agent was stuck was right there. But no code was looking at it.

Here's the shape of the smell. The model requests an action that looks sensible.

The tool responds without an error, even with no real progress.

Every turn resends the whole history, which grows with each step.

The loop's only exit is the model deciding to stop.

And when it doesn't decide, the provider's invoice is what stops the run.

How do you spot it? The agent's code says while true, or while not done, with no step counter.

There's no time, token or money limit per run.

Nobody can say what happens if the model never gives a final answer. And the month's most expensive run cost dozens of times the median.

The trace shows the same tool, with the same arguments, several times in a row.

And the only alarm that goes off is the credit card's.

Why it happens

The prototype was born this way. The simplest agent examples use while true, and the loop shipped unchanged.

It works in testing. On demo tasks, the model finishes in five steps. Nobody tested the portal with a broken button.

Tools that lie by omission. Okay, as the result of a click, doesn't say whether anything changed. The model has no way to notice it's stuck.

And the provider looks like a cap. People assume the context window will eventually stop the agent. But many frameworks trim old history to make it fit. And then the loop runs forever.

What it costs

Now the cost, with illustrative numbers. Say the system prompt and the tool descriptions are three thousand tokens, and each turn adds about four hundred. A normal run of ten turns sends about fifty-two thousand tokens in total. A stuck run of two hundred turns sends about eight point six million.

Twenty times more turns, and over one hundred sixty times more tokens. Cost grows with the square of the step count, because every turn pays again for everything before it. A single stuck run can cost more than a whole day of normal use.

And money is the smaller part. The loop eats the account's request quota, and takes down other runs sharing the same key.

If the stuck tool has a side effect, like sending, creating or paying, every turn repeats it.

And a trace with thousands of steps is close to unreadable.

A challenge

Here's one for you. An agent runs in while true. But its tool has a rate limit of ten calls per minute, so it never spends much per minute. Is this an unbounded loop?

Yes. A rate limit controls speed, not the total. A loop stuck at ten calls a minute still makes over fourteen thousand calls a day. It only spreads the cost over time. And the context window isn't a reliable brake either. Many frameworks drop old messages to fit, and the loop keeps paying for a full window, on every turn.

The treatment

The treatment is a refactoring called add loop budget. And the budget has four parts. The last one is the one people forget.

A step cap. Pick it from your traces. If ninety-nine percent of runs finish within fifteen steps, a cap of forty leaves room, without allowing a whole night.

Time and cost caps. Steps can be cheap or expensive. A money limit per run catches the case where a few steps send huge contexts.

A repetition detector. The same tool, with the same arguments, three times in a row, means the agent is stuck. Stop before the cap.

And behavior at the cap. Return what was done, explain where it stopped, and record the case. An agent that stops with a silent exception, and makes the task disappear, still leaves the user with no answer. The cap exists, but the treatment isn't finished.

Most agent frameworks already give you the first piece, as a maximum number of turns, or a recursion limit. You write the rest. And along with the budget, review your tools. A result that says what changed, like page two of seventeen loaded, helps the model notice when it's stuck. The pattern you're heading for is called stop conditions, and it's two lessons ahead.

And a week after you set the cap, say two percent of runs end there. Don't raise the cap to four hundred. Without reading the traces, you'd only let stuck runs spend ten times more before stopping. And don't ignore them either. Read those traces, find the cause, like a vague tool result or a page that changed, and turn each one into an eval case. They're the best source of hard cases you have.

Close relatives

Two cases to sharpen the eye. A job walks three hundred invoices, calling the model once per invoice, with no step counter. Is that this smell? No. The list is finite, and the code decides the next turn, not the model. The loop ends at invoice three hundred, either way.

And an agent with a thirty step limit, where each step can spawn subagents, which also have thirty steps, and can also spawn subagents. Each level has a cap. The total doesn't. That's a related smell, subagent recursion. The budget has to cover the whole tree, not each node.

When to ignore

When can you relax? A coding assistant in your terminal, with you watching and able to interrupt at any time, tolerates a high cap. Set one anyway. And no production agent, running without a person watching, should ever run without a cap.

Wrap-up

So here's the idea to take with you. The model can say it's done, but it can't be the only brake. Steps, time and money belong to your code, along with a repetition check and a clear answer when the cap is hit. Then the most expensive run of the month is a number you chose.

In the next lesson, we'll build that budget step by step: add loop budget. See you there.