Your Organisation Added Eight Agents. It Did Not Add Anyone to Watch Them.

The average number of AI agents deployed per organisation rose from five in early 2025 to thirteen by April 2026. In Salesforce's dataset, seven in ten customer service sessions are now handled autonomously.

Those are adoption numbers and they get reported as good news. The operational reading is different: capacity roughly tripled while the number of people responsible for knowing whether that capacity is behaving correctly stayed where it was.

The cost is showing up in people

Harvard Business Review published a piece in March 2026 coining the term brain fry for the specific fatigue of supervising systems that move faster than a person can track. In their study, 88% of heavy AI users reported increased feelings of burnout.

That figure deserves more attention than it has had, because it is measuring the thing that limits how far any of this scales. The constraint on an agent fleet is not compute and it is not model quality. It is the number of hours of competent human attention available to check it, and that number is fixed.

Supervising thirteen systems is not thirteen times harder than supervising one. It is worse than that, because the failures interact and because a person cannot hold thirteen sets of expected behaviour in their head at once. This is a well understood problem in every other field that runs automated processes, and software is currently rediscovering it.

“The constraint on an agent fleet is not compute and it is not model quality. It is the number of hours of competent human attention available to check it, and that number is fixed.”

Why the obvious fix does not work

The obvious fix is to hire someone to supervise. Most organisations will not, because the entire business case for the agents was that headcount would not need to rise, and asking for a supervisor undermines the case that got the project approved.

So the supervision gets distributed. It lands on the operations people who were already accountable for the process, as an unnamed addition to their existing job, which is exactly the pattern the burnout figure is describing.

The constraint on an agent fleet is not compute and it is not model quality.

The opening this creates

I wrote earlier about the oversight layer around agents as a product category. The supervision data sharpens what that product has to do, and it is not what most people would build.

The instinct is to build a dashboard. A dashboard adds to the supervision load rather than reducing it, because it is one more surface a tired person has to check. What reduces load is the opposite: a system that stays silent unless something needs a human, and that is specific enough about what needs attention that the person does not have to reconstruct the context themselves.

That means the product is mostly a set of rules about what counts as abnormal in a particular industry, wrapped in the smallest possible interface. The rules are the hard part and they are not general. What counts as an agent behaving oddly in claims processing has nothing to do with what counts as odd in scheduling.

The question to ask this week

If agents are running near you, find out how many. The answer is often higher than the person you ask expects, because they arrived one at a time inside tools that were bought for other reasons.

Then ask who would notice if one of them started getting worse. If the answer is nobody, or if it is a name attached to somebody already fully occupied, you have found both a risk your employer is carrying and a problem worth solving properly.

See audit trails are a feature for the record-keeping half of this, and the operator track for how this fits a career spent inside processes.