Your agents will not break the AI stack first. They will break the systems built for human pace
Anthropic's source control, Third Moment's backtests and Databricks' job scheduler hit the same limit: systems sized for people. A framework to audit yours before agent volume arrives.
Listen to this article · 4 min
AI-generated narration of the full article.
Most enterprise AI risk reviews look at the model and the agent: what it can access, what it might say, what it might do. They rarely look at what the agent will do to everything else. This week’s engineering reports suggest that is where the first production problems at scale actually appear.
Anthropic’s merged changes grew from about 2,500 to more than 30,000 a day in four months, and Git’s assumptions broke before its storage did. Third Moment’s research agents burned their budgets polling a three-hour backtest. Databricks’ researchers launched eight times more training jobs once agents ran experiments, and found that slow startups and confusing errors became the bottleneck. None of these was a model failure. Each was a system designed around how people work, meeting software that works differently.
Our view, and it is a view built from these signals rather than a measured law: the first systems to fail under agent adoption are the ones sized for human tempo. People act a few times an hour, tolerate waiting, read ambiguous errors with judgment and are limited in number. Agents act continuously, never tire of retrying, read errors literally and multiply on demand.
A tempo audit
The practical response is an audit of the systems agents will touch, done before the volume arrives. For each one, write down the assumption it makes about its users, what breaks when that assumption fails, and the first signal you will see.
| Assumes | Breaks at agent pace as | First signal | |
|---|---|---|---|
| Source control | Occasional commits, full local copies | Clone and fetch load, lagging mirrors | CI minutes per merged change rising |
| Code review | A person reads every change | A queue nobody can clear, or rubber stamps | Median wait for review growing faster than output |
| CI and merge queue | Merges arrive one at a time | Serialized queues that never drain | Queue time exceeding build time |
| Job schedulers | Patient users who read errors | Retries, polling and misread failures | Launch time and retry rate per job |
| Approval workflows | A few requests a day per approver | Approval fatigue; approval stops meaning review | Approval time collapsing to seconds |
| Quotas and licenses | Limits per person or seat | Throttling, surprise bills, shared identities | Rate-limit errors and spend spikes per agent |
Two rows deserve special attention, because they fail quietly. A source control system under load gets slow and someone notices. A review process under load keeps working: approvals still happen, just without anyone reading. An approval that takes four seconds is a signature, not a review. That is the cost we described in verification as the new bottleneck, seen from the infrastructure side.
Three design moves that help everywhere
Replace waiting with signals. Polling is the agent equivalent of a person refreshing a page, multiplied by thousands. Completion callbacks, event notifications and durable waits remove it. Third Moment’s fix was faster jobs; the more general fix is never making an agent ask “is it done yet?”
Pin what agents run through. Agents trigger pipelines far more often than people do, so anything that can change underneath a pipeline matters more. GitHub’s new workflow lockfiles, in public preview since October 14, pin Actions and reusable workflows, including transitive dependencies, to specific commits while workflow files keep their existing references, and administrators can require them by policy. A lockfile does not make a pinned commit safe, but it stops a dependency from changing after review without a change in your repository.
Give agents their own quotas and identities. Shared service accounts and per-seat limits hide who is consuming what. Per-agent quotas make the load visible and the limit a decision, which is the agent file with a budget we argued for earlier.
Run the audit before the pilot scales
The cheapest moment to find a tempo problem is before a successful pilot gets copied across the company. A useful rule: when a team proposes scaling an agent tenfold, ask which of the six systems in the table it will load, and who owns each. If nobody can answer, the scaling plan is a model plan, not a production plan.
Anthropic’s advice to other companies was to bring Scion’s ideas to Git rather than adopt Scion. The same applies here. Nobody needs to rebuild their infrastructure for agents in 2026. Everyone deploying them needs to know which assumptions about human pace their systems are quietly relying on, and which ones agents are about to retire.