The Robustness Story Nobody Files, and the Agent Loops Everybody Does

Zero public stories about lack of robustness. One hundred and nine about multi-agent risk. That gap is not evidence that robustness is solved. It is evidence that we are auditing the wrong layer.

What most people think

The common view is that robustness and multi-agent risk are two faces of the same problem. If a model is fragile, the argument goes, that fragility will show up wherever the model is used, including inside agent workflows. Fix the model and you fix the system. So the reasoning runs that organisations investing in model evaluation are, by extension, de-risking their agent deployments. The two move together, and the news coverage should roughly track both.

It is a reasonable position. It is also wrong, and the evidence against it is sitting in plain sight.

What the data shows

Our live incident database, which tracks reported AI failures from public news, ingested 1,410 stories in the last 180 days. In the most recent 45 days it logged 462 stories, against 454 in the 45 days before that. Volume is steady. What the stories are about is not.

Against the MIT AI Risk Repository subdomains, the mismatch is stark. Multi-agent risks (subdomain 7.6) picked up 109 stories in 180 days. Lack of capability or robustness (7.3) picked up zero. Not few. Zero. Overreliance and unsafe use (5.1) also zero. Environmental harm (6.6) zero. Competitive dynamics (6.4) two.

Meanwhile the categories that do get covered are privacy leakage (182), multi-agent risk (109), fraud and targeted manipulation (96), and AI system security vulnerabilities (96). Governance failure sits at 42.

Severity is also shifting. In the last 45 days, critical stories fell from 90 to 45, while major stories rose from 357 to 402. That is a mix moving from acute to chronic. Fewer single dramatic events, more sustained operational drag.

The reporting base is thin, too. The top five outlets carry 7% of the last 45 days. Yahoo Finance and Law360 each carry 2%, Fortune, IAPP and Reuters 1% each. No single outlet is driving the picture.

And the security side is writing about a class of failure the governance side barely names. Our sister platform ThreatClaw published 40 articles in 60 days. The recurring tags include prompt injection (9 articles), data poisoning (9), and MITRE ATT&CK (9). MITRE ATLAS lists 22 documented real-world cases of LLM prompt crafting (AML.T0065), 15 of AI agent tool invocation (AML.T0053), and 12 of user harm (AML.T0048.003). None of these appear in the news window at all.

Why this happens

Organisations evaluate models in static test harnesses. You feed a fixed input set, you score the output, you compare against a baseline. That harness rarely produces catastrophic failures. A model that is slightly wrong on a benchmark is still a model that returns an answer. The test environment has no latency, no concurrent tools, no partial failures, no retries.

Production multi-agent workflows are the opposite. They are dynamic. Agent A calls Agent B, which calls a tool, which returns something malformed. A latency spike causes a timeout, which triggers a retry, which triggers a second tool call, which the first agent interprets as new input. Minor operational noise becomes a deadlock or an unintended loop. Nothing in the static harness predicted this, because nothing in the static harness had a clock or a second agent.

So the two risk classes diverge. Robustness failures are rare in the harness and therefore rare in the report. Multi-agent failures are absent from the harness and abundant in production. The reporting follows the test environment, not the deployment.

The consequence is that risk teams are spending testing budget on single-model accuracy benchmarks while their agent architectures run without circuit breakers. The gap between the two numbers is not a gap in risk. It is a gap in instrumentation.

The best argument against this

The strongest objection is that absence of reporting is not absence of failure. Robustness failures may be underreported because they are boring, internal, and rarely reach the press. A model that quietly misclassifies a document is not a news story. A multi-agent loop that takes down a customer portal is. On that reading, the 109 versus zero is a media bias artefact, not a risk signal, and the two classes probably do track together once you correct for visibility.

That objection is fair, and it is partly right. Reporting bias is real. But it cuts the other way too. If robustness failures are underreported because they are mundane, then they are also underreported in the regulatory filings that will matter from December 2027, when the EU AI Act's serious-incident reporting obligations under Article 73 come into force. The same day, Annex III high-risk obligations apply. Regulators will not be reading Yahoo Finance. They will be reading incident reports, and those reports will describe what actually broke. Multi-agent coordination failures leave traces. A deadlocked workflow leaves logs. A single-model accuracy miss often leaves nothing at all.

So the objection does not rescue the consensus. It just relocates the problem from public news to internal filings, where the multi-agent failures will still be the ones that show up.

What I think happens next

By December 2027, over 50% of major enterprise AI outages cited in regulatory filings during the second half of that year will be attributed to multi-agent loops rather than single-model hallucination or lack of robustness.

The date is 2027-12. What would prove me wrong is straightforward. If public post-mortems and regulatory disclosures through December 2027 show that single-model robustness failures outnumber multi-agent coordination failures by a ratio of 2:1 or higher, the thesis fails and the consensus was right.

What to do about it

• Mandate cross-agent message logging and rate limiting for all multi-agent tool invocations. If you cannot see the message, you cannot see the loop.
• Replace static robustness test suites with stochastic simulation environments that inject network and latency faults. A test harness with no clock is not testing the system you deployed.
• Add circuit breakers to agent workflows. Cap tool invocations per task, cap retries, and fail loudly when the cap is hit.
• Track multi-agent incidents as a named category in your risk register, separate from model accuracy. If your taxonomy folds them together, you will not see the divergence.
• Instrument the runtime, not just the model. Governance decides what an agent is allowed to do. Argus, at argus.threatclaw.ai, records what it actually did, including the attacks hidden inside retrieved documents and tool results. For a worked example of how tool chaining breaks a threat model, see "Why Giving AI Agents More Tools Opens New Security Holes" at threatclaw.ai/blog/stride-your-agent-logic-why-tool-chaining-breaks-your-threat-model.

The 109 stories are not a warning about multi-agent risk. They are a warning about what we are not measuring. That is the part worth fixing this quarter, before the filings start.

More from our platforms

These sister platforms cover the parts of this problem that sit outside governance.

• Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
• ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.

Related reading:

• The Patching Gap Hiding in the Government's Threat List on ThreatClaw
• Why Giving AI Agents More Tools Opens New Security Holes on ThreatClaw