A Builder Reports 40 Wrong Billing-API Calls at 1:20 AM. What Stops Call 41?

Governance Watch

At 1:20 AM, an agent called the wrong billing API forty times in a row.

That is a builder's own account of his own system. Deepak Bagada, an AI builder, posted it on 5 October 2026 [1].

It is a first-person self-report — not verified against logs, and not independently confirmed by any third party. And the calls failed: forty failed calls, a deployment stalled three hours. No charges and no financial loss are reported. Read it as a useful war story from the front lines of agent deployments, not as a confirmed industry incident.

What he says broke

Per the post itself [1]:

• Eleven MCP servers wired straight to a release copilot for speed.
• The same tool name — get_user — living in four different servers, each with a different schema.
• The agent conflating parameters, and inventing three tools that did not exist.
• No chain log showing who called what on whose behalf.

The post also includes survey-style figures about agent policies that we could not trace to any verifiable survey, so this article does not repeat them as facts. What remains without them is still the useful part: a concrete picture of what tool sprawl does to an agent at 1:20 AM.

The question underneath

A pedagogical scenario, clearly labelled as one — not a case study, not a walkthrough of anyone's UI: your agent picks the wrong tool. What stops the next call?

Not a better prompt. The failure mode is structural: at the moment of the call, something has to know what the agent is allowed to do — and it has to sit between the agent and the side effect, not beside it in a dashboard.

Working practice, not a compliance checklist

• Connected-action policy. Decide in advance which actions an agent may take, and enforce that at the boundary before execution — routine actions proceed, prohibited actions are blocked, sensitive actions wait.
• Human approval where it matters. Approval requested by policy, before the side effect — not a notification after it.
• Records. If you cannot later show what the agent attempted, what was decided, and who approved it, you have logs at best and an argument at worst.
• Quarantine for loops. Where a configured control can stop further governed actions for an affected agent or session, a repeating failure ends at the boundary instead of compounding. Quarantine does not switch off an entire host, and it does not fix a confused tool catalogue.
• And fix the namespaces. Duplicate tool names across servers are yours to deduplicate. No governance layer renames your tools for you.

Where HaltState fits — and where it doesn't

HaltState checks the connected action before execution: your policy can deny an out-of-scope request or require human approval for a sensitive change, and signed Proof Packs record governed decisions for later review. Where configured, quarantine stops further governed actions from the affected agent or session. It does not deduplicate MCP tool names, does not verify another person's self-report, and is not a substitute for the schema hygiene that caused this failure. On the current product page, the worked refund example is labelled illustrative — not live activity [2].

General information only. This article and its companion video are not legal advice.