Rate Limiting and Abuse Control for Agent-Generated Support Email

Ticket volume is up 4x on Monday morning. No outage, no campaign, no product launch. CSAT is unchanged, first response time is fine, and every single one of the extra tickets is beautifully written.

Somewhere in that queue is one customer whose assistant is checking the status of sixty open orders every fifteen minutes.

Agent traffic doesn't look like human traffic

The first thing to understand is that this isn't a volume problem with a familiar shape. It's a different distribution entirely.

People batch. Someone with three questions about a delayed order writes one slightly rambling email containing all three. An agent does the opposite: it decomposes. The same underlying need becomes six or ten precise, single-intent queries, because that's what produces clean answers it can act on. One human intent, ten tickets.

The timing changes too. Human queues have a diurnal curve you can staff against. Agent traffic arrives at 3 a.m. in bursts, driven by whenever the customer's workflow happens to fire.

And then there's retry behaviour. A person who gets an unhelpful reply sighs and waits until tomorrow. An agent that gets an unhelpful reply writes back in ninety seconds with a rephrased question, and keeps doing so. The cruel part is that these emails are exactly the kind your automation handles well: unambiguous, correctly formatted, high confidence. So your resolution rate looks great while your cost per customer quietly triples.

Throttling first is the wrong instinct

The reflex is to find the noisy sender and cap them. Resist it for a moment.

That agent is a legitimate customer using the interface they've chosen. Blocking it is closer to refusing to answer the phone because a customer called from a different handset. The customer doesn't experience a rate limit as protection of your infrastructure; they experience it as your company being unable to answer questions about their orders.

The right frame is fair use, not defence. You're designing a budget that lets ordinary agent behaviour through and makes pathological behaviour expensive, and those two things need to be separable before you write a single limit.

Pick the right unit to limit

Most teams reach for messages per hour. It's the easiest thing to count and close to useless, because messages aren't what costs you anything.

What costs you is resolution work and, above that, actions taken against your systems. Ten status lookups against a cached order record cost roughly nothing. One refund initiation costs money and carries risk. A limit that treats them identically is calibrated wrongly in both directions at once.

Limit along these axes instead:

• Action class. Read-only lookups get a generous ceiling. Writes such as refunds, cancellations, address changes and plan modifications get a tight one, ideally tight enough that hitting it is itself a signal worth investigating.
• Account, not sender. The meaningful subject is the account holder the agent acts for. One agent platform might serve thousands of your customers, so a per-domain limit punishes all of them for one bad actor.
• Agent identity. Where a verified agent card exists, reputation can attach to it and limits can loosen for agents with a clean history.
• Intent, deduplicated. Six queries assembling one answer about one order should count once. This is harder than it sounds and it's the one that actually controls cost.

That last axis is worth dwelling on, because it's where the economics live.

Deploy the controls in this order

1. Identify agent traffic before you do anything else. Sender domain patterns, signed agent cards, message structure, timing signatures, and the tell-tale absence of typos. You can't set a budget for a population you can't count.
2. Measure a baseline for a full cycle. Two weeks minimum, ideally through a billing period. What does normal agent behaviour look like for your product? A logistics customer's agent checking shipments hourly may be entirely reasonable.
3. Set budgets per account, generously. Start at something like 5x your observed p95 for that account tier. You are looking for the pathological case, not the enthusiastic one.
4. Shape before you reject. Cache aggressively and serve repeat queries from the cache. Collapse multiple queries in a window into one digest reply. Answer the question the agent will ask next, unprompted, which cuts round trips more than any limit does.
5. Return machine-readable backpressure. When you do have to slow someone down, say so in a form the agent can parse and act on.
6. Escalate to the account, not to a block. Sustained overage is a conversation with a customer about a better integration path, not a silent wall.

What backpressure looks like without an HTTP status code

Email has no 429. There's no Retry-After header the sender's agent will honour, and there's no standard for this yet.

What works is a structured block in the reply body carrying four things: the fact that a limit was hit, the specific limit and window, an absolute reset timestamp, and a cheaper alternative endpoint. That last one matters most. An agent hammering your inbox for order status is usually doing it because nobody offered it a better option. Pointing it at a webhook or API path converts a cost centre into a subscription, and the agent will almost always take it, because polling an inbox is nobody's preferred design.

Abuse that isn't about volume

Rate limits catch the loud problems. A few patterns are quiet and matter more.

Policy enumeration. An agent systematically probing for the most generous path through your refund rules: rephrasing the same request as damage, then as late delivery, then as wrong item, watching which framing gets approved. Individually each message is legitimate. The pattern is not. Detection is a per-account rule about repeated similar requests with rotating justifications, not a volume threshold.

Injection dressed as a query. Instructions aimed at your agent embedded in what looks like a customer question. Prompt injection now tops the OWASP LLM risk list and grew roughly 340% year over year, and support email is the ideal delivery channel for it.

Identifier guessing. Sequential or near-sequential order IDs across a small number of messages, testing which ones return data. Low volume by design, so a rate limit set for polling behaviour will never see it.

Channel amplification. One complaint fanned across email, chat, WhatsApp and a review site simultaneously by an agent instructed to escalate. Not malicious, genuinely disruptive, and invisible unless you're deduplicating across channels.

The pricing problem nobody has solved yet

Here's the part that should worry a CX budget holder more than the infrastructure question.

Per-resolution pricing has settled into a rough band of $0.50 to $2.00 across the vendor market, and hybrid models are now the de facto standard at around 41% of vendors. That pricing was designed for a world where one customer intent produced one ticket. Agent traffic breaks the assumption. If ten decomposed queries about one delayed order bill as ten resolutions, you're paying ten times for the same piece of customer value, and the customer's satisfaction hasn't moved.

The definition of resolution already varies enough between vendors to swing total cost of ownership by 30-60%. Agent traffic widens that gap considerably, which makes it a live question during procurement rather than a footnote. Three things to pin down in writing before you sign:

• Whether multiple messages resolving one customer intent bill as one unit or several
• Whether agent retries after an unclear reply are chargeable
• Whether traffic you've explicitly rate limited still counts as a resolution

Our breakdown of how AI email support pricing models compare goes into the wider structures, and the cost per email ticket benchmarks give you a baseline to test any quote against. Honestly, the vendors who define resolution at the intent level rather than the message level are the ones who've thought about this at all.

How you'd know any of this is working

Standard support dashboards will not tell you. Tickets per day, first response time and CSAT all get muddied the moment a meaningful share of your queue is agent-generated, because the denominators change underneath you. Segment agent traffic from human traffic and track four things on the agent side specifically:

• Messages per resolved intent. The core number. If one customer question still takes eight messages after you've shipped caching and richer replies, the replies aren't answering the follow-up.
• Retry rate within an hour of a reply. A clean proxy for whether your answers are actually usable. Retries should fall when structure improves and rise when a template regresses.
• Write actions per account per week. Watch the tail rather than the average. A single account at the 99th percentile is worth a manual look every time.
• Conversion to a better channel. Of the agents you offered an API or webhook path to, how many took it? If that number is low, the alternative you're offering isn't good enough.

Run all four against a baseline before you deploy any limits. Otherwise the first genuine spike is indistinguishable from a control that's misfiring, and you'll spend a week arguing about which one it was.

What not to rate limit

Blanket limits do real damage in cases that look identical from a metrics dashboard.

• Outage bursts. When your service is down, everyone's agent asks at once. That's the system working. Suppress limits during declared incidents or you'll turn an outage into an outage plus a support blackout.
• Accessibility use. A meaningful share of agent traffic comes from customers who use an assistant because typing, reading or processing email is genuinely difficult for them. Their volume looks abnormal because it is, and limiting it is a discrimination problem, not a cost problem.
• Legitimate B2B bulk. A freight forwarder tracking 400 shipments is not abusing you. They need a different integration, and the correct response is a sales conversation.
• Seasonal peaks you already plan for. Anything you'd handle in Black Friday load planning should be exempted by calendar rather than discovered by a throttle at 2 a.m.

Where Robylon fits

Robylon's email agents classify inbound sender type as part of triage, so agent traffic can carry its own budgets, caching behaviour and action limits without touching how human email is handled. Deduplication happens at the intent level rather than the message level, which keeps decomposed agent queries from inflating both the resolution count and the bill. Write actions sit behind separate, tighter limits than reads, and sustained overage surfaces as an account-level signal for your team rather than a silent drop.

Ready to handle agent traffic without paying ten times for one customer intent? Robylon AI resolves 60–80% of customer emails autonomously with agents that take action across Zendesk, Gmail, Shopify, Stripe and 60+ other integrations. Start free at robylon.ai