I’ve been thinking about one of the more interesting disconnects in public markets today: how investors are valuing IT services and BPO companies in the age of AI. The more I look at it, the more I think the market is asking the right question and arriving at the wrong conclusion.
The question is straightforward. If AI automates knowledge work, what happens to companies whose business model has historically depended on selling that work?
The conclusion the market seems to have reached is equally straightforward. AI replaces labor. IT services sell labor. Therefore IT services become less valuable over time.
There is truth in that argument. AI is already changing how software gets written, how applications are tested, how documentation is produced, and how support teams operate. Anyone who has watched a capable engineer work with modern AI tools knows this isn’t marketing hype anymore. Productivity gains are real and they are compounding.
But I think that line of reasoning stops one step too early.
It captures the first-order effect of AI, which is labor automation. What it misses is what that automation enables at a system level. That is where I think the more interesting question lives.
The work being automated is not the same as the capability being sold
There is certainly a future where enterprises need fewer developers, fewer testers, and fewer support engineers. Companies whose only competitive advantage is supplying lower-cost labor should probably be worried.
Not every services company falls into that category.
The best enterprise services firms have never been valuable because they employ thousands of engineers. They are valuable because they understand environments that outsiders struggle to navigate.
They know which undocumented application still produces a nightly file that another critical system quietly depends on. They know that touching one integration point can break five downstream processes that nobody has looked at in years. They know that the CIO wants transformation, the CFO wants predictability, and the compliance team wants stability unless every audit requirement has been addressed first.
That is not just technical knowledge. It is organizational knowledge accumulated over years of operating inside a client’s environment. It is difficult to capture in a proposal document and even harder to encode into a model.
I am aware this argument has a shelf life. Tools are already emerging that attempt to map legacy dependencies and capture institutional context automatically. Over a long enough horizon they will likely succeed in parts of it. But enterprise transformation has never moved on the timeline that technology capability would suggest, and the window in which this knowledge remains economically valuable is probably longer than the market is currently pricing.
Enterprise complexity has a way of surviving every technology cycle
For years, CIOs, particularly in financial services, have been describing the same objective: retire the mainframe and move everything to the cloud.
Many have made substantial progress. Many are still running critical workloads on systems that were expected to disappear years ago.
This is not because enterprises resist innovation. It is because replacing core operational systems is rarely a technology problem alone.
Every major system sits inside a web of operational dependencies, regulatory obligations, contractual commitments, security controls, and organizational habits. Changing one component often requires changing dozens of others that were never part of the original plan.
AI does not remove that complexity. In many cases it adds another layer to it.
Who is accountable when an AI system makes a recommendation that turns out to be wrong? How should that output be audited? Which data can legally be processed in which jurisdictions? How do organizations monitor hundreds of AI-enabled workflows without introducing entirely new operational risks?
Those questions are becoming more important, not less.
The microservices lesson is worth remembering
When microservices became the dominant architecture for enterprise software, the promise was compelling. Smaller services. Faster releases. Independent teams. Greater flexibility.
Those benefits were real. So were the unintended consequences.
Entire categories of software companies emerged to solve problems that microservices themselves created. Observability platforms, distributed tracing, platform engineering, service meshes, and reliability engineering all became important because managing hundreds of services turned out to be substantially harder than managing one large application.
Automation did not eliminate operational work.It changed where the work lived. AI may follow a similar path.
As the cost of automating business processes falls, organizations are unlikely to automate fewer processes. They are more likely to automate many more. This is Jevons paradox applied to enterprise automation and I don’t think we should dismiss it casually. The difference between enterprise IT and markets where automation genuinely collapsed demand is that the underlying problem space keeps expanding. Travel booking was a fixed market. Enterprise technology complexity is not.
An enterprise managing 500 AI-enabled workflows has a very different operational challenge from one managing 50, even if each individual workflow becomes cheaper to build.
Somebody still has to integrate those systems, monitor them, govern them, secure them, and continuously improve them.
Where I think investors are making the real mistake
The label “IT services” has become too broad to be useful. It groups together companies with fundamentally different trajectories.
Some firms are still competing primarily on labor cost and billing by the hour. Those businesses face genuine structural pressure. If clients need fewer hours and AI keeps driving that number down, there is no natural floor. CIOs will demand those productivity gains come back to them as rate reductions, and they will largely be right to do so.
I should be clear that the shift to outcome-based pricing is not inevitable and not frictionless. Enterprise procurement teams have been buying hours for decades, and outcome-based contracts transfer risk in ways that make buyers cautious. This transition has been discussed for years and has historically moved slowly. What is different now is that pressure on unit economics may become strong enough that both sides are pushed toward new structures. That does not imply speed. It implies necessity over time.
Others are quietly becoming something different.
They are automating their own delivery so repetitive work requires fewer people. They are building repeatable approaches for AI governance, implementation, and compliance. They are accumulating experience from dozens of enterprise AI deployments that clients cannot easily replicate internally.
Most importantly, they are shifting from selling effort to selling outcomes.
That distinction changes the economics in a very specific way. If you charge for hours worked, AI simply reduces the hours available to bill. But if you charge for a business outcome and AI allows that outcome to be delivered with fewer people, revenue stays stable while delivery costs fall. The firm that used to need fifty engineers to fulfill a contract might now need fifteen. The contract value does not change. The margin does.
Not every management team will navigate this well. Some will automate delivery and pass the savings straight through to clients in the form of lower prices, which improves competitiveness but leaves the underlying economics unchanged. The firms worth watching are those that automate delivery and reprice the work at the same time.
From a distance, these two groups still look similar. Over the next several years, I suspect their financial performance will not.
The obvious AI trade has been building intelligence. The less obvious trade may be building the organizations that make intelligence usable inside large enterprises. I suspect the market is still treating those as the same thing.
As usual, these are strictly my personal views.
And Vijay Says... 