Agentic Flooding: How to Protect Your Internal Systems from AI Swarms

What is agentic flooding, and how does it threaten internal systems?

Agentic flooding is a surge in the volume or complexity of requests a system receives because AI agents are generating and submitting them cheaply, faster than the system was built to handle. The term comes from researchers studying government services, where AI agents now draft benefit appeals, tax objections, and freedom-of-information requests at essentially zero marginal cost. The same dynamic is starting to show up inside companies, where internal copilots and task agents hammer APIs, ticketing systems, and support queues that were designed for human pacing, not machine pacing.

If you run internal tools, this is not an abstract policy problem. It is an infrastructure problem headed for your help desk, your internal APIs, and your on-call rotation.

Where does the term agentic flooding come from?

Researchers at the Hertie School's Centre for Digital Governance, along with the Cooperative AI Foundation and GovAI, coined "agentic flooding" to describe surges in government service demand driven by AI. They built a dataset of 84 documented cases across 11 jurisdictions where officials or credible outlets attributed a demand spike to AI use, spanning tax objections, benefits appeals, planning consultations, and freedom-of-information requests. In 87% of those cases, the mechanism was simple: an LLM cheaply generated legally sophisticated text, which a human then submitted through an ordinary web form. No browser automation, no elaborate tool use. Just cheap, competent writing at scale.

The pattern is visible outside government too. Some German social courts attribute a 55% year-on-year rise in 2025 caseload largely to AI-generated claims. The UK's Department for Work and Pensions has seen benefit appeals climb more than 60% since AI benefit-drafting tools first appeared in 2022, well before autonomous agents entered the picture. Australia has considered reintroducing fees for freedom-of-information requests specifically because of a wave of AI-assisted submissions. The Economist has started describing this as a force capable of straining state administration.

None of this is really about government specifically. It is about any system that was designed assuming a human, with human patience and human writing speed, sits on the other end of the request.

Why does agentic flooding matter for internal systems, not just citizen-facing ones?

Swap "government service" for "internal API" or "support queue" and the mechanics hold. AI agent workloads break the assumptions traditional rate limiting was built on in three specific ways: cost heterogeneity between cheap and expensive model calls, wildly variable request sizes within the same session, and recursive amplification where one user action triggers dozens of downstream calls. A single rate-limit bypass at the entry point can cascade into hundreds of operations within seconds once an agent starts chaining tool calls.

That traffic looks nothing like the load internal tools were sized for. A support workflow that used to see one ticket a day from a human can now see an agent polling a status endpoint every few seconds, retrying on ambiguous responses, and fanning a single task out into dozens of downstream calls without anyone noticing until something breaks.

There are three distinct failure modes worth naming separately, because each needs a different fix.

Quantitative flooding. More requests than before. Researchers found 60% of documented flooding cases involved a rise in request volume. This is largely a rate-limit problem, and it is the easiest to see coming.

Qualitative flooding. Same number of requests, but each one is longer or more complex, because the agent did more homework than a human ever would. Researchers coded 90% of cases as qualitative flooding, and in one case AI-drafted complaint letters ran past 4,000 pages. Internally, this shows up as tickets with exhaustive context dumps or API payloads bloated with speculative data pulled just in case it was needed.

Recursive amplification. The one that actually pages you at 2 a.m. Agents do not make one request, they orchestrate chains: retrieve, validate, retry, chain to the next tool. One user action can quietly trigger dozens of calls, and a single bypassed limit at the entry point compounds fast.

Why do traditional controls fail against agents?

Most internal APIs and ticketing systems carry implicit assumptions that agentic traffic breaks.

Counting requests, rather than counting cost, was a reasonable proxy in the REST era when every call cost roughly the same. AI workloads break that: a prompt routed to a small model might complete in 50 milliseconds, while the same token count routed to a larger model can occupy compute for seconds, meaning two identical-looking requests can differ five-fold in resource consumption. Fixed-window counters also allow boundary surges, where a tenant sends its full quota in the last second of one window and again in the first second of the next, doubling effective load while technically staying within limits. Static, request-per-second rules end up blocking a large share of legitimate agent traffic while still letting expensive, abusive traffic through, since the traffic itself does not look different at the HTTP layer.

What actually holds up against agentic flooding?

The fixes that work are not exotic. They are the same discipline API teams already apply to third-party integrations and multi-tenant platforms, enforced earlier and more strictly.

Rate-limit by cost, not by request count. Token-aware or compute-aware limiting treats a request's actual resource draw as the unit of enforcement rather than a flat count. A token bucket sized to the estimated compute cost of a call, rather than a fixed "one request equals one unit," converts a request limiter into an actual compute limiter, which is the correct unit for agentic traffic.

Isolate tenants and agents with separate rate-limit state. Never share a single counter across tenants or agents. Hierarchical limits, org level, agent level, and user level, prevent one runaway agent loop from exhausting a shared quota meant for an entire team.

Return real backpressure signals, not silent failures. Every rate-limited response should carry a Retry-After header along with limit and remaining-quota headers. Well-behaved agents parse these and back off with exponential delay and jitter; agents that only see a bare rejection, or worse a 200 status with an error buried in the body, tend to retry immediately and compound the load.

Pair rate limiting with circuit breakers, not one instead of the other. Rate limiting enforces fairness and cost governance at steady state. Circuit breakers protect service health when a downstream dependency, like an LLM provider or an internal service, is already degraded, tripping to reject requests outright rather than letting retries pile up against a failing system.

Use queue-based backpressure for async agent dispatch. Rather than pushing every task straight through, let consumers pull work only when they have spare capacity. This is the same pattern message brokers use to prevent one noisy producer from starving everyone else on a shared queue.

Make agent traffic visible as its own category. Tag requests by client type where you can. Without that distinction, a burst of internal automation traffic looks identical to an attack, and a team either drowns in false alerts or misses the real ones.

What audit is worth doing this quarter?

The government-services research offers a useful lens for internal systems too: near-term risk concentrates in services that are complex to use, high-value to complete successfully, and historically protected by friction rather than deliberate design. Inside a company, that maps to workflows like expense approval, access requests, or internal support ticketing, where a slow, annoying process has quietly been doing the job of a rate limiter. Once an agent can fill out that form perfectly and instantly, the friction that used to cap demand disappears, and whatever sits underneath it needs to hold weight on its own.

Start by listing which internal APIs and queues have no real boundary between "can read" and "can act," and which ones assume a human is the one making the request. Those are the systems agentic flooding will find first. This is also where the build-vs-buy conversation gets real: teams standing up their own internal agent workflows need the same access discipline they would demand from a vendor, which is a big part of why orchestrating an internal office of clones requires real infrastructure thinking, not just a prompt and an API key.

A growing number of teams are handling this by putting a managed orchestration layer between agents and the systems they touch, something like Remy, rather than letting every team wire its own agents directly into production APIs with whatever credentials were lying around.