Debugging Claude agents in finance: loops & bad tool calls

The first time a Claude agent went sideways in a financial workflow I was on, it didn't crash. It quietly called a balance-lookup tool eleven times in a row, each time with a slightly different account identifier it had invented, then confidently summarized a reconciliation that referenced none of the real data. No exception was thrown. The run "succeeded." That is the unsettling thing about debugging agents in financial services: the failures are rarely loud, and the cost of a silent wrong answer in a domain governed by ledgers, regulators, and customer trust is far higher than a stack trace.

Debugging an agent is not like debugging a function. A function has deterministic inputs and outputs you can assert against. An agent is a loop of model calls, tool invocations, and accumulating context where the model decides what to do next. When something goes wrong, the root cause might be a vague tool description, a poisoned context window, or a model that simply guessed. This post walks through the failure modes I see most often when teams deploy Claude across banking, lending, payments, and wealth workflows, and how to find them fast.

The three failure modes that dominate financial agents

Across dozens of agent builds, the same three problems account for most of the wasted runs. The first is infinite or near-infinite loops: the agent calls a tool, gets a result it doesn't quite understand, and tries again with a tweak, over and over. In finance this often happens with stateful APIs — a transaction-search tool that returns an empty page, which the model interprets as "I haven't found it yet" rather than "there is nothing there," so it keeps paginating into the void.

The second is wrong tool calls — the agent picks the right intent but the wrong tool. Ask it to flag a suspicious wire and it calls get_transaction instead of create_alert because both descriptions mention "transaction." The third, and most dangerous in a regulated domain, is hallucinated arguments: the model fabricates an account number, a date range, or a currency code that looks plausible and is completely wrong. A hallucinated account_id passed to a funds-transfer tool is not a bug, it is an incident.

A practical definition to anchor on: an agent failure mode is a recurring, identifiable pattern in which the model's decision loop produces incorrect tool calls, arguments, or termination behavior despite each individual model response appearing reasonable. Naming the mode is the first step to instrumenting for it.

Make the agent's reasoning observable

You cannot debug what you cannot see. The single highest-leverage change is to capture the full trace of every run: the system prompt, each model turn, every tool call with its exact arguments, the raw tool result, and the token counts. When you build on the Claude Agent SDK or Claude Code, you get hooks that fire on tool-call boundaries — use them to emit structured trace events to your logs rather than scraping stdout. Each trace event should carry a run ID, a turn index, the tool name, the argument JSON, and a hash of the result so you can diff identical calls.

flowchart TD
  A["Claude turn"] --> B{"Tool call?"}
  B -->|No| C["Emit final answer + trace"]
  B -->|Yes| D["Pre-call hook: log args, validate schema"]
  D --> E{"Args valid & in allowlist?"}
  E -->|No| F["Reject, return error to model"]
  E -->|Yes| G["Execute tool"]
  G --> H["Post-call hook: log result + token cost"]
  H --> I{"Same call seen >3x this run?"}
  I -->|Yes| J["Trip loop breaker, halt"]
  I -->|No| A

With that trace in place, loops become trivial to spot: you group calls by tool name plus argument hash and look for repeats inside a single run. I set a hard ceiling — if the agent makes the same call with the same arguments more than three times, a loop breaker injects a message telling the model the call is not making progress and to either change strategy or stop. That message in the context window is often enough to snap Claude out of the loop, because the model is genuinely reasoning; it just lacked the signal that it was stuck.

Validate arguments before they reach a real system

The defense against hallucinated arguments is a validation layer that sits between the model's tool call and the actual financial API. Every tool gets a strict schema — not just types, but semantic checks. An account_id must exist in your customer index. A transfer_amount must be positive and under a per-run cap. A currency must be in your supported set. When validation fails, you do not silently drop the call; you return a structured error back to the model so it can correct itself. Claude is good at reading "account_id 88421 not found, did you mean one of the accounts in the prior context?" and self-correcting.

The subtle part is distinguishing a hallucination from a legitimate miss. If the model invented an account number that was never in its context, that is a hallucination and you should tighten the prompt to forbid guessing identifiers. If the model used a real value that simply doesn't exist anymore, that is a data freshness problem. Your trace should make this distinguishable by recording which prior turn, if any, the argument value first appeared in. Arguments that appear out of nowhere are your hallucination signal.

Why wrong tool selection happens — and how to fix it

Wrong tool calls almost always trace back to ambiguous tool descriptions. When two tools have overlapping language, the model has to guess, and under token pressure it guesses badly. The fix is descriptions written for disambiguation, not just documentation. Instead of "Searches transactions," write "Read-only. Returns past transactions for a known account. Does NOT create alerts or move money — use create_alert or initiate_transfer for those." Telling the model explicitly what a tool is not for is one of the most effective edits you can make.

Tool count matters too. An agent with forty tools in scope will misroute more than one with eight. In financial deployments I scope tools to the task: a reconciliation agent does not get transfer tools in its toolset at all. This is both a correctness win and a security win — a tool the agent cannot see is a tool it cannot misuse. If you need many capabilities, use subagents, each with a narrow, purpose-built toolset, coordinated by an orchestrator that hands off cleanly rather than one monolith juggling everything.

Reproduce, don't just observe

The last piece is reproducibility. Because model outputs are non-deterministic, a failing run can be hard to recreate. The trick is to replay against recorded tool results. Save the exact tool outputs from a failed run, then re-run the agent with those outputs stubbed in, varying only the prompt or tool descriptions you are testing. This isolates whether your fix actually changed behavior or whether you got lucky on a re-roll. Run the same scenario several times — agent debugging is a statistical exercise, and a fix that works once out of five is not a fix.

Keep a library of these recorded failure cases. When a new edge case bites you in production, add it to the library and confirm your change resolves it without regressing the others. Over time this becomes the backbone of your eval suite, and the line between debugging and testing blurs in the best possible way.

Frequently asked questions

How do I stop a Claude agent from looping forever?

Track tool calls by name plus an argument hash within each run and set a hard repeat ceiling, commonly three identical calls. When the ceiling trips, inject a message telling the model the call is not making progress and require it to change approach or terminate. Pair this with a global turn limit as a final backstop.

What's the best way to catch hallucinated tool arguments?

Put a strict validation layer between the model and the real API. Check not just types but semantics — that account IDs exist, amounts are within caps, codes are in allowlists — and return structured errors to the model so it can self-correct. Record which prior turn each argument value first appeared in to distinguish invented values from stale ones.

Why does my agent call the wrong tool?

Usually the tool descriptions overlap in language and the model can't disambiguate. Rewrite descriptions to state explicitly what each tool does and does not do, and reduce the number of tools in scope per task. Narrow, purpose-built toolsets routed through subagents dramatically cut misrouting.

How do I reproduce a flaky agent failure?

Record the exact tool results from the failed run and replay the agent against those stubbed outputs, changing only the variable you're testing. Run each scenario several times because behavior is statistical, and keep the recorded cases as regression tests.

Bringing agentic AI to your phone lines

CallSphere brings these same debugging-first habits — full traces, loop breakers, and argument validation — to voice and chat agents that answer every call, use tools mid-conversation, and book work around the clock. See how it runs in production at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.