Traditional data center LANs have been built as a tree, with layers of switches that connect in a multi-link way with those at the next layer down. This provides a resilient way of creating what’s effectively a mesh, but it imposes a greater and greater latency and cost burden as the size of the data center increases. A long-standing graph theory says that the best approach would be to create a “flat” network in which the switches connected among themselves at random. Such a network requires fewer switches and presents a nice predictable and linear relationship between network capacity loss and switch failure. The problem is that attempts to realize this happy outcome have been unsuccessful.

Amazon came up with an approach that mixes true randomness and deterministic behavior with what it calls “spraypoint”. In this approach, a source switch picks a neighbor at random and sends a packet to it. That’s the random part. The receiving neighbor uses traditional shortest-path rules to send the packet onward, which is the deterministic part. The connectivity is structured in “rings” connected by a “ShuffleBox”, which on one side connect too switches and on the other to other ShuffleBoxes. This means that when a new server or rack is added, you simply connect it to the local ShuffleBox, and no other cabling is needed. The way the rings and ShuffleBoxes are designed is based on modeling Amazon has built through simulation, so the data center operator can input the number of servers and the performance required, and the result is a ring/ShuffleBox configuration.

I’ll mention this again, because it’s important, but this is not an actual fabric. The ring-and-shuffle model means that the traffic will still take hops, and the number of rings and shuffles will influence latency. A true fabric would deliver better latency performance, but of course many “fabric” switches aren’t really any-to-any non-blocking. Just keep this in mind.

Amazon started proving this in at the end of 2024 in one data center, and in April of this year it was adopted as the default architecture for all new AWS data centers. It reduces cabling complexity, operational errors during updates to the data center, failures, and the number of switches needed versus the tree-hierarchy approach. The latter, of course, may be why a data center user like Amazon came up with this rather than a network equipment vendor.

I think Amazon’s move is a proof point for something I’ve said in a past blog; data center traffic is driven by more than just AI, and in fact “horizontalization” of application component traffic may be for most users the greater driver. It also, I believe, demonstrates that it’s inside the data center where AI models are hosted that the greatest network impact of AI is likely to be found, at least for the moment. The new strategy seems to answer some network and traffic questions, but not all of them.

First, it appears that this approach could be used for traditional and AI data centers, as long as you had a handle on the traffic loads to be handled. That’s something that’s possible through simulation but easier for those who already have a tree hierarchy in place supporting an application/server mix, and want to expand or improve it. Some of the enterprises who mentioned this approach to me had concerns that the dynamism of application configuration and usage might drive changes that would impact the design, but admit that’s true for any data center network model.

Second, some enterprises wonder whether the Amazon model might also reduce the number of servers needed to meet QoE objectives, by reducing horizontal latency. Would the traditional approach to a scaling problem perhaps involve adding servers to reduce response times? Amazon has not commented on this so far, but if they’d like to do so on my LinkedIn post or to me via email, I’m all ears.

Third, given the relentless focus of network vendors on AI traffic, could Amazon’s approach help or hurt vendors? It does look like you could buy less network gear with this model, and since data center switches are increasingly a target for revenue-hopeful vendors, might this derail some confidence in predicting sales growth due to AI? It’s clear that Amazon is already targeting a reduced switch spending target, and I hear both Google and Microsoft are doing the same.

Fourth, does this all mean that vendors who offer both servers/platforms and network switches will have an easier time? If there is a move to address AI or other horizontal traffic growth by remodeling networks to reduce switch count, the vendor who can also supply other gear like the servers generating the traffic will have greater influence and incentives than the one who has only network gear in their inventory. This could help HPE/Juniper, and potentially hurt Cisco, whose server business isn’t all that active. Or, perhaps, make Cisco get more server-aggressive?

Fifth, is this a full and best-of-the-lot solution? There are still hops, still potential variations in latency, versus a true any-to-any fabric. There also appears to be a risk that improper setup or careless changes in the configuration, including adding and removing things or even accidental unplugging of a cable, might set up a chain reaction. Still, as I’ve said in many customer tutorials in the past, “There’s no substitute for knowing what you’re doing”. It’s just this is a different sort of “doing” than most will be used to. For large-scale data centers who want to avoid full-fabric costs or who simply can’t get a true fabric with enough capacity, this seems to be a great idea. For smaller ones, I think it may offer minimal advantage over traditional layered switch models, and for AI model hosting that spreads across servers, the latency could be more of an issue.

The final, and perhaps most important question, is whether the Amazon move suggests we’re extending the more-for-less thinking that’s dominated enterprise IT planning for the last couple of decades. Enterprises have already shifted to the cost-savings model of planning, are the hyperscalers now doing the same? Could it be that AI hype is coming home to a lot of roosts?

Wall Street believes there’s a major risk that AI is a bubble. I’m of the view that it’s a PR-and-media bubble, and that it may well be approaching being over-invested based on current opportunities for revenue. If that’s true, one of the responses could be to try to cut costs without dissing the AI hype that’s keeping so many stocks afloat. A better response would be to work to find future opportunities for revenue, like those in real-world-real-time services.

Wireless standards evolution has, in the past, worked well for telcos. It’s what brought broadband Internet services and enabled the whole smartphone revolution, after all. But over time, it’s focused telcos on coming up with features to enable new applications, not to extend old ones (like Internet access) to mobile, and telcos have been unwilling or unable to promote all the ecosystemic components of the new stuff. Arguably, they’ve not even thought about what the new stuff might be. I’ve said for years that this was a strategic fault; you can’t expect fancy new apps to spring up without the required business cases for all the stakeholders the apps would depend on. Nothing has changed here.

What may have changed then? The answer lies in the nature of the “Gs”, which are really all about mobile access and potentially service/access independence. In one sense this is logical; most “new applications” of network services would necessarily have new access requirements or they wouldn’t require changes in services at all. In another sense, it’s opening a big problem.

Access is a sink for roughly a third of all network capex. Because access services get you on the network, they are baseline requirements that aren’t linked to a specific desirable application, but to…well…access to applications. Table stakes, so you can’t price them too high or nobody comes to the table at all. Consumer broadband is a good example of this; the price per bit of consumer broadband is insignificant compared to the price of business bandwidth, especially if you consider history. I remember when the average business paid almost a thousand dollars a month or so for 1.5 Mbps of access; today twenty or thirty bucks a month gets you a couple hundred Mbps in most developed markets. So access has a high capex and low base revenue; meaning it has a lousy ROI.

Telco focus on the “G” succession in mobile service, then, is focusing them on the connectivity role that at least sustains and might even exacerbate their revenue per bit problem. And this is happening as seemingly unrelated industry forces are pushing things in an unfavorable direction in the access space.

Let’s start with the cloud. Cloud computing is a byproduct of the shifting of consumer information-gathering to an online task. Gathering information is an irregular, unpredictable, activity overall, and most enterprises quickly found that the level of traffic generated by these applications varied considerably. If you sized your hosting for a typical safety margin above the average, some outside factor could drive up demand suddenly, resulting in your failure to serve your users, and likely poisoning the relationship. If you sized for the peak, your hosting costs skyrocketed. So you bought hosting from a third party (the cloud provider) who could average hosting costs across a large base, creating the classic economy-of-scale resource pool.

But if this is the typical situation, which it is, then more and more consumer broadband is simply getting users to a cloud. And why couldn’t the same strategy work for employees in remote locations or working from home or on the road? If that happens, then the low-ROI consumer access network gets everyone to the cloud, and the cloud provider offers a connection to your data centers. If you have the average thirty sites of a multi-site business, you might have had thirty-one (including your HQ) expensive business data lines. Now you have one.

Then there’s voice and text, traditional non-Internet services. Every mobile plan to speak of includes them, but most have shifted from linear voice to VoIP. And what are voice or text services seen as most important for? Emergencies, which is a problem because anyone in a remote area or anyone whose Internet is down suddenly can’t use them. So they want satellite backup. How long will it be before satellite companies can offer basic voice/text? That doesn’t mean that telcos can’t sell theirs, but it does mean that at least some users will be looking for a mobile cellular service that doesn’t include voice, and that the notion of a “universal number” independent of provider is in the offing. How much of mobile service stickiness is generated by a phone number and the hassle of porting it?

The same is happening with video; cable companies are finding it harder to sell linear TV, with users moving away from scheduled to on-demand viewing and with TV sources offering streaming services. Streaming video means that there is no unique video channels to sell users, no extra revenue. Cable companies had a big advantage over telcos because of those channels and the “What’s on?” mindset. You can already see that going away.

How does this impact our progression of mobile service standards? Well, low-latency is a way of getting real-time data to a processing point with minimal delay. But who makes the money on it? The processing people. Low-latency broadband would just be a new generation of table-stakes connectivity. And how about network slicing? What applications require special QoS? Not ones we have online now, so new ones will be hosted, and the same sort of disintermediation the cloud generated will now hit these QoS-dependent apps.

Mobile standards are an access trap for telcos. Even if they succeeded, they’d succeed in the context of an application ecosystem that rewards other more experience-related players far more than it would telcos, while focusing telco spending on an area that is not only low-ROI by nature, but is also cannibalizing (via the cloud and SD-WAN) other more profitable business access opportunities. They’re getting sucked into the communications-services equivalent of a draw play, and they’re not only not resisting, they’re actively helping with their own disintermediation. And they’re not going to stop.

That’s why we have to watch the players like Ericsson and Nokia. They’re remoras on the telco sharks, so if telcos starve so do they. And as equipment vendors, they have a broader infrastructure view. So think less about 5G or 6G or any-G, and more about what these vendors are trying to do at the application level. That’s the only stuff that can get telcos back in the game.

To the first question, I think the answer is clear; yes, we need to regulate AI. The real problem comes in the second and third questions, starting with the fact that regulation is justified by preventing harm in some form, and so we have to know just what harm we’re trying to address.

The obvious harm of AI comes from the very terminology. Artificial intelligence is either a nonsensical fraud or it’s a technology that appears to mimic at least some aspects of human intelligence. We don’t let humans do anything they want, so we can’t let AI do any of those things either.

AI can generate voice, images, videos. If these are realistic enough, they can mimic a real person, and so it would be possible to generate stuff that could be embarrassing or even things that might lead to criminal prosecution of the target. To use AI to mimic a real person leads to risks that have to be addressed through regulation.

AI, of course, can also generate stuff that doesn’t mimic a real person, but instead constructs an artificial person. Here, the problem is that this artificial person could still commit real liable or slander, and potentially even conspire in real criminal activity. The harm this could cause is equal to the harm that a real person could cause in the same activity, and so it must also be reduced or eliminated through regulation.

Suppose our artificial person looked/sounded very real. Could it be “hired”, meaning take the job of a human? Hollywood and the music industry are already worried about this, and even more worried if you modeled the artificial person on a real one. I think regulations to prevent this without permission of the target people is essential, but this raises the broader question of whether AI impact on jobs should be regulated.

Enterprises are mixed on that one, with the split being largely based on age and position. Generally, younger and older workers tend to favor some job-protecting rules, and generally workers in higher-level positions are less concerned than those in more clerical or laborer roles. Senior types are concerned about the potential social/political impact should the use of AI displace a lot of workers, creating employment and social welfare problems overall.

I’m ambivalent on this one, so far. The industrial revolution was populizing, so it generated both jobs and lower costs and raised overall living standards and economic strength. The computer revolution has been a bit less populist in impact; you could argue that it exacerbated the division of wealth. An AI revolution could bend in either direction, and at this point I think it would be hard to say which is more likely. I think it would be logical to assume that some policy of expanding data collection and reporting on the topic would be in order for now, with action determined when we have a better handle on just how AI is impacting overall employment.

Then there’s the issue of data centers. Here, enterprises seem to have a consistent viewpoint; AI data centers should not in any way threaten the utility costs for residential and business properties. Regulation to require them to assure that’s the case should be considered strongly, but many think that it will be difficult to establish consistent rules given the patchwork of utility regulations in place in many countries, including the US.

For tech, there’s another issue, which is the impact of AI on ad sponsorship. The impact comes from two sides; the impact on ad delivery and on personalization and targeting.

AI summaries of search requests are already messing up SEO strategies for advertisers and online sites. Google has an obvious advantage in dealing with search impact; some are already seeing ads spliced onto AI summaries, so Google is selling placements there. Can this make up for the smaller number who click on search results? Google seems to think that for them, at least, it could. For most, it depends on the broader issue of personalization and targeting.

Google already personalizes ads based on what it knows about users. Most tell me that they prefer ads that align with their interests to those that do not, though some worry about how much companies like Google know about them. It’s perfectly plausible to assume that more personalization and targeting will emerge as a result of the combination of AI impact on ad delivery and its ability to personalize more effectively.

I’m like many, but not all, people in that I don’t “see” ads at all. They don’t register on me because I simply don’t look. For web ads, I ignore them. For TV ads, I check my phone. However, if I’m actively looking to buy something I would be likely to pay attention to ads related to my purchase goal. Could AI predict, with accuracy, what I’m looking to buy? Some of my Meta contacts suggest that Meta thinks that social media is a forum where people share information about themselves and their goals far more explicitly than they’d reveal indirectly by search behavior. Could that then help Meta target? Sure. Could it encourage companies like Google and Microsoft to seek access to your emails, texts, and even your web activity through their browsers? Maybe.

The problem with personalization is that you can use personal information for more than ad targeting. You could use it to target malware, deny someone insurance of multiple types, and even to run complex scams. To the extent that these outcomes are real risks, they’d need to be considered for regulation.

AI has the potential to alter our social, economic, and quality of life factors in ways that other technologies have not, which means it poses a potential threat to all of them. However, potential threats aren’t a good way to target real regulations; they’re usually too vague to address effectively, and the actual impact is rarely known well enough to compare to the impact of an attempt to regulate.

The “who?” question is the most problematic, and is related to this. AI is today projected through the Internet. If regulatory policies are set by governments at various levels, they’re almost sure to be inconsistent. Would that inconsistency erode any benefit, given that it might be easy to bypass stringent regulations simply by going to the right sites? Or could regulating AI lead some geographies to fall behind in a giant technology advance? Or both?

We need to sort this out, but I doubt that the political arena is suitable for the task. What is? I wish I knew.

Technology isn’t what it’s about, it’s the benefits of technology that drive change. All of our hype waves, including AI and 6G, are created because a new technology is a kind of blank slate, a “UFO” that because it’s not actually landing in your yard, lets you assign any properties to it that you find interesting or helpful. Hype builds on supposition, which is most powerful when reality isn’t messing up our flights of fantasy. We’re seeing a bit of that now, in vendor announcements.

Nokia’s AI lab announcement and Street success in May demonstrate that a WAN vendor can’t really participate in AI traffic/network needs. Wall Street comments that the success it’s earned comes from the leveraging of optical networking in the data center, where AI inarguably can drive massive traffic changes. Let’s run with that point for a moment.

AI drives traffic within the model, for sure. It can also drive traffic to the model, if the model consumes a large amount of data in training or through something like RAG. It’s less likely, for now at least, to drive traffic growth between model and user. So far, less than two percent of enterprises have reported any noticeable growth in network traffic AI-to-user. The reason is that AI, in chat or agent form, tends to deliver answers, which don’t generally require a huge amount of data. Hey, people struggle to absorb 500-word tech articles, so why would they want massive AI reports?

The corollary to this is that AI is going to impact networking of the models, not connection of users to results. That means that companies like Nokia need to participate in AI hosting infrastructure, not wait for AI traffic to emerge in the WAN, if they want to gain from AI. It also means that telcos are unlikely to play in the AI world we see today because they are WAN providers facing a LAN-connected AI revolution…sort of.

What about the RAG stuff? The problem with that, says enterprises, is that the majority of data they’d want AI to analyze to create business cases is the same data that they don’t want to host in the cloud for security and governance reasons. The majority of AI agents hosted by cloud giants, for example, operate on less sensitive data, supporting missions that improve productivity but don’t create revolutions in traffic. Of the three agent models enterprises have always recognized (interactive, embedded, and workflow), the first two can easily be applied to non-governed data but the last poses the same governance concerns that “moving everything to the cloud” poses.

If AI networking is to develop, everything we can see today says it must develop from a decision to host AI within the enterprise. This decision would create an explosion in AI data centers, which would mean that AI data center networking would become an enterprise challenge and not just one for the cloud providers. It would also release the governance concerns on core enterprise data, which would then permit AI to be integrated into more of today’s business-critical workflows.

We are seeing, enterprises tell me, less growth in self-hosting of AI than expected. The reasons are first that all the public focus on AI is on cloud-hosted models, which can’t fully address governance concerns, and second that the technology itself seems to enterprises to be in a state of flux. What’s really needed to self-host AI?

Broadcom seems to want to answer that, within VMware. Its VCF 9.1 release is aimed at production AI hosting, meaning to enterprises the workflow model of AI agents that would let them open business cases involving the application of AI to core, governed, data. In their press release, you’ll find this quote: “As more enterprises turn to AI for driving competitive advantage, they face three critical challenges: data and IP privacy concerns, surging infrastructure costs, and their readiness for the world of agentic AI,” said Krish Prasad, senior vice president and general manager, VMware Cloud Foundation Division, Broadcom. “VCF 9.1 is a single unified platform that addresses all three and delivers one of the most advanced infrastructure for Private AI. We enable zero-trust security for AI, reduce costs through intelligent infrastructure optimization and hardware choice, and provide the flexibility to run both agentic workflows and accelerated inferencing on the same platform.”

This may be the most important announcement for AI of recent times. Enterprises don’t want to blaze AI trails, they want to ride an AI superhighway, which somebody has to build for them. VMware is perhaps the most widely deployed virtualization and compute infrastructure framework, so making it AI-ready, and coming out with the specific solution to the three challenges that Prasad cites, gives enterprises at least a view of the on-ramp.

How does this impact 6G, though, and what about the Broadcom announcement of the first 50G PON edge AI portfolio? Let’s see.

There are two ways that AI could credibly generate more edge traffic. One way is that AI supports new and broadly used real-time applications, which would require sensor data to bring reliable real-world state into machine-accessed form. Another is to find non-governed AI missions that do generate more traffic, which would mean finding a credible collection of prospective consumers of those missions.

As all of my readers know, I’m a fan of real-time AI missions. My problem is that you can’t sell connectivity for them until they’re ready to be connected, and nobody in the telco world seems to recognize that. 6G without real-time applications is hype, just like 5G was. That should mean that telcos and their vendors should be looking to promote those real-time applications, not just connecting hypothetical ones. How do you connect a hypothetical application? With a hypothetical service. How do you pay for it? With hypothetical money. Do better, people, and it may be that Nokia’s dabbling into data center networking for AI will lead its lab initiative to look at all the self-hosting issues. VMware is there to help.

For 50G PON, Broadcom doesn’t need to sell every consumer or small business site on massive AI commitments, only sell some of them, perhaps ten to twenty percent. If that number in a PON span need capacity, then the span needs to provide it as an option. Right now, ten percent of consumers (roughly) and fifteen percent of workers, can justify cloud-productivity AI tool purchases. Drop the price in half and you triple those numbers.

These two trends, the expansion of the cloud-agent value proposition and the creation of a reliable and cost-effective self-hosting model for AI, are independent. Get either going and you have some form of AI success. Get them all going, and do you have that elusive AI revolution. Maybe, and we may find the answer to that in the next year.

The market always gets it right, though “right” is in the eyes of the beholder. With AI, as with other over-hyped tech developments of the past, a surge of overstatements and flat deception often covers important truths, and in tech at least these truths tend to emerge because only demonstrable benefits can drive persistent sales. So it may be with what could be the most important development of this decade, the AI agent concept.

The combination of AI hype and “AI-washing” has always made it difficult to align stories on the topic with a consistent position, much less with enterprises’ own views. The most realistic position is that enterprises tend to see AI agents as software components, while the broad media/market view (encouraged, of course, by AI model and chip players and the cloud giants) tends to cast them as cloud tools of some sort. Because software components need a business case, and because business cases are easiest to make when the data in use is a company’s own core data, subject to governance, enterprises have effectively focused on self-hosting agents.

To differentiate “agentic” AI from AI overall, the media/market trend has been to focus on autonomy. An agent does something specific, on its own. It’s not a virtual person that can be asked questions, but rather a tool that acts on a command. While this is surely different from chatbot-like AI, it’s actually converging a bit on the enterprise view, to the point where it’s possible to see both agreement and more meaningful differences.

Software components do things. Agents do things. You can argue that software components behave autonomously, since they act on units of work based on their design and on any collateral data that they digest. Thus, the market view that agentic AI’s fundamental property is at least somewhat consistent, so dare we hope for some useful convergence?

Is autonomy really the fundamental property of “market AI?” I submit it is not, because the promotion of AI agents in the marketplace, in the media, is almost exclusively focused on the cloud-hosted form. Not a surprise given that the vast majority of AI being consumed these days is hosted by one of the AI giants. What AI is consumed that isn’t cloud-hosted is largely what enterprises have considered as “embedded AI”, built into software or devices to do something that the user may not even be aware of. If you have a recent Pixel smartphone you are using device-hosted AI in a number of things, from explicit (via Gemini integration) to embedded (in Google Camera). Even enterprise use of AI today is largely focused on the cloud, because enterprise deployment of AI is in its infancy, and what is deployed is often (as it is for consumer AI) embedded in something.

In cloud or in-house? That’s the real question, the real distinction. You obviously could host AI in-house, just as you host software components there, and likely for the same reasons, data security and cost. Cloud computing is not suitable for all IT in the minds of virtually every enterprise, partly because of data governance issues but also because most highly used enterprise applications are cheaper to run in the data center. Only things that are highly bursty in utilization are likely to benefit significantly from cloud economies. So, if AI agents are software components, when do the agent-components meet cloud requirements? Does any bursty agent belong in the cloud, if governance could be resolved? Those are now the critical questions for cloud AI and all the current AI giants.

Enterprises, focusing on data governance, have less a problem with cloud-hosted agents that don’t use governed data. That tends to focus agents on missions that aren’t company-specific, though, which means that what enterprises think is the most compelling business cases are off the table. However, they do recognize several types of “generalist agents” that could be useful.

One that over two-thirds of enterprises mention is content analysis, where “content” means things like video, audio, even text. Many copilot-type AI applications already nose at the edges of this mission set, but video is the specific one enterprises think they might like. Think of analyzing security feeds, of creating a record of events and interviews, and you get the idea. It’s clear that this sort of thing could, in theory, also end up exposing confidential information, but so could phone calls and public meetings, so it’s a risk companies can manage.

Another mission that gets nearly as much support is “market analysis”, which means using economic and demographic information that’s public rather than company-governed. I’ve used this kind of data in my own market modeling, and tried it with AI as well, but the traditional chat form of AI doesn’t seem to spread as wide a net to capture useful information as I could do myself. This issue is recognized by many enterprises too, so it may be why this particular agent mission gets support.

The third mission, which is relevant to roughly half the enterprises, is what you could call “operations analysis”. Think of this as being culling operations data from networks, hosting, and even from industrial processes that have real-time sensors, and then making suggestions or (perhaps, with human permission) taking actions. This seems to me to be the mission that has the most intrinsic interest, but there is a clearer risk of governance/security issues with it that’s making enterprises antsy. There is, however, much more interest in having this kind of agent follow the embedded approach, meaning that it would be integrated with an operations management application that could set guardrails on what might get exposed.

Ah, governance; the same issue that impacts cloud service adoption. There is some indication in the attitude of enterprises toward the missions above that there’s company data and there’s governed company data, and that even that last category has a bit of elasticity in terms of cloud-hosted AI. Some providers are more trusted than others (Google currently gets that nod) but none are fully trusted. Could AI itself provide governance? IBM is promoting an AI agent framework aimed at that, but primarily for in-house applications. Might it be useful for cloud AI? Enterprises aren’t saying at this point, but they’re not ruling out some sort of AI governance fence, if they believed it trustworthy.

To me, that suggests that there might be broader interest in cloud-hosted agents if there were a locally hosted front-end agent through which requests were actually made. If that’s true, then the value of cloud AI might depend on a generalized agent, self-hosted, that could enforce data governance on external, secondary, AI agent access. This could look, structurally, somewhat like what cloud providers now offer enterprises for edge computing, a middleware kit that acts as a front-end to the cloud and handles, locally, things that can’t tolerate cloud latency. This time, it would be things that can’t meet company governance rules.

In all, this could be a hopeful sign for the cloud giants and their massive AI investments, since it could open up more agent opportunity to them. However, they could mess this up. What they’d love to see is a set of distributed local agents that were tightly coupled to their cloud models, which would mean that there would have to be some form of cloud-provided-and-trusted governance between the distributed pieces of the model and the cloud. If enterprises were willing to trust cloud governance enough for that, they wouldn’t have data governance concerns about the cloud overall. That’s why we need an event-driven link, so that the data that’s used by these local models can be isolated. The giants should keep this in mind; sometimes the easy-greedy path isn’t the best one to take.

Google, Amazon, Meta, and Microsoft have all reported, with Google coming out well on the Street, Amazon coming out OK, and Microsoft and Meta both facing issues relating to their AI spending. There are two views, as is often the case, coming out of Street research. The dominant one is that companies are doing OK, even OK on AI, but there is a fear that the players are at risk of overspending any hope of return. That, I’d point out, is my own view. The contrary view is that AI success is supply-constrained not demand-constrained. Microsoft’s call is cited by this group as the proof. Let’s see what enterprises say.

First, enterprises (by a 4:1 margin) tell me that they believe AI will have a “significant” value to their business, but they believe, by almost the same margin, that this value is likely to take two to three years to realize, and almost all say that they’d be less surprised if it took more time than they would if it required less than that. They still (by a 5:1 margin) think that AI agents are the most likely sources of value, and (by a similar margin) that these valuable agents will likely be primarily self-hosted for governance reasons. In fact, working through the technology issues of self-hosting is the main reason why they see a delay in realizing AI value.

Second, enterprises note that these views are coming largely from the IT organization. Line departments have a completely different view, one that embraces the “copilot” or “chatbot” models (3:1 acceptance of one or both among line organizations), who see value in AI without access to governed core data (4:1), and who believe AI should be consumed as a service, from some giant like our big AI four (almost 5:1).

The line organizations like the notion of agents (4:1) but they favor the definition that gets all the tech ink; an agent is an autonomous AI element. It’s not something that looks like a trusted work partner, but rather something you can give a task to.

Let’s take these two points and apply them to the situation of our big four.

Google has always been seen by enterprises as having AI tools rather than offering AI as a virtual partner, even before the agent concept gained traction in the media. They are still seen by enterprise IT as the player who offers AI solutions rather than AI conversations, and enterprise IT pros tell me that’s also the view of their line organizations. IT pros also say that Google has an approach to AI agents that’s more workflow-driven, and thus better aligned with their own views, and Google is more trusted to handle “lightly governed” data than any other AI service.

What makes this important is that Google’s quarterly numbers, and its AI return so far, seems to be drawing increasingly from symbiosis between Google Cloud and Gemini. IT pros also tell me that Google’s AI tools are encouraging “citizen AI” (more on that later), and to respond quickly, AI organizations are hurrying to respond, perhaps by doing a bit more in the cloud than usual. In any event, it sure looks like both enterprises and Wall Street are starting to see Google as the best of the AI players.

Microsoft’s situation seems, say enterprises, more linked to that “citizen AI” stuff. They are not highly connected to internal AI projects run by IT organizations, but the copilot model is very easy for line organizations to adopt, since it integrates with personal productivity tools they already rely on. There is also, say enterprises, increased interest in line organizations engaging with their own IT to bring AI features into Azure applications, either already partly in the cloud or new ones under consideration. This is responsible for much of the order backlog Microsoft has reported, I think, but Microsoft still seems to be struggling to find an agent story that looks like what enterprises and line departments alike want to hear.

Amazon’s position with AI, particularly with AI agents, is difficult for both the Street and enterprise AI prospects to decode. Of all the AI giants, or cloud giants, Amazon has the least trust among enterprises for data security. Amazon is also not widely considered for AI tools, in no small part because their AI position isn’t nearly as visible as those of Google and Microsoft. The recent deals it’s cut with OpenAI and Anthropic are largely aimed at getting Amazon cloud/AI hosting revenue from their partners, not opening a direct AI play. To the Street, though, a new AI position for a company is at least not actively disproved, where many established ones seem to be on that path. It’s too early to say if Amazon really has any risk or benefit in the wings.

Meta is by far the most problematic player. It’s not that they have no monetization path, but that their obvious path of ad targeting has a limited upside and limited runway given that the ad market is finite and clearly smaller than the theoretical market for AI tools. The fact that it’s cutting staff to offset AI costs is less a proof that their AI can replace workers than a decision made to protect them from Street skepticism on AI spending’s impact on their bottom line.

Alongside all of this is a big problem for everyone; the return on current and promised AI investment. My model says that the current level of cloud AI spending could be sustained only by increasing the monthly AI subscription price to 1.79 times current levels. The promised level would require increasing it by 2.29 times. The question then is how many AI dabblers would continue to dabble at those higher prices. Enterprises (line buyers using AI services) say that their own maximum tolerance for an increase would be less than 1.5 times. Usage pricing of AI, which all the giants are considering, would be generally unacceptable to line organizations because it would make AI costs uncontrollable. For AI agents, the IT organizations can only speculate at this point, but they say that roughly half the proposed agent applications would “likely” require significant trials to validate usage before they could be approved.

The overall story here is, or should be, clear. AI cannot go on as it has so far because ROIs are too low and investment levels (driven by hype and desperation) are too high. Behind the scenes, driven by players like Nvidia and groups like the Digital Twins Consortium, we are seeing actual progress in finding paths to a new set of business cases that AI could facilitate, but this sort of thing is a poster child for what I wrote about the problem with media coverage of tech. Most people, even many in enterprises charged with AI planning, have never heard of some of the important developments in this area, and without it, AI faces ROI problems down the line…and maybe not that far down it.

I wrote my first article for a network publication, believe it or not, in 1982. It was a time when the early surveys of network professionals I did showed that a few key publications, especially Business Communications Review (BCR) were the most influential forces in network planning. I wrote for them regularly, and for a half-dozen print publications overall. None survive today. I used to publish a monthly newsletter (“Netwatcher”) which was for a time the longest continuously published newsletter on network technology. It’s no longer published. Technology publications these days are all online, and format of delivery isn’t the only difference. Not a single network professional out of over 800 who’ve commented to me in the last two years say that any of today’s publications are the most influential force in their planning.

What happened here? Does it matter? Both questions are complicated.

Tech publications when I started writing were transitioning from a paid subscription model to a qualified-recipient model. The mechanics of the former are obvious; you paid for the publication and so you received it. The latter approach involved filling out the once-ubiquitous reader-service cards, where you provided your job title and the budget you influenced, and the publication qualified you to receive it free, sponsored by advertisers who wanted to reach “influencers” in the purchase of their products or services.

Even before the dawn of online publications, in the early 1990s, the qualification approach was showing cracks induced by two basic issues. First, people who wanted to receive publications simply lied about their qualifications. Second, publications competing for advertisers wanted to boost their circulation, and so not only overlooked but encouraged “over-qualification”. I did surveys during the 1980s, and found that while in that period, the number of qualified points of network purchasing in the US grew from roughly 12,000 to roughly 14,500 during the decade, the number qualified according to reader-service cards grew from 15,000 to over 50,000. The total budget the latter claimed to influence was almost half the US GDP, which is obviously hardly likely to be true.

Even with this, though, the value of network technology publications remained high. The top pubs were number one through roughly 1985, and remained in the top three of the list of influences to planners for another decade. Things then entered the next era of content and influence evolution. Online content started replacing print in the early 1990s, as noted earlier, and it brought about three major changes.

The first change was timeliness became the priority. You didn’t have to wait for printing and delivery any longer; you could post an article immediately. It became clear that meant that people tended to seek out resources that got something up quickly, and that the increased use of search engines meant that something posted quickly would be crawled, indexed, and placed in the search results faster. You wanted a scoop, because the first story to appear was more likely to be clicked on, and ad revenue depended on getting served adds with those clicks.

The second change was that searching diluted publication loyalty. More and more online articles were found as a result of searching, rather than someone going to the publication website. SEO was more important than publication identity for the typical reader of an article.

The final change, mentioned in passing above, was that a click on the article link was the payoff for the publication, not whether the article was “useful”, “insightful”, or “referenced”. This, combined with the other points, meant that articles got shorter and less technological for the simple reason that this kind of stuff was easier and cheaper to produce, and paid off just as well. One result of all these forces was to reduce the value of “opinion” pieces in tech publications, in favor of news. That quickly made publications look more and more like summaries of press releases, and generated pressures on people like me who tried to go beyond that. I started getting editors telling me that I needed to explain a given acronym, one that anyone actually planning a project would have known well, but which the average tech reader, who wasn’t playing any role in project planning, might need decoded if they were to find the article through SEO. Do that in an article whose size was limited by tighter and tighter restrictions (from two thousand words, down to 800 or less) and there’s no room left to educate anyone.

All of this collided with a parallel shift on Wall Street. Companies used to be valued at some multiple of earnings, but tech was increasingly valued on the potential for people to buy the stock to cash in on future movement (yes, we still have that today). Stock analysts were famous for creating bubbles, and eventually regulators passed laws that made this sort of thing harder to do for stock analysts. By 2000, that meant that hype had to move to the tech publication space, where the forces I’ve cited above created a fertile growth medium.

Sadly, 2000 was roughly the end of the “obvious tech advances” period, in networking and elsewhere. We moved from mainframes to minicomputers to PCs to smart handheld devices, and you couldn’t just assume that a new application was both justified by extending previous business-case paradigms and run on infrastructure whose principles had been evolving for four decades. We needed to educate the buyers on how to make this new world work…but who would do that?

Vendors hate educational sales, because the salesforce spent a lot of time just getting a prospect to the point of actually considering a purchase, at which point they’d likely put the deal out for bid and let competitors who’d watched them teach tech school now steal the benefits. In any event, the financial regulations that came in around 2000 (Sarbanes-Oxley, or SOX, notably) tended to focus the Street more on current results, so you had to make your quarterly numbers, not “sell futures”.

Education, though, had been a role publications had played well. Why not now? Well, you can’t educate someone in a new technology in 500 words. I used to regularly write 2,000-word articles for influential tech pubs, but nobody by the 2000s would take something that long. No vendor education, no education from the publications either. So what does that mean for tech?

So, a gradual shift from revolution to evolution. In 2000, slightly more than half the budget available for IT spending came from new projects, new business cases. Today, the percentage hovers around 12%. Over 80% of enterprises tell me that they have reduced the number of vendors, tended to stay with the tech model they had in place, because it was easier to justify. Modernization, the orderly maintenance of the role IT already plays, became the goal. If anything, you needed to reduce costs every year, somehow, because you couldn’t make new business cases easily. But if you’re not able to get comfortable with the new, how do you ever get out of the status quo? And just over-hyping doesn’t solve the problem, either. Instead, it focuses you on dabbling, on low-commitment paths to something like AI. Expense it, try it, walk away if it doesn’t make you feel good.

This, in my view, is what’s behind a lot of the challenges tech faces today. We need to open new business cases to justify spending growth, and that takes work, understanding. We can’t claim that enterprises trying to cut costs are always going to find ways of doing that while avoiding tech costs. Truth be told, it’s just as hard to prove that tech can reduce worker costs as it is to prove that tech could accelerate output or improve quality. This could turn into a race to the bottom, and it’s our own fault, including the media and the analyst communities, the advertisers and the editors and publishers.

All of this has led us to an industry more interested in building fables than in building value. What enterprises tell me they are doing, and what they want to do, and what they need to do, is totally different from what I read about online on mainstream sites. It’s even getting harder to find non-mainstream sites that talk about the things I hear are important, the things I know from my own software and network background are important. I can’t write those fables, only about what I hear and believe to be true. Others can, and of course AI can as well. I’ve been running an experiment on having AI generate an analysis of network technology announcements, and it faithfully follows the party line of hype as well as any PR type or human reporter would. Is this whole click fascination, then, paving the way for AI to replace people? Interesting thought.

The tech we knew can’t go on as it has for decades, in a world where only clicks matter, and that, my friends, is the absolute truth. We did better in the past, and that proves that we can do better again. I think we have to.

We need to get a point out of the way here, which is why I’m focusing on AI agent self-hosting and not on cloud-hosted agents. The reason is that enterprises have only limited use for the AI services offered by the giants, because of concerns about data security. Yes, they could use agents for missions that didn’t involve business-critical data, or any of their own data at all, but these agents would be, they say, nothing but renamed retreads of AI chatbots. Aimed at generalized productivity enhancement, they offer relatively little benefit, and because they can’t use that business-critical data that enterprises say make business cases, they don’t generate any significant WAN traffic.

OK, onward to self-hosted agents. Every enterprise starts AI network planning with the data center. The first, and perhaps most important point, in enterprise AI thinking is that AI and traditional data center servers and storage will be co-mingled in any realistic deployment, and that means to them that Ethernet is the vehicle to support AI networking, period. Some enterprises say that they don’t think that enterprise clusters of AI would be large enough to justify InfiniBand because they plan to deploy multiple clusters if they have a lot of independent agents to deploy rather than a single giant one, but most simply say that Ethernet is the answer.

The reason for that lies in the three models of AI agent operation enterprises recognize, and how they view their potential for making an AI business case. Of the interactive, embedded, and workflow models of agent operation, enterprises think that the workflow model, then the embedded model, are the ones most likely to drive longer-term AI deployments. Both these models are expected to be tightly coupled to existing applications (embedded ones are inside them) and to corporate data repositories. Where current application hosting and data repositories are grouped by class of application, that would result in multiple agent clusters. Since those non-AI elements are almost certainly Ethernet-connected today, and the same sort of traffic that AI will generate is carried among them, Ethernet is the answer, period.

What changes with AI agents, say enterprises, is the scope of data involved. They see AI as offering a broader more “business-contextual” insight-creation capability than traditional software components, and they believe that breadth comes about in large part through AI’s ability to link in related information that traditional applications did not access. As a result, AI agents would not only increase the volume of horizontal traffic, but also the breadth of the elements being accessed. Previously independent application hosting clusters would then likely be more connected. To enterprises, horizontal traffic in general would require a change in data center network topology, and AI agents would require a radical change. Think of meshing as the top data-center networking priority for the AI agent age.

Almost everyone who’s deployed multiple AI servers knows that meshing within an AI cluster is absolutely critical because you can’t afford to add latency to the model’s internal data paths, for fear of slowing a final result to the point where it impacts the mission overall. What enterprises say is that horizontal traffic in the data center has, for decades, influenced them to think in terms of creating more paths among data center switches, eliminating the old bridging model that really preferenced vertical traffic. With AI, this gradual evolution to more meshing is expected to become a sudden thrust toward something much more like a fabric, an any-to-any design.

Enterprises also say that the shift from a vertical traffic aggregation model to a fabric will have to be accompanied by other changes to accommodate the intermingling of AI agents and software components. Current software moves transactions and events via a “service mesh” (Istio), “service bus” or “service broker”, but this is too much overhead, enterprises say. Even at the software level, tighter coupling is needed.

Fabric interconnection is therefore likely to be accompanied by a shift toward RoCE (RDMA over Converged Ethernet, where “RDMA” is “Remote Direct Memory Access”) as a means of lowering operating system and middleware overhead in interconnections. All of this requires Ethernet’s priority flow control and congestion notification features, which are more and more common anyway due (again) to the growth in horizontal traffic, which is typically more latency-dependent and availability-dependent than vertical traffic anyway.

The RoCE/RDMA piece may be the most significant piece of all of this, because it encourages a cluster of servers to be viewed as a common shared-memory, multiprocessor, system. Some enterprises say this is already influencing operating system and middleware selection, for AI and for any systems that are linked to AI for workflow integration or data exchange. A middleware model to optimize this sort of connectivity is unknown to most enterprises, but increasingly sought.

The next question enterprises are working to address on the AI networking front is the issue of distributed AI. Distributed AI, to enterprises, means AI models running symbiotically but not as a single model. Many AI missions, including nearly all those associated with real-time applications, involve a world model that enterprises believe is likely to be a model-of-models, creating a hierarchy of processing that will increasingly involve a hierarchy of AI elements. Just as a smart city is a model made up of smart building models, which in turn are likely smart-office-suite models and so forth, any real-time system can best use AI if limited local AI models handle events with very short response time requirements, and pass off events that can wait a bit to larger models designed to host AI at a better economy of scale.

This question is proving difficult for enterprises because little is being published online about the network relationship among distributed AI models. Enterprises’ own view is that this relationship would be created by the same means as used to link elements of distributed real-time processes today, which is event exchange. This presumes that the model-of-models approach to distribution, which is intuitively accepted by enterprises, is the best approach. A few (single-digit percentage) of enterprise users of AI agents recognize that if you assume the RDMA approach to interconnection within a cluster, it is not unreasonable to assume that a shared-memory approach might be extended beyond a cluster, which could mean high-capacity, low-latency paths for token movement in the WAN. Since most enterprises don’t see this approach, and those considering it admit it’s not proven out at this point, I’m inclined to think that token exchanges over the WAN isn’t a big opportunity.

That raises the ultimate question, which is the impact of AI agent use on the WAN. Distributed AI, as I just noted, isn’t seen by enterprises as having a big impact, because they dismiss the notion that it would have to be based on tightly coupled model hosting points. Here, again, I’m seeing enterprises drawing conclusions by associating AI agents with software components. Adding a component to a workflow impacts the user-to-application relationship only if the addition changes application functionality to the point where the data relationship with the user is altered. Enterprises at this point don’t see AI agents doing that; the data appetite of AI agents answering questions might be changed, but the impact on the size of the questions and answers, not so much.

Here I have a slight disagreement, but mostly due to what might be an increase in data gathering rather than user/application exchanges. I believe that real-time AI will require the analysis of video in order for world models to gather information about the real world. Would that analysis be purely local? Would responses to real-time conditions have to be returned in video form? How much latency could be tolerated there? I think there is potential for WAN impact here, but probably not for at least three years.

The perception you’d get from listening to vendors, AI and networking, is that a revolution is imminent. I think a revolution is coming, driven in part by AI but mostly by what AI would do, and mostly related to its ability to spread IT empowerment to real-time applications in a new, more intense, way. Imminent? Not according to enterprises, and I agree. What hype wave has ever come along to promise delayed gratification? No, it has to be immediate to be effective, and we’ve accelerated nearly every trend, even those with little chance of coming about at all, into current-day timelines. Well, we’ll see if this is different, but I don’t think so. Expect big changes, but not right away.

Generally speaking, data center networking is driven by an increase in vertical (application to user) traffic, horizontal (inter-component) traffic, or both. The nature of the traffic flows depends on where all the participating elements are located as well as the volume. Vertical traffic, in the data center network, is largely focused on getting in and out of the data center from the WAN, which might be the Internet, the cloud, the company VPN, etc. Horizontal traffic might be within a cluster of servers, within a data center, across data centers, and perhaps even to distributed computing elements outside the data center. All of this impacts what specific issues are important in the data center.

In the WAN, the big network question is “how to the users connect?” There are three broad possibilities; they connect via an MPLS VPN or private network of some sort, they connect via the Internet (including SD-WAN), or they connect via the cloud. All these mechanisms involve a different requirement for the enterprise network, and any or all of them might be used by a given enterprise, in any mix.

Only a bit over ten percent of enterprises who comment actually had any significant AI hosting, and all of them had deployed AI in centralized clusters. However almost a third had some “local” AI models running, often within facilities but sometimes in the data center. All 221 said they had experienced growth in both vertical and horizontal traffic, but all but 9 said that their horizontal traffic growth was the real driver of change to their network needs. Over 80% had made some changes in their networks to accommodate things like cloud networking, SD-WAN VPNs, and similar things, but these were tactical justifications, not what they considered strategic moves.

There are three forces driving things, say enterprises. One of them is the increased drive to integrate business processes, something that arguably started in the 2000s with the “Enterprise Service Bus” and Service-Oriented Architecture. This integration tends to create a transaction cascade as a “primary” transaction triggers related business processes independently, rather than having workers bridge the activity that crosses application boundaries. Think of this as a shift from double-entry bookkeeping to having a single action trigger both entries. This, the enterprises say, is the historical driver of horizontal traffic growth, and for most (a bit over three-quarters) it’s still the dominant one. It is also, as we’ll see, a driver that’s arguably behind the other two drivers.

The second force is componentization, a close second in terms of current growth. Here I’ll ask you to recall that enterprises see most AI applications as being components of a broader business toolkit, so they tend to see AI as contributing to growth here, but in two ways, and the one you probably think of as primary isn’t primary at all. Direct AI traffic, meaning access to AI tools, is a minimal issue. According to enterprises, the most successful AI agents are applied to enhancement of business analytics, and these tend to expand the way analysis draws on data repositories. “Without AI, it’s complicated to construct a big cross-all-data sort of analysis,” one enterprise told me. “With AI, we’re doing bigger and more complex analysis, involving more data and more data access.” AI agents are components, and components that spread data access breadth.

The third force is real-time services, the smallest of all the drivers at present but the one enterprises think has the greatest potential for long-term growth. The reason is, according to one IT planner, “We see a shift from integrated production to meshed production.” Today, transactions tend to link multiple stages of a business even if, within some at least, there’s real-time process control. This makes real-time systems an encapsulated element in those cascade transaction flows of our first driver. In the future, say about a third of the enterprises, the goal will be to create one enormous world model for the whole of the production process, and even perhaps for some of the related administrative and financial functions.

That’s not all, though. Real-time applications create and use more data, and have an exceptionally low tolerance for faults or even significant shifts in performance that impact application QoE. Thus, to the extent that AI is likely to drive real-time application growth, it’s also more likely to require (even though it’s an indirect influence) improvements in both latency and availability of network resources.

Now for the WAN. Enterprises do not, so far, see AI influencing WAN requirements, owing to the fact that the user-to-AI connection is confined to exchanging prompts for results, and thus isn’t much more data-intensive than traditional searches or typical enterprise applications. This, of course, presumes that the WAN carries only the prompts and responses, which may not always be the case.

There are three possible sources of WAN traffic beyond the prompt/response exchange; distribution of AI into a model hierarchy, remote model database access, and additional data collection to support AI agents in application missions not previously served. Each of these requires some exploration.

Distributed AI models seems to enterprises most likely to come about as a result of the creation of a world model that’s fed by individual process models. This sort of thing is most likely to arise in process control (real-time) applications, but in theory it could also be applied if a “local” AI agent could call on the capabilities of a larger, deeper model. AI models could in theory be tightly coupled to act as one, or be event-coupled, with the former creating the greatest network impact.

Model access to databases (RAG or similar techniques) might involve WAN access if the model were separated from the databases it relies on, or perhaps during training. The latter situation is not considered by enterprises as creating a likely network change, since training is a transitory activity, and the great majority of the enterprises who commented on AI agents’ use of data said they would not be likely to host a model so far from its data resources that WAN access would be required. This could change, but there’s no sign of it so far.

The additional data collection driver of incremental WAN traffic is the most difficult to assess because enterprises so far have very little exposure to it, even in the planning stages. Yes, it is possible that AI would open new application areas requiring new data absorption, but the current enterprise focus on AI agents is in area where a workflow, and thus data exchange, is already established. Again, real-time process control is the area where change is most likely.

OK, that’s our summary of traffic impacts, so in our last blog of this series, we’ll look at where those impacts might take networks.

In order for any IT tool to reduce costs for enterprises, there has to be some specific cost or costs it reduces. In general, enterprises say there are two possible sources. The first is labor cost reduced by either cutting worker numbers or facilitating the replacement of higher-cost workers with lower-cost workers. The second is cutting IT costs in some way, an approach that’s initially been focused (in the media, at least) on software in general and SaaS in particular.

Enterprises largely believe that the only way to justify AI cost is by “enhancing productivity”, which means getting more from a given unit of labor. There are some studies that bear this out, too. The problem with labor cost reduction as a goal is that enterprises have not reported any significant job cuts associated with the use of hosted AI services, and that any such goal generates significant public policy risk, proportional to the scope of the impact but real at almost every level. However, enterprises have consistently reported business benefits derived from one of the three AI agent models (interactive, workflow, embedded) that they recognize. These benefits are sometimes linked to the ability to reduce additional staff, but (so far) rarely to the ability to cut staff. In fact, AI agent use so far seems more often justified by improved decision-making, which may be due in part to the fact that many applications are currently linked to business intelligence.

The one area of exception to this is in the customer support area, where many enterprises seek to reduce call center personnel through the use of AI-provided interactive chatbot services. Enterprises say that call centers employ anywhere from virtually none to as much as five percent of their workforces, so this can be a significant gain, and it’s surely the low-hanging fruit of the whole AI interactive agent game. In addition to the potential reduction in labor costs, application of AI to support roles could improve user satisfaction, since call center delays and offshoring-created language barriers are a continuous source of complaints.

Wall Street tends to love the notion that AI is going to disrupt the software space, creating winners and losers that hedge funds can exploit with “long” and “short” bets on their stocks. There is some limited indication that AI is impacting software purchase decisions; enterprises are trying to work through the question of what AI could/should do versus what they’ve traditionally done with software tools.

Enterprises have mixed views on whether AI saves software costs in the long run, largely because the applications of AI agents have a varied relationship with current or prospective software expense. There are four primary sources of cost; development costs, software purchase, SaaS usage expenses, and hosting/network infrastructure costs, and all of them get mixed enterprise reviews.

Enterprises generally say that while AI can be used in coding missions, they have not actually cut costs significantly through this application. Most say that AI can generate basic functions, simple microservices, with acceptable accuracy, it requires more software-architect and development review, which limits the net savings in human resources.

There’s similar skepticism on AI reductions to software purchase. Part of this is due to the fact that enterprises are currently most likely to view AI agents as a supplement to existing software or a way of doing something that they have not been able to do in a satisfactory way with traditional software tools. There’s also a widely held view that AI will generally require more hosting resources than traditional software, in which case the TCO of an AI solution might be higher even if less software were to be purchased.

SaaS, or any form of expensed software, and in particular software tools used for “citizen empowerment” are a different matter. Most enterprises believe that AI agents and even AI services (many of which, I’d note, are positioning themselves as “agents”, compounding the general terminology challenges of the space) will impact other “personal” tools delivered as SaaS, and over a third say that’s already happening for them, though so far the impacts are reported as small. The question, says a large majority of enterprises, is whether the SaaS services are themselves augmented with AI, which most agree is already happening. They expect SaaS applications not involving data governance requirements to become “AIaaS” applications. Interestingly, this is what most see as the “agent-as-a-service” target that the current AI giants could exploit. However, to exploit it they’d have to come in cheaper than traditional SaaS, and I’m not convinced that would be a profitable business model for the provider.

The impact of an AI move against traditional software most often runs afoul of this tension between hosting costs and data governance. Enterprises with actual AI experience say that AI agents are like any sort of software, meaning that where usage is highly erratic it’s not economical to self-host, and so if AI services are ruled out because of governance issues, AI may not be an option at all. Even where that’s not a factor, there are AI agent hosting issues to work through.

Most software projects are cost-justified on a narrow basis, and AI is no exception. The problem is that like software in general, totally distributed AI introduces inefficiencies in hosting. That means some sort of AI clustering, usually in the data center, is essential for economical AI deployment. But if AI agents are narrowly cost-justified, how do you deal with the need to aggregate AI hosting to achieve overall cost efficiency?

This seems to be the overall dilemma that CIO/CFO types are trying to deal with. On the one hand, AI agents can generate real benefits if they’re applied to missions that involve a company’s core business data. On the other hand, to serve these missions with cost efficiency, you need an AI resource pool and not a bunch of independently deployed and operated AI servers.

One obvious question raised by this is how to interpret the massive layoffs being reported, particularly with tech companies, and attributed to AI. What I hear from insiders in all these companies is that the layoffs have relatively little to do with AI, at least in the sense being reported. They say that their companies are under profit pressure from Wall Street, and tech revenue growth hasn’t kept pace with expectations except where it’s related to AI futures. The lack of revenue growth means that profit growth can only come from cutting costs, but if you have to increase AI spending, you need to cut elsewhere, whether AI is in any way facilitating this.

Time to analyze, I think. Based on what I hear from enterprises, it will be very, very, difficult to justify AI-as-a-service based on reduction in labor costs, except where call center labor is the target. However, it would be possible to justify AI replacement of SaaS services, but only if AI is cheaper, which makes it an unlikely growth driver for the AI space. Thus, I remain convinced that massive growth in AI services will require a driver we currently don’t have.

AI agents, particularly those that operate on company-private data, are another matter. I believe what enterprises tell me is true, which is that these applications can make a business case in multiple ways. I also believe that this potential can be enhanced by facilitating an AI-resource-pool model that enterprises can be confident in deploying. There is, then, an AI self-hosting opportunity for chip and server vendors to exploit, but it will be what every seller hates to see—an educational market. You’ll have to teach the right way of doing this, because it’s very unlikely that the media/analyst space will address it because of the lack of click potential. So, the wait for AI to boom in truth and not just in clicks, continues.

What all this means for network evolution is simple; AI isn’t yet a revolution, and so its impact on networks is likely to be expansion of the “horizontalization” trends already established by service-oriented software componentization. But in every evolution, there are leaders, so there will be early adopters of AI agents on a large scale who will face network changes early on. We’ll be watching what they find, and do.