The productivity argument for AI is fairly intuitive. If an engineer with agents can do substantially more work than an engineer without them, the company has gained capacity.
What happens next is less obvious.
The company could decide it needs fewer engineers to produce the same amount of work. Or it could keep spending the same amount on engineering and become more ambitious.
The second option sounds like pure upside. If the people you already employ can suddenly accomplish substantially more, why wouldn't you just do more?
Because doing more is actually hard.
Individual Productivity Isn't Organisational Productivity
AI can increase the amount of work an individual can attempt without increasing an organisation's ability to absorb that work at the same rate.
There is already some evidence of this distinction. A six-month randomised experiment involving 7,137 knowledge workers found that access to generative AI changed behaviours people could alter independently. Frequent users spent substantially less time on email and completed documents somewhat faster. But the researchers didn't find a significant change in time spent in meetings — behaviour that requires other people to change with you.
That's a useful distinction. An engineer might be able to produce substantially more code. That doesn't mean a product organisation can identify substantially more valuable things to build, or that a team can review changes at the same increased rate, or that customers can absorb substantially more change.
The limiting factor moves.
A 2026 field experiment across 515 startups gets even closer to this problem. The researchers call it the mapping problem: discovering where and how AI actually creates value within a firm's production process. Companies given information about how other firms had reorganised production around AI discovered 44% more AI use cases and subsequently completed more tasks, acquired more paying customers and generated more revenue.
The interesting part isn't just that AI produced gains. It's that finding and reorganising work around those gains was itself a problem to solve.
Delegation Gets Complicated Quickly
Consider something fairly mundane: I ask a company-provided coding agent to make a change.
It has access to the repository because my company gave it access. It may have instructions supplied by the organisation. It can use tools the organisation has made available to it. I give it a task, review the result and merge the change.
Then it causes an incident.
Who is responsible?
The simplest answer is me. I delegated the work and ultimately accepted it.
But change the scenario slightly. What if the agent can merge its own changes? What if another agent reviewed them? What if the mistake came from centrally supplied instructions rather than my prompt? What if another engineer later builds on the agent's output without knowing how it was produced?
None of these questions make agents unusable. They demonstrate that using them creates work around the work.
Someone has to decide what can be delegated, what requires review, which permissions an agent should have, when it should escalate, how its actions are recorded and who ultimately owns the outcome.
This isn't entirely hypothetical infrastructure. Workday's Agent System of Record, for example, is explicitly designed around registering agents, defining their roles and responsibilities, governing their access and tracking their impact.
As agents become more capable, some of the work shifts from performing tasks to designing the system in which those tasks can safely be delegated.
We've Seen This Kind of Problem Before
This isn't the first time organisations have discovered that improving the technical part of a work system doesn't automatically improve the whole thing.
Research into British coal mining in the 1950s helped establish what became known as sociotechnical systems theory. Researchers studying the introduction of new mining technology found that outcomes depended on the relationship between the technical system and the social organisation around it. Changing one while ignoring the other could make the overall system worse.
The analogy to AI shouldn't be stretched too far. A coding agent is not mining equipment and a software company is not a coal mine.
But the underlying observation still seems useful.
AI is changing one part of the work system extraordinarily quickly. It changes how much work a person can attempt, what can be delegated, where judgement is applied and increasingly who or what can act.
The rest of the system has to adapt around that.
The Work Hidden Inside the Efficiency Gain
Once you look at AI adoption this way, a lot of apparently separate questions start to look related.
How much should an employee be expected to review before accepting an agent's work? What happens when someone doesn't trust an agent their organisation expects them to use? How should an organisation monitor an agent's behaviour without turning that monitoring into surveillance of the person using it? When should an agent be allowed to act autonomously? Who decides whether it is behaving in a way the organisation actually wants?
There are questions about people too. Some employees will eagerly change how they work. Others won't. Some resistance will come from unfamiliarity, but some will come from reasonable disagreements about quality, judgement, privacy, craft or what parts of their work they are willing to delegate.
I'm not trying to answer all of those questions here.
Their existence is the point.
The difficult part of adopting AI isn't limited to making the technology work. Organisations have to change how work is delegated, reviewed, coordinated and understood around it.
That is significant work.
Capability Is Moving Faster Than the System Around It
Microsoft's 2026 Work Trend Index provides a useful measure of the gap. In its survey of 20,000 AI users across ten countries, organisational factors such as culture, manager support and talent practices were more than twice as strongly associated with reported AI impact as individual factors such as mindset and behaviour.
Only 19% of AI users in the study had both high individual capability and high organisational readiness. Another 10% had developed strong individual capability but lacked the organisational conditions to apply it.
Microsoft describes this as a gap between what employees can do and what their organisations are built to support.
That seems close to what I'm experiencing from the inside.
If an engineer can do twice as much, the organisation doesn't automatically get twice as much value. It gets the capacity to attempt more.
Turning that capacity into something useful still requires deciding what to do with it and building a work system capable of supporting it.
This is where management becomes important. In the next essay, I look at the same transition from the manager relationship: agents may automate some management work while the difficulty of changing how people work makes good management more valuable.
There is simply more change to manage.
And there is another question behind both essays. If agents themselves are becoming participants in these work systems, what can we borrow from the structures humans already use to make imperfect intelligence reliable? That's the thread I pick up in Agents Get Better by Becoming More Human.
Some of these problems will eventually become mundane. We will develop conventions, tooling and organisational patterns that make them easier. Things that currently require explicit thought will become assumptions built into how companies operate.
We're not there yet.