Agent era demands extremely robust software

People use applications at a human pace: they read a page, click a button, wait for a response, and decide what to do next.

An agent can make several API calls, start parallel subagents, review their results, and repeat the cycle before its user has finished reading the first response. For the services handling those calls, that means more requests arriving in sharper bursts and with more concurrency.

In the agentic era, its easy to put systems under traffic they may never have been designed for.

GitHub is probably the clearest example of a service already affected by this kind of load.

GitHub

GitHub has had availability problems as agentic development workflows have grown sharply. Its CTO wrote in April that the team had moved from planning for a 10x capacity increase in October to designing for 30x capacity in February.

GitHub’s COO projected an annualized pace of 14 billion commits for 2026, compared with one billion in 2025. This growth is not isolated to commits, it also includes repository creation, pull requests, API use, and CI runs, which agents can spawn much faster than people.

This has triggered repeated reliability problems, some of which connects directly to the sharp growth in agentic activity. These have affected core services and have massively reduced some developers confidence in the platform.

Agents change how load arrives

Sam Altman recently put the scale of this change in useful terms. In 2020, OpenAI’s heaviest token user consumed about 100k tokens a month, which he said seemed ludicrous at the time. He now puts the worldwide average at roughly the same number, while OpenAI’s current leader uses hundreds of billions of tokens each month. Token count is an imperfect metric, but it shows why forecasts based on historical usage and human interaction are no longer completely reliable.

Agents change more than the number of requests. When a person opens a pull request, they normally wait for CI and peer feedback before acting again. An agent can create several at the same time, ask other agents to review them, check the results, make changes, and start the cycle again. A task that once involved a few steps can now create a large amount of work across many services.

This becomes more dangerous when something goes wrong. Agents often retry until they get an answer, so a small failure can quickly create even more traffic.

Prepare the limits before needing them

Not every project needs to prepare for millions of users, but it should know what happens when an automated client sends far more work than expected. Important actions should be safe to repeat, and the service should be able to slow clients down, queue work, or clearly reject it when it is under pressure.

Monitoring and tests should cover this kind of traffic too. It is useful to know which agent is making calls, how often it retries, and whether work is building up, then test what happens when several agents try the same thing at once.

The ease of producing software has increased the need to design it well.