Debugging Claude Cowork: Loops, Bad Tool Calls, Hallucinated Args

The first time a Claude Cowork agent works end-to-end, it feels like magic. The second time, it spins in a loop calling the same connector eleven times, picks a tool that has nothing to do with the task, and confidently passes an argument no human ever typed. Debugging agentic work is its own discipline. The model is not wrong the way a null-pointer is wrong — it is wrong in plausible, fluent, hard-to-spot ways. This post walks through the three failure modes that account for the overwhelming majority of broken Cowork runs and gives you a concrete way to diagnose and fix each.

Before you debug anything, instrument it. The single most valuable thing you can do is capture the full transcript of every run: each user turn, each tool definition the model saw, every tool call it emitted with raw arguments, and every result the tool returned. If you are flying blind on the inputs and outputs of each step, you are guessing. Treat the transcript as your stack trace.

Failure mode one: the runaway loop

Loops are the most common and the most expensive failure. The agent calls a tool, gets a result it doesn't quite like, calls the same tool again with a tiny variation, gets a similar result, and repeats. Sometimes it alternates between two tools forever. In a multi-turn Cowork session this burns tokens and wall-clock time while producing nothing.

Loops almost always trace back to one of three causes. The tool returns an ambiguous or empty result and the model keeps retrying hoping for something better. The success criterion is underspecified, so the model never knows it is done. Or two sub-agents hand the same sub-task back and forth because neither owns the decision. The fix for the first is to make tool results unambiguous — return an explicit status field and a human-readable message rather than a bare list that might be empty. The fix for the second is to state the stopping condition in the task instructions: "When you have the customer's account ID and current plan, stop searching and produce the summary."

How to read a loop in the transcript

The diagram below shows the decision flow you should walk through when a run loops. The goal is to localize the loop to a single tool or a single ambiguous instruction before you change anything.

flowchart TD
  A["Run loops or stalls"] --> B{"Same tool repeated?"}
  B -->|Yes| C["Inspect that tool's results"]
  B -->|No| D{"Two agents ping-pong?"}
  C --> E{"Result empty or ambiguous?"}
  E -->|Yes| F["Return explicit status & message"]
  E -->|No| G["Add a stop condition to the task"]
  D -->|Yes| H["Assign clear ownership of the subtask"]
  D -->|No| G
  F --> I["Re-run & confirm termination"]
  G --> I
  H --> I

Set a hard ceiling on iterations as a backstop. A run that hasn't converged after a reasonable number of tool calls is not going to converge on its own — it should fail loudly and hand back to a human rather than silently draining your budget. The ceiling is not the fix; it is the seatbelt while you find the real fix.

Failure mode two: the wrong tool call

The second failure mode is the agent reaching for a tool that is plausible but wrong — calling a search connector when it should have called a write connector, or invoking a destructive action when a read-only one would do. This is rarely a model-intelligence problem. It is almost always a tool-description problem.

Claude chooses tools from their names and descriptions, the same way a new hire chooses from a menu. If two tools have overlapping descriptions, the model will sometimes pick the wrong one, and which one it picks can feel random. The cure is to write tool descriptions that are mutually exclusive and explicit about when not to use them. A good description says what the tool does, what it returns, and the precise condition under which it is the right choice. Add a sentence like "Do not use this to modify records; use update_record for that." Disambiguation in the description is cheaper and more reliable than any clever prompt.

When wrong-tool calls persist, reduce the surface area. An agent offered forty tools makes worse choices than one offered eight. Cowork plugins let you bundle only the skills and connectors a given workflow needs; lean on that. Fewer, well-described tools beat a giant undifferentiated toolbox every time.

Failure mode three: hallucinated arguments

The most insidious failure is the hallucinated argument: the tool is right, but the model invents a value — a customer ID that doesn't exist, a date in the wrong format, a field name it imagined from training data. These pass schema validation just often enough to reach production and cause real damage.

Defend at the boundary. Every tool should validate its arguments against a strict schema and reject anything malformed with a descriptive error rather than guessing. When Claude receives "error: account_id must be a 12-digit string, got 'ACME-CORP'", it self-corrects on the next turn far more reliably than if the tool silently coerced the bad value. The error message is a teaching signal — write it for the model, not just for a log file.

The deeper fix is to make the agent ground its arguments in retrieved data rather than inventing them. If an action needs an account ID, the workflow should first call a lookup tool that returns the real ID, so the model copies a value it actually saw instead of confabulating one. Hallucinated arguments thrive when the model is asked to supply a value it was never given. Close that gap and most of them disappear.

A practical debugging loop

Put it together into a repeatable routine. Reproduce the failure with a fixed input. Read the transcript and classify the failure as loop, wrong tool, or bad argument. Apply the targeted fix — clearer result, sharper description, stricter validation, or grounding. Re-run the exact same input and confirm the behavior changed. Then add that input to a small regression set so the bug can't quietly return when you tweak a prompt next week.

Resist the urge to fix everything with one giant system-prompt edit. Vague global instructions like "be careful with tools" rarely move behavior and make the next bug harder to isolate. Surgical, one-cause-at-a-time changes keep your transcripts interpretable and your fixes durable.

Frequently asked questions

Why does my Claude Cowork agent keep calling the same tool repeatedly?

Almost always because the tool's result is ambiguous or empty and the model retries hoping for a better answer, or because the task never states when the agent is done. Return an explicit status and message from the tool, and write a concrete stopping condition into the task instructions.

How do I stop Claude from choosing the wrong tool?

Rewrite tool descriptions so they are mutually exclusive and say when not to use each tool, and reduce the number of tools the agent sees. A small, well-described toolset produces far more reliable selection than a large overlapping one.

What is a hallucinated argument and how do I prevent it?

A hallucinated argument is a tool parameter the model invents rather than derives from real data — an invented ID, date, or field name. Prevent it by validating arguments strictly at the tool boundary, returning descriptive errors, and having the workflow look up real values before any action that needs them.

Do I really need full run transcripts to debug?

Yes. Without the exact tools the model saw, the arguments it emitted, and the results it received, you are guessing at the cause. The transcript is the agentic equivalent of a stack trace, and capturing it should be the first thing you set up.

Take these patterns to your phone lines

The same debugging discipline — readable transcripts, sharp tool descriptions, and grounded arguments — is what keeps voice agents reliable too. CallSphere builds multi-agent assistants that answer every call and message, use tools mid-conversation, and book work around the clock. See it live 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.