Imagine taking a paper approval form, turning it into a PDF, and emailing it through exactly the same sequence of departments. The form moves more easily, but the business still waits for the same signatures. Digitizing the document has changed one part of the process. The assumptions behind the process remain intact.
I see a similar pattern in how enterprises are approaching AI.
They are trying to fit it into existing processes and workflows. Give employees a tool to write faster, summarize meetings, prepare presentations, or search documents. Then measure how much time they save.
Those improvements have value. My concern is that productivity and speed have become the entire conversation. The organization keeps the same work, the same handoffs, and the same approval structures, while expecting a new technology to produce a fundamentally different result.
What could this workflow look like if we designed it around the capabilities available today?
That is the question I believe business leaders need to spend more time asking.
The gap between capability and organizational readiness
Ethan Mollick describes a capability overhang: a gap between what AI systems can accomplish and what people actually use them to do. His argument is that existing capabilities remain underexplored, even as attention moves toward the next generation of models. Read Mollick's argument in “The Overhang.”
For enterprises, I think that gap has an organizational dimension.
A company may have access to a capable model without giving it the information, tools, authority, or operating environment needed to do useful work. Employees may understand how to ask for a summary but have little understanding of how an agent could carry out several connected tasks.
At the same time, the company may be waiting for AI to become better before reconsidering its processes. That creates a circular problem: it cannot discover what the technology can do because it only permits uses that fit the way work already happens.
This does not mean every company already has everything it needs. Reliability, integration, cost, and security can still be genuine constraints. It means leaders should investigate where the limitation actually sits before assuming it is the model.
The capability gap is conceptual: useful technology becomes business value only when the surrounding organization can put it to work.
Faster tasks can leave the customer waiting
Consider an illustrative customer-service process.
A customer submits a request. An employee reads it, searches several systems, checks a policy, drafts a response, and sends the proposed action to someone else for approval.
Now give that employee AI to draft the response. Writing takes less time. But the customer may still wait because the information is fragmented, the request has been assigned to the wrong team, or an approval sits in a queue.
The writing improvement is real. Its effect on the customer's experience may be small.
Redesigning the process begins with the outcome: resolve an eligible request accurately, with appropriate controls and a clear record of what happened.
Depending on the systems and permissions available, an agent could gather relevant information, identify missing details, and prepare an action. A controlled workflow could allow routine cases to proceed after the required checks, while unusual or consequential cases go to a person.
The human contribution changes. People define the policy, establish limits, examine exceptions, and investigate failures. They also remain responsible for whether the service works for customers.
This example describes a possible design, not a result I am claiming from a particular implementation. It also requires testing. A confident response based on the wrong customer record is still a failure, however quickly it arrives.
A proposed customer-service workflow. Permissions, checks and escalation determine which actions can safely proceed.
Leaders need to understand agents through actual work
In my experience, much of the enterprise conversation still treats AI as a productivity assistant for an individual employee. There is less understanding of what changes when a system can take actions across a sequence of tasks.
An agent can use tools, examine results, and choose subsequent steps toward a goal within its available permissions. That requires a different management conversation from asking someone to use AI when writing an email.
What information can it retrieve? What can it change? How will it recognize that it lacks enough information? Who handles an exception? How do we know the task was completed correctly?
These are questions about how work is organized.
They also help leaders avoid treating agents as the answer to every problem. Anthropic's guidance distinguishes predefined workflows from agents that choose their own steps, and recommends starting with the simplest approach that meets the need. Greater flexibility can bring additional cost and delay. See “Building effective agents.”
A fixed rule may be sufficient for one step. A person may be essential for another. The useful design combines these capabilities around the outcome.
Leaders develop a better understanding by examining a real workflow with the people who perform it. Watch where information is gathered, where judgment matters, where people wait, and where work is repeated. Then test a small part of a different design.
Fear is part of the operating environment
There is another issue I see that cannot be solved with a better demonstration: fear and anxiety about uncertainty, changing roles, and job loss.
It is easy for leadership to describe AI as an opportunity. An employee may hear the same presentation and wonder whether demonstrating a more efficient process will help eliminate their position.
That concern deserves a serious response.
Anthropic's June 2026 Economic Index report discusses earlier interviews in which users reported productivity gains alongside concerns about displacement. Its subsequent survey also found differences in expectations across users. This is evidence from Claude users, rather than a representative picture of the entire workforce, but it illustrates how enthusiasm and concern can coexist. Read the report's discussion of worker perceptions.
I believe leaders need to explain what they are trying to improve, how employees will participate, and how decisions about changing roles will be made. Promising that nothing will change is unlikely to build lasting trust when the purpose of the initiative is to change work.
People need time to learn, opportunities to practise, and a way to report failures without feeling that they are obstructing progress. Their knowledge of exceptions and informal workarounds is essential to designing something that functions outside a demonstration.
If every improvement is immediately translated into a headcount calculation, leaders should consider what incentive employees have to share that knowledge. The organization could lose the cooperation it needs to understand its own work.
Access and accountability make capability usable
A capable agent with incomplete information may produce an incomplete answer. Giving it unrestricted access creates a different problem.
The business has to decide which information is authoritative, which actions are permitted, what evidence is required, and when a person must intervene. These decisions need owners.
In the customer-service example, someone must define which cases qualify for routine resolution. Someone must own the underlying policy. Someone must investigate an incorrect action and decide whether to change the workflow, restrict its authority, or suspend it.
Approvals should have a clear purpose. Some protect an important business obligation; others may exist because the old process could not perform a reliable check earlier. Examining that distinction is part of redesigning the work.
This is why buying access to AI is only one part of adoption. The surrounding investment includes integration, evaluation, staff development, and the ongoing effort to operate the system responsibly.
Start with one outcome and learn from the evidence
I would begin with a recurring business problem that matters enough to measure and is limited enough to test.
First, establish the baseline. Understand the time, cost, error rate, rework, and customer experience of the existing process. Include waiting time between teams.
Second, redesign the workflow with the people doing the work. Identify steps that can be combined, removed, or handled differently. Preserve controls that serve a real purpose.
Third, define the boundaries. Establish data access, permitted actions, escalation conditions, and responsibility for the outcome. Make those boundaries enforceable in the system.
Fourth, test representative cases, including failures. Compare results with the baseline. Include the cost of human review and correction when assessing whether the new approach is worthwhile.
Finally, use the results to decide what happens next. Expand where the evidence supports it. Revise where it does not. Stop if the approach fails to deliver enough value.
A practical starting framework. Greater autonomy depends on demonstrated performance and the consequences of getting the work wrong.
Measure the improvement the business actually receives
The number of employees using AI can help explain adoption. It cannot, by itself, establish whether the business has improved.
For customer service, I would want to know whether customers receive correct resolutions sooner, whether requests reopen, whether complaints increase, and what a successfully resolved case costs after review and correction.
For another workflow, the measures will differ. The principle remains: follow the work through to the outcome, including any burden transferred to another team.
Time saved also needs a destination. Does the capacity reduce a backlog, improve service, or enable work the organization previously could not afford? Leaders should be able to explain how an efficiency gain becomes a business benefit.
I believe the capability overhang presents a practical opportunity for enterprises willing to examine their own assumptions. They can begin by understanding what today's systems do well, involving employees in the redesign, and testing a more useful way of working.
The next model may expand what is possible. The work of turning that possibility into value is already a leadership responsibility.