The short answer
An agent that loops is doing one of three things. It cannot tell that its action worked. It has no rule that says when to stop. Or the rule exists but the output it checks never matches it. This worksheet collects the minimum evidence to tell those three apart.
Do not change the agent until you have filled in all three sections. A fix made without a trace usually moves the loop rather than ending it. A fix made without a regression case breaks again silently the next time the input changes.
Why it repeats, in two minutes
In under three minutes you will know why an AI agent repeats the same step, what to write down first, and why a limit on tries is not a fix.
Every example in the video is made up to show the method.
The words of the video
Does your AI agent ever do the same thing, again and again? Before anyone changes it, give me three minutes. I'll show you a one page worksheet that finds out why.
First, what are we talking about? An AI agent does a job for your team, one step at a time. Say it looks up a price, but the answer isn't what it expects. So it tries again, and again, and never finishes.
Here's what I've learned. When an agent repeats itself, the first idea is a quick fix, like a limit on tries. But a fix made without knowing why usually moves the problem somewhere else. So find out why, before you change anything.
Here's a made up example. Customer A orders three boxes of one item. Agent B looks up the price and gets two, an old one and a new one. Its rule says stop at one price, so it looks again, and again.
So here's the worksheet. First, a record of every step, what it did and what came back, copied exactly. Second, the rule that says when it should stop. Third, a saved test you can run again after the fix.
In my experience, there are only three reasons it repeats. There's no rule for when to stop. Or the rule can never be met, like one price when there are always two. Or the rule is there, but nothing checks it.
One more thing I always check. A limit on tries stops the repeating, but it doesn't fix the reason. Raise the limit, and it repeats again. So treat it as a safety net, and fix the real reason.
So that's the worksheet. It shows where it went wrong, which of the three reasons it is, and what kind of fix it needs. And the saved test proves the fix worked.
The worksheet and a made up example are free on shurco.ai. Fill it in before anyone changes the agent.
1. Reproduce the loop on a safe copy
Run the agent against a copy of the input that caused the problem, not the live mailbox, queue or system. If the agent writes to a database, point it at a test database. You need the loop to happen again so you can record it.
I ask for the smallest input that still causes the loop. A single email, a single order line, a single timesheet row. A smaller input produces a shorter trace and a faster regression test.
2. Record a synthetic trace
A trace is a record of every action the agent took, in order, with the input it saw and the output it produced each time. Synthetic means you write it by hand from the logs, not that you invent it. Copy the real log lines into the trace sheet. Do not paraphrase.
Mark the step where the agent should have stopped. If you cannot mark it, the stop condition is missing or invisible. That is already a finding.
3. Write the stop condition in plain English
A stop condition is the rule the agent uses to decide it has finished. Write it as a sentence a colleague could check by hand. For example, stop when the price list row for this item code returns exactly one match and the quantity field is a whole number above zero.
If the condition is already written somewhere, copy it exactly. Then check whether the agent's output at the marked step actually meets it. If the output meets the condition and the agent continued anyway, the condition is not being checked. If the output does not meet it, find out why.
4. Build the regression case
A regression case is a saved input and the correct output you expect from a fixed agent. It lets you confirm the fix worked and catch the same loop if it returns. Save the smallest input that caused the loop, the trace you recorded, the stop condition, and the output you expect after one correct run.
Store the regression case where the team that maintains the agent can find it. A folder in a shared drive is enough. A case that lives only in someone's head is not a case.
The blank worksheet
Fill in one section at a time. Do not move to the regression case until the trace and stop condition are complete.
| Section | Field | Your entry | Source | Checked by | Date checked | Status | Notes |
|---|---|---|---|---|---|---|---|
| Trace | Input that caused the loop | ||||||
| Trace | Step number | ||||||
| Trace | Action taken | ||||||
| Trace | Output produced | ||||||
| Stop condition | Condition as written | ||||||
| Stop condition | Output at marked step | ||||||
| Regression case | Saved input file or reference | ||||||
| Regression case | Expected output after fix |
Download this sheet as a file for Excel
A worked example
Made up example. Every row here is made up to show the method. Agent B and the price list described do not exist.
| Section | Field | Your entry | Source | Checked by | Date checked | Status | Notes |
|---|---|---|---|---|---|---|---|
| Trace | Input that caused the loop | Order line from Customer A, item code P040, quantity 3 boxes | Test mailbox copy dated 2026-10-10 | Person A | 2026-10-11 | Confirmed | Smallest input that still loops |
| Trace | Step 1 | Look up P040 in price list | Agent log line 14 | Person A | 2026-10-11 | Confirmed | Returned two rows, revision B and revision C |
| Trace | Step 2 | Look up P040 in price list | Agent log line 15 | Person A | 2026-10-11 | Confirmed | Same result, agent did not filter by revision |
| Trace | Step 3 | Look up P040 in price list | Agent log line 16 | Person A | 2026-10-11 | Confirmed | Loop confirmed, marked step where stop should occur |
| Stop condition | Condition as written | Stop when price list lookup returns exactly one active row for the item code | Agent specification document section 4 | Person B | 2026-10-11 | Gap found | Condition does not say which revision to prefer when two are active |
| Stop condition | Output at marked step | Two rows returned, both active, revisions B and C | Agent log line 14 | Person B | 2026-10-11 | Confirmed | Output never meets the condition as written, so agent retries indefinitely |
| Regression case | Saved input file or reference | test-inputs/customer-a-p040-loop-2026-10-10.eml | Test mailbox export | Person A | 2026-10-12 | Saved | |
| Regression case | Expected output after fix | Agent returns one price row for P040 revision C and stops, or sends line to a person when revision is ambiguous | Agreed with Person B on 2026-10-12 | Person B | 2026-10-12 | Agreed | Revision C is current per catalogue owner confirmation |
Download this sheet as a file for Excel
The three causes and how to tell them apart
The first cause is a missing stop condition. The agent was never told when to stop. The trace shows the same action repeating with no check between steps. Fix the specification before touching the code.
The second cause is a stop condition that the output can never meet. The worked example above shows this. The condition says one row, the price list always returns two. The agent is not broken in the sense of ignoring a rule. It is following a rule that cannot be satisfied. Fix the condition or fix the data.
The third cause is a stop condition that exists and could be met, but is not being checked. The agent produces the right output and then runs again anyway. This is a wiring problem. The check is written but not connected to the step that should trigger it. Read the code around the check, not the check itself.
What can change the answer
Some loops are not infinite. An agent may repeat an action a fixed number of times before failing with an error. Check whether the log shows a retry count. A retry limit is not a stop condition. It is a safety net. The underlying cause is still one of the three above.
An agent that loops only on certain inputs has a data problem as well as a logic problem. Run the regression case against several inputs from the same source, such as the same customer's orders or the same timesheet format, to find whether the loop is narrow or wide.
When this is the wrong tool
This worksheet covers loops where the agent repeats a single action. It does not cover an agent that oscillates between two different actions, an agent that produces wrong output without repeating, or an agent that stops too early. Those need a different trace structure.
If the agent has no logs at all, the first task is adding logging, not filling in this sheet. A trace built from memory is not reliable enough to base a fix on.
Some repeated actions are correct behaviour. An agent that polls a queue every thirty seconds is not looping in the sense this worksheet addresses. Confirm that the repetition is unintended before starting.
What the three sections tell you
| Section | What you collect | What it tells you |
|---|---|---|
| Synthetic trace | Every action in order, with input and output at each step | Where the loop starts and what the agent saw when it should have stopped |
| Stop condition | The rule as written and the actual output at the marked step | Whether the condition is missing, unsatisfiable or disconnected |
| Regression case | Saved input, trace and expected output after the fix | Whether the fix worked and whether the loop returns on a later run |
What to do with the result
Take the completed worksheet to whoever will make the fix. The trace tells them where to look. The stop condition analysis tells them what kind of fix is needed. The regression case tells them how to confirm it worked.
If the stop condition is missing or ambiguous, agree the correct rule in plain English before anyone writes code. A fix that adds a retry limit without correcting the condition will loop again when the limit is raised.