Agent Shakedown

Why Your Agent Repeats Itself: The Interruption Problem

In our lab, we grade voice agent calls the way they'll be graded in production: recordings open, scorecard out. On October 28, 2026, a test call produced a failure we'd seen hints of before — this time clean enough to name.

The agent did its job. It also said the same thing three times, to a caller who had already agreed.

What happened on the call

The test was a booking call. The caller had a straightforward problem, gave their details, and the agent worked through its intake correctly. Then it reached the required statement — the service fee. The fee on this agent is $49, stated with what it covers and the fact that it's credited toward the work if the caller goes ahead.

The agent began: "Before I book it — our service visit is $49. That covers the tech coming out, inspecting..."

The caller, hearing the number and satisfied, said what real callers say: "That's fine."

The agent restarted. From the top. "Before I book it — our service visit is $49. That covers the..."

The caller agreed again. The agent restarted again.

Three times in total, the fee statement began from the beginning, because the caller kept doing the most natural thing a caller can do — answering before the agent was finished. The call still completed, and the booking was made. Scored against our checklist, the run passed on task completion and failed on fee delivery and interruption handling: a required statement must be delivered in full, and it must be delivered once.

The cause was not the model

It's tempting to file this under "AI being AI." It wasn't. Two things in the setup produced the loop:

First, the script required the statement delivered in full. The agent's instructions treated the fee statement as incomplete until every word had been said and acknowledged. An interruption didn't register as the caller accepting the fee — it registered as the statement not having happened yet. So the agent did what it was told: it delivered the statement. Again.

Second, the responsiveness setting made it worse, not better. The agent was configured to yield quickly when the caller speaks — which is what you want. But yielding plus a restart-from-the-top instruction means every early answer triggers a fresh attempt at the full statement. The more responsive the agent, the more politely it repeats itself.

Notice what this means for testing: no single-turn test finds this bug. The statement reads perfectly in the prompt. The fee is stated correctly in every quiet test call. The failure only exists in the interaction — a caller behaving like a caller.

The fix was one rule

We didn't rewrite the script. We added a rule to the agent's instructions, at the end, where it overrides everything above it:

Never restart a statement from the beginning. If the caller answers, agrees, or says yes at any point during a statement — including the fee statement — that is their answer: accept it, bank it, and move to the next step. The fee counts as delivered once the amount, what it covers, and the credit have been said; if the caller agrees before the end, it is delivered — do not say it again.

Two ideas in that rule matter:

  • An early yes is data, not noise. Callers signal agreement while you are still talking. An agent that can't accept agreement mid-sentence will argue with satisfied customers.
  • Delivered has a definition. "In full" was the trap. The rule defines delivery by content — amount, coverage, credit — not by uninterrupted recitation. Once the caller has the substance and has agreed, the requirement is met.

The same call also got faster

This test series was run while we were tuning the agent's response time, and the graded numbers from the same configuration change are worth reporting because they come from the same discipline — percentiles, not impressions. Median end-to-end response time improved from 1.73 seconds to 1.24 seconds (p50) after the latency change, measured across the test call's turns. The point is not the specific numbers; it's that a change made for speed and a change made for behavior were both verified by re-running graded calls, not by feel. Speed changes alter interruption behavior, and behavior changes alter timing. You only see the interaction if you score both every time.

What to take from this

  1. Test interruptions on purpose. If your test callers always wait politely for the agent to finish, you have not tested the calls you will actually get.
  2. Score required statements per delivery, not per call. "The fee was mentioned" and "the fee was delivered once, in full, and accepted" are different results.
  3. Write the interruption rule down. Every agent needs an explicit instruction for what an early answer means. If you don't write it, the default behavior is whatever your other instructions accidentally imply — in our case, repeat yourself.
  4. Re-run after fixes. A rule that stops restarts could also let an agent accept agreement it shouldn't. The same scenario set, re-graded, is how you know the fix worked and what it cost.

The full scorecard these categories come from is public: AI agent evaluation checklist. The step-by-step test process is here: How to test a voice agent before launch.

Agent Shakedown runs interruption testing — and the rest of the scorecard — against voice agents on Retell, Vapi, or a custom stack, and returns the graded recordings. Launching soon: join the waitlist.