The short version. Most enterprises are deploying AI to help the organization handle more work. The larger opportunity is using it to need less. The evidence for the gap is mounting: MIT’s NANDA initiative reported that 95 percent of generative AI pilots in its analysis had not yet delivered measurable financial impact, and Gartner expects more than 40 percent of agentic projects to be canceled by 2027. The common thread is not model quality. It is what the model is pointed at. Two principles a century apart, Gates on automation and Jevons on falling cost, both warn that technology amplifies whatever you aim it at, for better or worse. The disciplined move is to use AI to simplify and eliminate unnecessary work before automating it. The cheapest token is the one you never spend.

Every enterprise rolling out AI is making a structural choice, and most do not realize it.

The choice is not which model to license or which platform to standardize on. It runs deeper than that, and it quietly shapes the return on every dollar spent. The choice is whether you are using AI to help the organization handle more work or to help the organization eliminate the work it needs to handle.

Those two goals sound adjacent. They are nearly opposite. And the default setting, in most enterprises, is the first one.

The two postures diverge at every level. One handles more requests; the other eliminates them. One speeds up coordination; the other removes the need for it. One layers automation onto existing complexity; the other reduces the complexity first. One spends more tokens as it scales; the other spends fewer. They can look alike on a roadmap. They build very different organizations.

The Default Setting Is “Do More”

The dominant AI strategy in 2026 is broad distribution. Everyone gets a license, everyone is encouraged to explore, and leadership waits for productivity gains to surface from the bottom up. The stated hope, usually somewhere in an all-hands deck, is that people will find their own ways to cut costs and improve quality.

That hope is not unreasonable, and the pressure behind it is real. Boards are asking about the AI plan. Competitors are announcing initiatives. Nobody wants to be the organization that moved too slowly. Broad deployment is the most visible way to demonstrate momentum, and visible momentum seems to be what this moment rewards.

But visible momentum and realized value are not the same thing, and the gap between them is now well documented.

What the Evidence Already Shows

In 2025, MIT’s NANDA initiative published one of the more sobering assessments of enterprise AI to date. An analysis of roughly 300 deployments found that 95 percent of generative AI pilots had not yet delivered measurable impact on the bottom line, despite an estimated $30 billion to $40 billion in collective investment. The researchers called the result the “GenAI Divide”: high adoption, low transformation.

The instructive part is the cause. The study did not blame the technology. It blamed integration. The organizations seeing little return were the ones treating AI as a tool to scatter broadly rather than a capability to build into how work actually gets done. The money, the researchers noted, was flowing toward the most visible functions rather than the ones where the returns were highest.

An independent reading from Deloitte points the same way. Its 2026 survey of more than 3,200 leaders across 24 countries found that workforce access to sanctioned AI tools jumped by roughly half in a single year, reaching about 60 percent of employees, while only about a quarter of organizations had moved even 40 percent of their experiments into production. Access raced ahead. Value lagged behind.

Gartner’s view of the agent wave is no kinder. The firm forecasts that more than 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating cost, unclear business value, and weak risk controls. Its analysts put a finer point on it: many of the use cases being built as agents today do not require agents at all. An agent that plans, reasons, and calls tools to do what a simpler automation already handled is not a breakthrough. It is the same work at a higher price.

Read these findings together and a pattern emerges. The problem is rarely the model. The problem is what the model is being pointed at.

An Old Rule, Newly Urgent

There is a principle from the early days of business computing that has held for thirty years. In 1996, Bill Gates wrote that automation applied to an inefficient operation will magnify the inefficiency. Apply technology to a process that works, and you amplify what works. Apply it to a process that does not, and you amplify the waste, now faster, more consistent, and far harder to unwind.

This is the rule most enterprise AI strategies are not built to respect, because most are built around deployment rather than understanding. The instinct is to find work and automate it. The discipline that gets skipped is the one that asks, before automating anything, whether the work should exist in its current form.

A caution belongs here. Not all complexity is waste. Some of it encodes legitimate control: regulatory requirements, safety checks, segregation of duties that exist for good reason. The discipline is not to strip complexity out wholesale. It is to separate the complexity that earns its place from the complexity that merely accumulated, and to do that before automating either one.

This is where AI is useful in a way unrelated to automation. Large language models are unusually good at showing how work actually moves through an organization: synthesizing across sources no person could hold at once, surfacing the redundancies and exceptions that accumulate invisibly in complex processes, and offering alternative framings that expose what a workflow is really doing. Pointed at a process before you automate it, AI becomes an instrument of clarity. An organization that uses it that way tends to discover that a meaningful share of what it was about to automate could instead be simplified, consolidated, or eliminated. The automation that follows is then aimed at work that has earned its place.

A concrete version makes the point. A support organization can build an agent that drafts a reply to every customer escalation, or it can use AI to find that a handful of upstream approval steps generate a large share of those escalations in the first place. The first option automates the symptom. The second removes the cause, and the escalations it prevents never need a token at all.

That sequence is not a delay. It is what makes the eventual automation worth building.

The Cost You Cannot See

There is a second problem hiding underneath the first. I watched it play out once already, in the early cloud era.

When enterprises first moved to cloud infrastructure, departmental consumption was largely invisible to the people generating it. Costs flowed into a central budget line, no manager had a clear signal of what their own usage was costing, and spending grew without the friction that accountability creates. An entire discipline, FinOps, emerged to restore that visibility.

AI token consumption is following the same path, and in many organizations it is further along than anyone realizes. The unit of cost, the token, does not appear in standard dashboards. Most department managers responsible for their own budgets have no line of sight into what their teams’ AI use is actually costing, because that cost sits on a centralized bill that nobody with operational authority is monitoring. The discipline that would prompt a manager to ask, “Is this worth it?” never gets triggered because the price tag is invisible.

The result compounds quietly. Industry practitioners describe pilot workloads that ran at $10,000 a month swelling to $400,000 a month in production, with no single decision causing the jump. It simply accumulated, across dozens of features and teams, none of them watching the meter.

A manager operating without that visibility is not being careless. They are being asked to be responsible for something they cannot see. That is not a personal failure. It is a governance gap, and governance is a leadership decision.

Why Cheaper Tokens Make This Worse, Not Better

Here is the objection that usually surfaces at this point: the cost of AI is falling so fast that it will solve itself. Per-token prices are collapsing. Why worry about a number that keeps dropping?

Because the bill is going up anyway, and the reason it is going up is the whole point.

The pattern has a name that predates computing entirely. In 1865, the economist William Stanley Jevons observed that as coal-burning engines became more efficient, England did not burn less coal. It burned far more because cheaper energy made entirely new uses viable. Efficiency expanded the market faster than it reduced unit costs.

The same thing is happening with AI, and the people running the largest AI businesses are saying so openly. When cheaper inference briefly rattled the market in early 2025, Microsoft’s Satya Nadella greeted it with a single line: Jevons paradox strikes again. Apollo’s chief economist, Torsten Slok, has put numbers to it this year. The price of a single token has fallen roughly 90 percent since 2023, and over the same stretch, total enterprise spending on these models has been climbing, not falling. As tokens get cheaper, Slok observed, companies do not pocket the savings. They run more agents, automate more workflows, and generate more code. The unit cost of intelligence collapses while the aggregate bill keeps rising.

The mechanism doing this is precisely the one enterprises are racing toward. A task that costs a few cents as a single question can cost dollars when rebuilt as an agent that plans, loops, and calls other systems along the way. Cheaper tokens do not restrain that. They invite more of it.

This brings the argument to its sharpest edge. Falling cost does not reward discipline. It amplifies whatever you have pointed the technology at. Aim it at validated, valuable work, and the expanding economics work in your favor. Aim it at work that should not exist, and you have built a machine that consumes more every quarter to do something nobody needed. Treating the falling price as a reason not to forecast is not a strategy. It is the most reliable way to end up owing your board an explanation.

Two Laws, One Warning

Step back and notice what is actually on the table.

Two principles, more than a century apart, are converging on this single moment. Gates says automation magnifies the operation you apply it to. Jevons says falling cost magnifies the consumption of the resource you apply it to. Both are about amplification. Both are now pointing at the same decision.

Point AI at simplified, necessary work, and the two laws compound in your favor: the automation magnifies an efficient process, and the falling cost funds more of something worth doing. Point it at inherited complexity, and the same two laws turn against you: the automation magnifies the inefficiency, and the economics pour ever more spend into sustaining it.

There is only one move that escapes both. Eliminating unnecessary work does not magnify it or fund it. It removes the work from the field entirely. The cheapest token, the one with no future cost and no compounding exposure, is the one you designed your way out of ever needing to spend.

The Choice Underneath the Tooling

This is the thread that runs under everything I write here. The question that matters in enterprise technology is rarely which tool you bought. It is whether the structure you built around it reduces the burden the enterprise carries, or simply relocates that burden somewhere harder to see.

I made a version of this argument in an earlier post about as-a-Service models: when you move operational execution to a provider, the overhead does not disappear, it relocates. AI presents the same fork in sharper form. Used to handle more, it relocates the cost of unexamined work into a token bill that grows as the price falls. Used to need less, it reduces the work itself.

Under undisciplined adoption, the coordination structures and cost burden an enterprise carries can transform, persist, or, in some cases, compound. Which of those happens is not determined by the model you chose. It is determined by what you decide to point it at. Simplification is the choice that lets those structures truly transform. Automating the inherited mess is the choice that makes them compound, now magnified by one old law and funded by another.

So, before the next question about which use cases to automate or which agents to build, there is a prior one worth sitting with. If you had to describe your organization’s actual theory of value for AI, not the tools deployed or the seats licensed, but the value framework underneath them, how confident are you in the answer?

None of this is free of friction. Simplification produces less visible progress than deployment. One creates fewer workflows; the other creates more demonstrations, and a leader measured on adoption feels that difference. But demonstrations measure activity, and activity is not the same as value.

This points toward a change in how leaders champion the technology, and it costs nothing to make. The encouragement can stay exactly as enthusiastic, but it carries a sequence: spend your tokens on simplification before you spend them on automation. Same broad access, same permission to explore, aimed first at understanding and reducing the work rather than encoding it. That single shift turns a scattered experiment into a disciplined one, and it points the organization’s spend at the gains that hold.

The enterprises that look back on this period with satisfaction will not be the ones that moved fastest. They will be the ones who ask what to simplify before they ask what to automate, and use AI as an instrument of clarity rather than a substitute for it. That is the harder path. It is also the one that produces something worth building on.

Systemic Inflections examines the organizational and structural questions beneath enterprise technology strategy, informed by four decades in the field and active research into how enterprises reorganize around as-a-Service models. If that is the work you are doing, subscribe to get each post as it publishes.

That technical reality has been changing for decades, and the forces driving it are not singular. Cloud platforms, software-defined infrastructure, AI-assisted development, and shifting vendor models have each contributed in different ways. Taken together, they are gradually dissolving the technical rationale for the organizational separation that created IT departments in the first place.

One of the more consequential models emerging from that shift is as-a-Service. Not the only one, but one worth understanding carefully, because it combines a financial model change, an operational model change, and a technical model change simultaneously. That combination is why enterprises are moving toward it. It is also why the transition tends to be more complicated than the business case suggests.

The Three Promises

As-a-Service models make three promises to enterprise technology leaders. They promise agility, the ability to scale capability without the friction of capital investment cycles. They promise cost efficiency, a shift from large infrastructure expenditures to predictable consumption-based economics. And they promise operational relief, the idea that by moving execution to a provider, the enterprise recovers the organizational bandwidth that running the operation was consuming.

The first two promises get most of the attention. They are familiar, measurable, and relatively straightforward to model in a business case.

The third promise is the one that deserves more scrutiny than it typically receives.

What Operational Relief Actually Requires

When an enterprise moves infrastructure operations to an as-a-Service provider, it is redistributing operational execution to an organization outside its own boundary. The provider handles the daily work of monitoring, troubleshooting, updating, and governing the infrastructure. The enterprise benefits from the outcome without sustaining the organizational effort required to produce it.

That is the model. The organizational reality is more nuanced.

Large enterprises do not build operational complexity arbitrarily. The approval layers, escalation paths, monitoring routines, exception-handling procedures, and governance structures that accumulate around infrastructure operations exist because the enterprise needed them. They are structural responses to uncertainty, interdependency, and the organizational reality of managing critical systems at scale.

Those structures do not dissolve when a contract is signed. Sometimes they transform, reshaped around the new provider relationship rather than eliminated. Sometimes they persist largely intact, because redesigning them requires organizational attention that the transition itself consumed. And sometimes the enterprise finds itself managing coordination on both sides: provider oversight and relationship governance on one side, and residual internal structure that was never redesigned on the other.

The financial model changes. The organizational complexity does not always follow.

Why Network Operations Is a Useful Lens

Enterprise networking is not where most technology leaders expect a structural insight to surface. It rarely leads the as-a-Service conversation, and it is not the most visible domain in the broader cloud and platform shift.

But it is one of the most operationally dense domains in the enterprise technology stack. Networks carry decades of accumulated internal structure, monitoring disciplines, configuration governance, change approval processes, lifecycle planning cycles, and vendor management practices. The operational complexity is real, well-established, and deeply embedded in how enterprise IT organizations are staffed and run.

Network-as-a-Service is also concrete enough to examine carefully. It has a defined scope, a meaningful adoption continuum, and a growing base of large enterprises that have moved significant operational responsibility to providers. The variation in how far enterprises have gone, and what that has meant organizationally, is observable and comparable in ways that more diffuse platform shifts are not.

That makes it a useful window into a question that applies well beyond networking.

The Question Enterprise Leaders Are Already Living With

When a provider takes over operational execution, what actually changes inside the enterprise?

Not in the contract. Not in the cost model. Inside the organization, in the coordination structures, the staffing models, the governance practices, and the operational rhythms built around doing this work internally.

Does the overhead reduce structurally? Does it shift form without reducing? Does the answer depend on how comprehensively the enterprise has committed to the transition?

These are not abstract questions. Technology leaders navigating as-a-Service transitions encounter versions of them constantly, usually without a clear framework for thinking through the answers. The vendor narrative tends toward simplification. The business case models tend to assume the benefits without examining the organizational conditions required to realize them.

The enterprises that are getting the most from as-a-Service adoption are not just buying a different financial model. They are doing something organizational as well. Understanding what that is, and whether it is something enterprises can design for rather than discover after the fact, is one of the more important practical questions in enterprise technology leadership right now.

If the organizational questions behind enterprise technology strategy are questions you are working through, this publication is written for you. Subscribe to get each post as it publishes.

Not intentionally. I was doing what ambitious business leaders do: identifying opportunities, solving problems, moving fast. When the IT organization couldn’t keep up with what my department needed, I found ways around it. Better tools, faster vendors, creative workarounds. We called it innovation. The IT organization called it Shadow IT.

I didn’t fully understand what I was doing to them until I became one of them.

Three decades ago I made an unlikely move: from the business side of a Fortune 500 company directly into the CIO seat. What I inherited was a world built around two Hitachi mainframes, COBOL-based enterprise systems, and the specialized expertise required to keep them running. The people in that organization weren’t obstacles to progress. They were managing extraordinary complexity with extraordinary discipline, under constraints that most business leaders never had to think about. Security. Reliability. Integration. Governance. The unglamorous architecture of enterprise continuity.

That experience changed how I think about information technology permanently.

The organizational model that created IT departments wasn’t arbitrary. It was a structural response to technical reality. Mainframe computing and COBOL-based systems required centralized infrastructure, specialized expertise, and significant capital investment. The technology itself demanded organizational separation from the business. You couldn’t run payroll on Tuesday and let marketing experiment with the same system on Wednesday. The boundaries existed because the technology required them.

Over the following decades, those boundaries became cultural as much as technical. IT organizations developed their own governance structures, their own planning cycles, their own professional identity. The separation that began as a technical necessity evolved into an organizational assumption so deeply embedded that most enterprises stopped questioning it.

Information technology belongs to the IT organization. Obviously. By definition.

Except something is changing.

Cloud applications now land directly in business units, provisioned by a product manager with a corporate credit card. Software-as-a-service platforms are selected, configured, and operated by the functions they serve: finance, marketing, operations, HR, often with minimal IT involvement until something breaks. AI-assisted development is putting meaningful technical capability into the hands of people who have never written a line of production code. Network-as-a-service models are moving operational execution outside the enterprise boundary entirely, to providers who manage infrastructure on behalf of organizations that no longer need to, or want to, sustain that expertise internally.

None of this happened because someone decided the IT organization should matter less. It happened because the technology changed the equation. The specialized expertise that once made centralization necessary is increasingly embedded in platforms, abstracted behind interfaces, and delivered as a service. The barriers that made organizational separation logical are dissolving. Not by design, but by gravity.

Which brings me to the question I keep returning to.

If the forces reshaping information technology are pulling capability closer to the business, and the evidence suggests they are, what does that mean for how enterprises organize around technology? Is the movement of technology toward the business an inevitable structural shift, or a transition that still requires careful enterprise governance to deliver its potential?

And perhaps more provocatively: if information technology no longer requires the organizational separation that created IT departments in the first place, what is the IT organization actually for?

I’m not asking that question as a criticism. I’ve led one. I understand the value, the discipline, and the complexity that serious technology organizations bring to enterprises that would otherwise underestimate both. I’m asking it because I’ve watched enterprises spend decades and billions on technology without realizing the advantages that investment should have produced, and I’ve come to believe that the organizational assumptions we’ve carried forward from the mainframe era are part of the explanation.

The enterprises getting the most from information technology are doing something differently. It’s not the tools they’re buying. It’s not the vendors they’re partnering with. It’s something more structural: something about where technology decisions get made, who makes them, and how the organization is designed to translate technology capability into business performance.

That’s what this publication is about.

Not technology. Not IT. The relationship between enterprises and the information technology they depend on, and whether the way we’ve organized that relationship is still serving us.

The questions ahead of us don’t have clean answers, and I’m skeptical of anyone who thinks they do. What I hope to offer is a way of looking at the landscape that makes the path a little more visible, informed by four decades in the field, active research, and whatever this community brings to the conversation.

If you’re leading enterprise technology strategy, advising organizations through technology transformation, or building toward a role where those decisions will fall to you, this is written for you.