Here's a real failure mode we hear about, in different forms, almost every month:
A team ships an agent that processes incoming support tickets. It works well in testing. In production, an edge case causes the agent to misclassify a ticket, ask itself a follow-up question, get a slightly wrong answer, and ask another follow-up. By the time someone notices four hours later, the agent has made 27,000 API calls to a downstream service and run up a $47,000 LLM bill that requires a Slack thread with finance and a separate one with legal.
The technical fix is straightforward. The team adds a check, ships a hotfix, moves on. The harder question is: why didn't the platform catch this?
Why global rate limits aren't enough
Most systems have some rate limit somewhere. The usual pattern is a global limit at the gateway: 1000 requests per minute, 10000 per hour, something like that. This protects the platform from total saturation, which is necessary, but it has two problems for agentic workloads:
Problem 1: it doesn't differentiate well-behaved agents from misbehaving ones. A global limit is a shared budget. One looping agent can consume all of it before any other agent gets blocked. The legitimate agents — the ones that were going to do useful work — start failing too.
Problem 2: the threshold is usually wrong. Set it low enough to catch a runaway agent and you'll throttle legitimate bursts (a daily batch job, a customer onboarding flood, a model evaluation run). Set it high enough to allow legitimate bursts and a runaway agent has plenty of room to do damage before tripping the limit.
The fix is per-agent rate limits with operationally sane defaults. Each agent gets its own budget. A misbehaving one gets blocked at its own ceiling without affecting anyone else.
What we built
Helix provides per-agent rate limiting designed for the actual ways agents misbehave:
- Per-agent budgets, not shared ones. Each registered agent has its own ceiling, set at registration. A loop in one agent stops at that agent's ceiling — the others keep working.
- Honest limits across boundaries. An agent that maxes its budget at the end of a window doesn't get to burn another full budget the moment the window changes. The limit is what it says.
- Different classes for different operations. Read-heavy agents don't get throttled at the rate of write-heavy ones. An agent legitimately reading a lot isn't capped by the kind of work it's not doing.
- Visible in real time. Operators can see, per agent, how close each one is to its ceiling and how its rate has been trending. No surprise saturation events.
- Safe by default for sensitive operations. When the platform is genuinely uncertain about an agent's current consumption, security-sensitive operations get held rather than waved through.
The aggregate effect: a misbehaving agent self-throttles. The blast radius of any single agent's mistake is bounded by its own ceiling, not by your AWS quota.
Why this matters more for agents than for traditional services
Three reasons:
Speed. A traditional service does what its caller asks. An agent decides what to ask next. When the decision-making goes wrong, the calls don't slow down — they accelerate, because the agent is "trying harder" to make progress.
Cost. Agent calls aren't free. Each one might consume LLM tokens, downstream API quota, compute, storage. A loop that makes 10,000 wrong calls is 10,000x more expensive than the right number.
Recovery. A service in a bad state usually crashes or stalls. An agent in a bad state often keeps going, producing confident-but-wrong output and making more calls. Without external limits, there's no natural circuit-breaker.
Per-agent rate limits are the external circuit-breaker. They're not optional infrastructure for agentic systems — they're the same category of "load-bearing" as connection pools and request timeouts.
What this is designed to produce
The patterns per-agent ceilings exist to create — the ones we'd expect any team running them to see:
- A runaway agent gets caught before it eats the rest of the budget. The first time an agent hits its limit, it's usually a bug. The platform contains the damage and surfaces the alert.
- Experiments stop being scary — once you set the ceiling. Give a new agent its own per-agent rate limit at registration and a runaway can't quietly eat the rest of the budget. Changing that ceiling is a deliberate, audited action — not something that happens by accident on the way to production.
- Finance stops being surprised. Predictable per-agent ceilings translate directly into predictable per-agent costs. Surprises stay small.
What to ask your platform team
Three questions:
- If a single agent goes into a loop right now, how many calls does it get to make before something stops it?
- When one agent hits its limit, do the other agents continue to work, or does one bad actor take everyone down?
- Can you tell me, today, what each agent's rate-budget consumption has been over the last hour?
If the answers aren't reassuring, the math is going to show up in your AWS bill or your downstream-vendor bill long before it shows up in your incident channel. A platform without per-agent ceilings is a platform that fails finance before it fails ops.
Go deeper
Per-agent ceilings, scoped tokens, and the rest of the agent control plane — start with the SDK quickstart at helix.tools/#docs.