The question
A small e-commerce operator's support agent had been live for two months, holding steady at roughly the same daily ticket count.
What we told them
Nothing was broken, in the sense of throwing an error. The agent was working exactly as built — that was the problem. A support agent that calls a tool, gets a bad or ambiguous result, and tries again isn't malfunctioning; it's doing what it was told to do. The cost shows up in three places nobody watches by default:
- Retry loops. A flaky lookup or a malformed response sends the agent back around — sometimes three or four times — before it either succeeds or gives up. Each pass is a full billable call, not a free retry.
- Tool-call chaining. An agent that checks inventory, then checks a second system to confirm, then re-checks after a tool times out, can burn five calls to answer one question a human would settle with a glance at one screen.
- Context growth. Long conversations carry their full history into every new call. A ticket that goes back and forth ten times isn't costing 10x one message — it's costing roughly 1+2+3...+10 times one message, because each turn re-sends everything before it.
None of this trips an error alert, because nothing failed. Usage looked flat because ticket volume was flat — the agent was just doing more billable work per ticket than it was in April. The fix isn't a smarter model; it's treating agent spend the way you'd treat a cloud bill: put a ceiling on it, and watch it before the invoice does. That means a hard cap on retries per task, a token or tool-call budget per conversation that kills the loop and hands off to a human when it's exceeded, and a weekly look at cost-per-resolved-ticket, not just total spend. If that number is climbing while volume is flat, you have a loop somewhere, not a workload increase.
An agent's meter doesn't stop just because the ticket looks the same size as last month's. Cap retries and tool-calls per task and track cost-per-resolution weekly, or the loop finds you through the invoice instead.