Enterprise AI Is Entering Its Tool Age

Enterprise AI is entering its Tool Age.

Jim Womack used that phrase to describe what happened during the Lean wave that took off in the West in the late 1980s and early 1990s. Companies learned 5S, kanban, A3s, value stream mapping, and kaizen. The tools were useful. The easier mistake was copying the visible practices without changing the management system underneath them.

I think we are starting to do the same thing with AI seats. Give everyone ChatGPT. Give everyone Claude. Run prompt training. Track weekly active users. Celebrate adoption.

I am not dismissing any of that. The task-level research is pretty convincing. In one large field study, customer support agents using generative AI increased productivity by about 14 percent on average, with much larger gains among newer and lower-skilled workers. Other experiments with knowledge workers have shown faster completion and better results on tasks that sit inside the models' capability frontier.

The tools work. That is what makes the next mistake easy.

People get faster. The company stays slow.

McKinsey's 2026 State of AI survey found that 80 percent of respondents said AI had improved their individual productivity. Only 37 percent said AI had made a positive contribution to their organization's EBIT. That is survey data. It is an association, not proof that one causes the other. Still, the gap is worth paying attention to.

People can get faster while the company stays slow.

Find the constraint

Theory of Constraints gives us a useful way to think about why. Find the constraint in the system. Then ask whether AI increases throughput through that constraint.

Suppose AI lets a sales team produce four times as many proposals. If pricing, legal, security, or executive approval still runs at the old speed, we did not get four times the throughput. We built a bigger queue.

The same thing is happening in software. Engineers can generate code much faster. If architecture review, testing, security review, or deployment becomes the constraint, more code just means more digital work in process.

I think digital WIP is going to become a real management problem. Local productivity can look fantastic while end-to-end cycle time barely changes. Everyone is busy. Every dashboard is green. The customer is still waiting.

Leadership owns the operating layer

Buying seats is a procurement decision. Changing how work flows is a leadership decision. Someone has to name the value stream that matters. Someone has to decide where AI is allowed to act, where a human still owns the call, and what evidence gets kept. Someone has to put WIP limits on AI-generated work so review does not drown. Someone has to stop celebrating vanity metrics when cycle time at the real bottleneck has not moved.

Lean taught the same lesson. Tools without leadership change stayed local. The companies that got further treated this as a management system problem: strategy, standard work, problem solving, and respect for the people doing the work.

That is why I keep coming back to the idea of an LLM operating system. I mean that very plainly: the workflow, context, tools, decision rights, humans, controls, measurement, and learning around the model.

That operating layer decides whether cheap intelligence becomes business throughput or simply creates work faster. Leadership owns that layer. IT can buy the seats. Only leaders can redesign the system.

What to measure instead

I wrote about this broader shift in The Augmented Enterprise.

I am already working toward another iteration, effectively a v3, because this operating layer is moving that fast. Models will improve. Prices will fall. Agent capabilities will change. Vendors will come and go.

The organizational problem is more durable. So is the leadership problem.

Where is the constraint? Did AI move it? Did total cycle time improve? Did more value actually make it through the system?

Tools-first is fine. Tools-only is not a strategy. I would spend a lot less time celebrating seat activation and a lot more time measuring cycle time at the constraint.