Unleash the 429

For most of the SaaS era, software was limited by its users.

People clicked buttons, filled out forms, waited for pages, switched contexts, went to sleep, and came back the next day. The user experience might have helped someone complete a task efficiently—or made the same task painfully inefficient—but either way, the human was a natural governor on throughput.

Behind those interfaces were APIs. They could be designed and capacity-planned around traffic that was ultimately human-shaped. Rate limits mattered, but the interface itself paced demand.

Agents remove that governor.

The interface is getting thinner

The user experience of an agent can be a single prompt. Behind it, the agent may reason, plan, call tools, retry failures, explore alternatives, and loop until it reaches an outcome. Whether those tools arrive through MCP or traditional APIs does not change the underlying reality: one human instruction can produce an enormous number of machine requests.

We can no longer assume that one user means one session, one workflow, or a predictable number of calls. The unit of demand is shifting from people using software to machines doing work.

That brings an old HTTP status code to the center of software design:

429 Too Many Requests.

The concept is hardly new. What is new is the strain being placed on it.

For a software service, the 429 may be its most critical lever. It protects capacity, cost, reliability, fairness, and sometimes the service itself. At the same time, the 429 may be its most limiting lever. It defines how much useful work an agent is allowed to do.

Both things are true.

A limit is now a product decision

Humans often tolerate friction. We wait for a spinner, return later, or accept that a service is slow.

Agents behave differently. An agent can back off, retry, parallelize, search for a workaround, choose another tool, or move to another service entirely. A rigid rate limit does not merely slow an agent down. It can make the service irrelevant to the task.

This changes the responsibilities on both sides of software development.

As system architects, we must anticipate surges and load. The cloud taught us to design for elasticity, but agents raise the stakes: they can run continuously, fan out, and create loops whose demand compounds faster than human traffic ever could.

As product managers, we must be careful not to bottleneck valuable work with limits inherited from the human SaaS era. A rate limit is no longer only an operational safeguard. It shapes whether a product can participate in an agentic workflow at all.

Unleashing the 429 does not mean abolishing limits. Capacity and money are real. Abuse is real. Runaway loops are real. It means replacing a blunt, static ceiling with an intelligent control surface: explicit budgets, elastic capacity, queues, priority, idempotency, metering, useful Retry-After signals, and pricing that lets legitimate demand expand.

The best 429 is not a wall. It is a negotiation.

The demand investors may be missing

Many people look at markets through a zero-sum lens. Investors are trained to search for the reason growth will slow, demand will move elsewhere, or a cycle has reached its top.

That framing may miss what agents are doing to software demand.

Agents do not merely redistribute existing clicks. They can create entirely new volumes of useful activity. Every plan, tool call, retry, validation step, and follow-up action consumes infrastructure. A wave of 429s can certainly reveal poor engineering or bad economics. But it can also reveal something more interesting: machines are trying to do more work than our systems are prepared to accept.

That is a new strain of demand.

The constraint may not be whether people want the software. The constraint may be whether the software can affordably absorb everything people now want their agents to do.

October 2026

As I write this in October 2026, services across the software landscape are being forced to scale for this new reality. The strategies for handling the 429 increasingly necessitate the cloud, elasticity, and a much more deliberate relationship between capacity and product design.

There is a difficult balance here. Protect too little and agents can overwhelm the system. Protect too much and they will route around it.

The companies that learn to unleash the 429—to turn hard ceilings into elastic, observable, economically sustainable throughput—will be positioned to survive this transition. Those that do not may find that agents simply stop choosing them.

Human SaaS was designed around attention. Agentic software must be designed around work.

Unleash the 429.