AI Speeds up Work but Rarely Grows Revenue

Brynjolfsson, Li, and Raymond ran a field study across more than five thousand customer support agents. Agents with access to a generative AI assistant resolved around fifteen percent more issues per hour. Newer agents gained the most, reaching thirty-four percent faster resolution. Customer sentiment improved. Agent retention improved. Revenue did not move.

That last sentence is the one worth sitting with.

The time went somewhere, just not where it needed to go

The gains in that study are not small. A thirty-four percent speed increase among newer agents, sustained across a full support function, should in theory reduce cost per ticket or absorb more volume without new hires. Neither outcome requires a strategic initiative. The math looks automatic.

But the research identifies exactly where the freed time went when no one decided what to do with it: into more of the same low-value work, or into organizational friction. Agents resolved tickets faster and then took the next ticket in the queue. The queue did not shrink. Revenue-generating work did not increase. The firm got faster at the same thing it was already doing.

This is not a story about AI failing. It is a story about what happens when you speed up a step inside a workflow without changing what the workflow produces.

The 1970s ran this experiment already

The IT productivity paradox is the most inconvenient fact in technology adoption history. Computers spread across U.S. firms for roughly two decades, from the early 1970s through the late 1980s, while aggregate productivity growth slowed. The firms were not misusing computers. Workers were genuinely faster at the tasks computers touched. The output of those tasks simply did not connect to firm-level performance in any measurable way.

The recovery came in the 1990s, when firms redesigned work around what computers made possible. Not when adoption crossed a threshold. Not when enough workers were trained. When the workflows changed.

The business process reengineering movement of that decade is not remembered fondly, and for good reason. A lot of it was consulting theater. But the underlying observation was correct: the firms that captured productivity gains from IT were the ones that reorganized decision rights, roles, and measurement around end-to-end outcomes rather than isolated task speed.

Generative AI is running the same experiment on a faster timeline.

When 34% faster agents didn't move the revenue line

The reasonable counterargument to all of this is that scale makes redesign unnecessary. If enough workers get thirty-four percent faster, the capacity release is automatic. You do not need a plan for freed-up time because the economics sort themselves out. The OECD synthesis of consultant data shows twelve percent more tasks completed, twenty-five percent faster completion, and more than forty percent higher quality scores. Numbers that large should show up somewhere in firm performance, even in noisy macro data.

They do not. The OECD synthesis documents macro-level output and profitability as modest or inconsistent despite those micro-level gains. Flat profitability is not a measurement artifact. It is a firm-level outcome, and the research attributes it specifically to where freed time goes, not to any deficiency in what AI produces.

The scale argument also collides with the IT paradox timeline. If scale and time were sufficient, the paradox would not have lasted two decades. Computers were genuinely widespread by the early 1980s. The gains arrived when firms changed the work, not when adoption reached some critical mass.

I find the scale argument genuinely appealing, which is why I think it is dangerous. It is the reasoning that lets you deploy a tool, watch the speed metrics improve, and conclude the revenue line will follow eventually. It gives you permission to not change anything.

What the OECD data actually shows

The OECD synthesis is worth reading carefully because it documents the same decoupling at a different level of the organization. Consultants complete more tasks faster at higher quality. That is the micro-level result. The macro-level result, across executive surveys and aggregate output measures, is modest or inconsistent gains in profitability and growth.

The McKinsey and Bain guidance cited in the research makes the mechanism explicit: firms need to reassign freed capacity toward higher-value activities. Not as a philosophical preference, but as the specific action that closes the distance between task speed and firm performance. If a consultant completes a deliverable twenty-five percent faster and fills the remaining time with more of the same deliverables at the same billing rate, the firm's revenue per consultant does not change. If that time moves to business development, client expansion, or work the firm previously declined because it lacked capacity, the economics shift.

The difference is not the AI tool. The difference is what you decided to do with the hours it freed.

What founders are actually measuring

Most founders measuring AI ROI are tracking the wrong thing. Task completion speed is easy to measure and satisfying to report. It shows up in demos, in quarterly reviews, in conversations with investors. A support team resolving fifteen percent more tickets per hour looks like a win on every dashboard built to capture operational efficiency.

The number that matters is what happened to revenue, capacity, or output per employee in the six months after deployment. If those held flat while task speed rose, the freed time went somewhere that did not compound. Finding where it went is the diagnostic step most teams skip.

The research does not suggest AI is oversold at the task level. The gains Brynjolfsson and colleagues documented are real and reproducible. The question is whether your org has an explicit answer to what a support agent, a consultant, or an engineer does with the thirty minutes per day your AI tool returned to them. If the answer is "more of the same work," you have purchased speed inside a closed loop.