A preprint published to arXiv on 17 August 2026 named something that has been quietly reshaping public administration for three years. Chris Schmitz (Hertie School), Lewis Hammond (Cooperative AI Foundation) and Alan Chan (GovAI) call it agentic flooding: a surge in the volume or complexity of requests a service receives, caused by AI agents lowering the cost of making them. Their dataset covers 84 cases across 11 jurisdictions where officials or credible third parties attribute a demand surge to public AI use.
The paper is about government. The mechanism is not. If your business accepts free-form text through an open digital channel, and the effort of writing that text is the only thing holding your queue at a manageable size, you are running the same architecture as a planning consultation. That architecture has just had its load-bearing wall removed.
TL;DR
- Researchers documented 84 cases of “agentic flooding” across 11 jurisdictions, where AI-assisted submissions strained government services; German social courts attribute a 55% year-on-year caseload rise in 2025 largely to AI-generated claims.
- In 87% of cases the mechanism is simply cheap LLM text generation, not autonomous browser agents. The sophisticated attack has not arrived yet; the cheap one is already working.
- Two properties predict exposure: the submission is financially or strategically valuable, and demand was historically suppressed by effort or specialist knowledge rather than by design.
- The same risk applies to commercial intake: support desks, warranty and refund claims, RFQs, job applications, disputes, abuse reports and bug bounty programmes.
- Adding friction (fees, CAPTCHAs, rate caps) is the fastest fix and the worst one. Structured interfaces, real identity, straight-through processing and AI triage take longer to build but do not punish your best customers.
Two kinds of flooding, and only one of them is about volume
The researchers split the phenomenon in two. Quantitative flooding is more requests. Qualitative flooding is requests that each take longer to process. Both increase load, and they need different responses, which is the part most teams get wrong.
The numbers are instructive: 60% of cases show quantitative flooding, 90% show qualitative flooding, and 50% show both. Complexity is the more common failure mode, and it is the one your rate limiter cannot touch. In one German case, submitted letters ran to over 4,000 pages. A cap of one submission per person per day does nothing about that.
This is why the standard infrastructure playbook underperforms. We have written before about API gateways not being ready for agent traffic, and that still holds, but agentic flooding sits one layer up. These are not bots hammering an endpoint. They are real people with real entitlements submitting real requests, assisted by a tool that made the writing free. Every request is legitimate. That is what makes it hard.
The evidence is broader than it looks
The authors scanned 12 countries and 13 service domains, roughly 190 candidate services per country. Fewer than one in twenty cleared their inclusion criteria, which required a plausible mechanism, evidence of a demand change, and explicit attribution to AI by a government or reputable secondary source. Justice and legal services dominate at 23% of cases, then regulatory complaints at 12% and benefits at 11%.
The individual cases read as a preview of your own inbox. Australia has considered reintroducing Freedom of Information fees after a wave of AI-generated requests. Japanese authorities blocked submissions to an energy policy consultation by IP address. Dutch municipalities saw a surge in property valuation objections. In Brazil, disability benefit claims arrived with AI-generated medical certificates.
That last one matters commercially, because it is the same pattern as a fraudulent warranty claim with a fabricated receipt, and it is arriving through the same door.
The two properties that predict who gets hit
Strip away the public sector specifics and the risk model is simple. Services get flooded when both of these are true:
- A successful submission is worth something. Money, an entitlement, a decision in your favour, or a legally mandated response from the recipient.
- Demand was suppressed by friction, not by design. Nobody set a limit. The work of writing a coherent complaint, assembling documents or understanding the eligibility rules quietly gated who bothered.
The second property is the one worth sitting with. Most intake systems have never been capacity planned. Their throughput assumption was inherited from how many people could be bothered, it was never written down, and so nobody noticed when it stopped holding.
Run the test across your own surfaces. Refund and chargeback disputes, previously gated by the effort of arguing. Enterprise RFQs, gated by the effort of writing a requirements document. Job applications, gated by the effort of tailoring a CV. Vulnerability reports, where we have already watched this play out as AI-generated submissions overwhelmed bug bounty triage. Abuse complaints, where a legally mandated response per report is the fastest route from a demand surge to a compliance failure.
The fast response is the bad response
The paper maps government options into two strategies, and the asymmetry between them is the most transferable insight in the piece.
Suppress demand by adding friction (fees, identity checks, rate caps, closing digital channels) or by reducing what a submission is worth. This is fast, cheap, well precedented and effective. It also deters the least confident and least resourced users first, which is rarely who you wanted to filter out. Governments used it in 17% of documented cases. Businesses reach for it constantly, usually by burying the contact form.
Increase capacity by redesigning the service or deploying AI in processing. This punishes nobody and tends to improve the experience for legitimate users as a side effect. It also needs lead time, budget and cross-team coordination, so it is essentially unavailable once a surge is underway.
The researchers expect governments to default to friction because, in the moment, it is the only lever short enough to pull. The commercial version of that mistake is a CAPTCHA on your enquiry form, and CAPTCHAs, as the paper notes, no longer reliably identify humans anyway.
What to build before you need it
The useful move is to treat this as an architecture problem now, while it is still cheap. Five things are worth doing this quarter.
Audit your intake surfaces. List every channel accepting free-form text from outside the company. Score each on value of a successful submission, current utilisation of processing capacity, effort per submission processed, and whether any contractual or regulatory obligation forces a response by a deadline. Start with the high-value, high-utilisation, deadline-bound ones.
Replace free text with structure where you legitimately can. Not everywhere: an open text box is often the correct design, and stripping it out to save triage time is a real cost to your users. But much of what arrives as prose could arrive as fields, and structured submissions are what make straight-through processing possible. Highest leverage, longest lead time, which is exactly why it needs starting before the surge.
Get identity right. Verified identity lets you enforce per-person limits without charging or deterring anyone, and it makes deliberate flooding much harder. It also lets you pre-populate what you already know, cutting effort for the legitimate user and your processing cost at once. Very few levers do both.
Deploy agents on your side of the wall. Intake classification, deduplication, completeness checking, evidence extraction and drafted correspondence are all within reach, and this is where the asymmetry finally works in your favour. If submissions arrive at machine speed, triage should run at machine speed too. Keep the consequential decision with a human, both because the law frequently requires it and because the failure modes of automated rejection are worse than those of a backlog.
Measure complexity, not just volume. Most intake dashboards count tickets. If qualitative flooding is the more common pattern, and the data says it is, average handling time and submission length are your leading indicators. A queue flat in count and rising in minutes-per-item is already flooding.
The honest caveat
The authors are careful, and it is worth being careful with them: their methodology supports no causal or quantitative claims, some volume increases predate ChatGPT, and observed operational impacts so far are moderate rather than catastrophic. This is not a crisis. It is a slow shift in a load assumption nobody wrote down, which is more dangerous than a crisis, because there is no incident to trigger a response.
The strategic point stands regardless of how fast agent capabilities advance. If your service works because submitting to it is annoying, you do not have a capacity plan. You have a side effect doing a capacity plan’s job, and it is being competed away.
Working on this?
REPTILEHAUS builds intake and processing systems that hold up under load: structured submission interfaces, identity and verification flows, AI-assisted triage pipelines, and the DevOps to keep them observable when volume moves. If your queue is growing faster than your headcount and you would rather redesign than add friction, get in touch.
Source: Schmitz, C., Hammond, L., and Chan, A. (2026). “Characterizing Agentic Flooding of Government Services.” arXiv:2608.16603. To appear in the proceedings of the 9th AAAI Conference on AI, Ethics, and Society.
📷 Photo by Wonderlane on Unsplash
