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.

Technology isn’t revolutionary in itself, it’s what we do with it. That’s true of network impact too. Networks carry data, support data movement, so what we have to be looking at if we want to track network change are the changes in data movement, and their causes. Enterprises have already been tracking one, and one that AI applications are impacting. “Horizontalization”

In the old days of monolithic applications, everything followed a nice input-process-output flow model. A user at a terminal generated a transaction, which flowed to the computer system running their application, which generated some database activity, and then returned something to that user. You could plot this top-down, which is what led to it being characterized as a “vertical” flow.

In the 1990s, we saw some kinks in this simple model of data flow, emerging from a combination of the trend to componentize applications and the trend to integrate applications by creating paths between them for shared action support. This, of course, was “horizontal” traffic. One enterprise noted that, within their company, they’d seen vertical traffic roughly double in the last ten years, but horizontal traffic had exploded by twelve times.

The force behind all of this was the need to achieve more productivity by improving information integration, quality, and distribution. Early IT was a bunch of application silos, and horizontal traffic the result of recognizing that businesses didn’t run on silos, but on the whole of their interactions with customers, suppliers, regulators and government agencies, and so forth. There’s strength in numbers, it’s said, and though the saying was talking about a different kind of numbers, it’s true for the business kind as well.

AI continues this trend, because what businesses want from AI is a set of agents that can do stuff that would otherwise require human action. That doesn’t necessarily mean closed-loop autonomy, but it does mean that the agents have to assimilate what the humans it augments/replaces knows or can know. More horizonalism, and the next and biggest force creates the most horizontal traffic of all.

Real-time services have a couple of faces of their own. One face, the most traditional, is the force of IT proximity. For seventy years, progressive growth in IT commitment and IT spending has been driven by bringing IT closer to workers. We started with mainframe computers in glass rooms tended by acolytes to personal computers or even smartphones, sitting on nearly everyone’s desk. We used to bring work to the mainframes, but we ended up bringing IT close to the work, making it a part of working.

But what about the no-desk situations? That’s the second of our faces of real-time services. It might seem like an evolution of the current trends, but it’s aiming at a different kind of work and workers. We’ve managed to enhance the productivity of those who could work through IT, but not those who’d need IT to work through them. Real-world systems are ones that make IT a cooperative piece of real-world processes, even ones involving people, and so they have to know about the real world, both conditions and rules. The new information relationships needed are a potential driver for AI, and of course new information relationships mean new information flows, which means network requirements.

I think that the initial focus of real-time services will be one of facility optimization, working to improve process control with a plant or campus. Most of the information needed for this will surely have been collected by early systems, so this is more a compute or compute-and-AI manipulation of a world model (digital twin).

The orderly expansion of this first step would take things to larger facilities, where inevitably fixed conveyance (like assembly lines, belts, etc.) give way to moving vehicles of some sort, and where it’s more and more likely that human labor has to be integrated. Both these introductions require new data to be collected, and in the case of the worker additions, also likely require new things be distributed to synchronize human and automated elements.

Running a world model, even for a “local world” is computationally intensive and generates horizontal data flows within the model, which is likely to be distributed both in terms of hosting elements and in terms of physical location. Thus, the initial impact of our real-time evolution will be sharp growth in horizontal traffic. Yes, there will be new telemetry and control flows, but these will likely stay on private facilities for now.

What expands us outward is the tightening of relationships between world models and human workers. It’s probably inevitable that, to the extent this trend is even recognized, that it gets twisted into robots and humans working side by side, but that’s a development that neither enterprises nor I believe will come along before about 2030. Initially, it’s likely to take the form of guidance, relying first on a phone/tablet display and then on augmented/virtual reality. Eventually it may involve simply timing mechanical movement to synchronize it with human movement, but all of this will mean analysis of video images to determine what the human workers are doing and where they are in the cooperative process sequence.

This process of coordination between humans and machines is what ultimately generates the network traffic, even in the WAN. Some jobs, like almost all of them in the public safety sector and the military, are long on the need to collect “awareness augmentation” information, both to alert a person to conditions they need to handle and to populate a model that enables broader process control, like a “smart city” environment.

What this all means for data centers and networking is what will drive the future of both, and that’s next week’s topic!

First, the only low-latency services that telcos themselves mention are those related to some form of real-time process control. Process control means control of things that take action in the real world, that do things. This category divided into two main segments—processes bound to fixed machinery and processes linked to mobile elements, which might be mechanical, human, or both. There is general agreement among telcos that bound processes are not likely to generate real-time service opportunities for them unless mobile elements are introduced in some way, so it’s fair to say that mobility of process elements is an essential feature of applications that credibly consume low-latency services.

The challenge with mobility is that there’s an inverse relationship, generally, between the latency requirements and the geographic scope of the process. The further a process is spread, the greater the mechanical delay associated with movement within it, and thus (if we neglect, for this discussion, the issue of autonomous vehicles, which we’ll get to later) the less valuable low-latency is. If I want to coordinate the dispatch of something between facilities that will take minutes or more to complete, there’s little to be gained by asking for it with microseconds-level latency. But if a process is confined to a single facility, the control of it can be locally hosted there, eliminating the need for a connection service, it’s practical to replace it with WiFi or private cellular.

Most process control apps, according to enterprises, are hosted on their own process controllers (which today are most often “embedded control” or “real-time” systems) local to the processes themselves. This is true of facility-mobile applications like warehouse stocking and removal, as well as bound processes, simply because it gives enterprises the most control and because the suppliers of the mechanical elements of these processes often also provide the applications and control hosting tools, which expect local connectivity. Telcos think that the evolution of these applications to include more mobile elements and greater geographic scope would create the opportunities for low-latency services, but enterprises are more skeptical.

This gets us to the notion of autonomous vehicles. Enterprises say that they would not expect to see the ROI in creating autonomous transport vehicles for passage between facilities absent any broad autonomous vehicle support. In most cases, the cost of a driver isn’t a large enough component of total cost of the process elements to make displacing human drivers worthwhile, especially given that it would mean replacing the current fleet elements. Today, they say, mobile process elements tend to be introduced into new facilities, as a part of the process of opening one and equipping it. Given that, it’s not surprising that enterprises suggest it could be smarter to aggregate related processes into a larger facility controlled by and connected with their own resources.

It’s hard to say how realistic this is, though. It is true that cloud computing is generally less economical than self-hosting; it justifies primarily where demand is too highly variable to permit cost-effective self-hosting. Might that also be true for edge hosting services, and thus justify low-latency connections to them? This is another place where there’s a diverging viewpoint in the market, this time both among telcos and among enterprises.

The “cloud-like-side” perspective is that if somebody deployed edge hosting, applications to exploit it would evolve. Absent the proactive deployment, there’s no reason for enterprises to plan such applications since they’d lack a mechanism to be run. The “cloud-unlike” perspective says that the cloud worked because self-hosting highly variable applications was the only option prior to the cloud, and so applications that could benefit from cloud hosting existed, latent opportunity for cloud services existed. A whole distributed and coordinated multi-process relationship would have to exist for a WAN service opportunity to host and connect their control existed. How would it be supported?

You can see sense, value, in each of these approaches, but I think you can also see that cloud hosting of highly variable application elements could be justified by simple economy of scale, but what about edge hosting? Real-time control is hard to “schedule” resources for. You have them or you don’t, and if you don’t what happens to the control process? This is way more complex to analyze, which is why there’s a debate.

Complicating the debate, for the telcos, is the issue of OTT competition, meaning at least the cloud providers but perhaps others as well. One telco planner told me that his company believes that electrical utilities and even local governments might get into the edge hosting business. The cloud providers have taken steps to make their cloud middleware tools available on customer-owned servers, which means that they can encourage enterprises to build applications around a cloud model, making them easier to migrate to future edge services. The same telco planner says that in any event, metro-level latency might well fit with current cloud hosting, at least for companies proximate to current cloud hosting points. In all, there’s a lot of credible competition for edge hosting, so why not let someone else do that, and simply connect that which emerges?

Because, others say, it might take a long time to emerge, time telcos might not have. Furthermore, since telcos have no experience with nor credibility in the application-hosting market, couldn’t those who develop it do so while minimizing the low-latency service opportunity? Chip improvements, in cost and performance, could well make it possible to build more intelligence into mobile devices, and we already know that autonomous vehicles that need connectivity all the time to stay operating pose a major risk that regulators could use as an excuse to bar their operation. How long until connectivity can be fully guaranteed, fully trusted, at any latency? My Internet was down yesterday for a brief time, long enough to have caused a lot of crashes or traffic problems.

I think we know that an event-driven, model (digital-twin-world-model) structure is what’s needed to make real-time process control work. I think we know that the components of the application would be functions whose input is the model-element needed and the event triggering it. I think we know that this makes the application naturally distributable, which means we can host a piece where the constraints like cost and latency are optimally balanced. What we don’t know is how this gets started so as to maximize the capabilities for all concerned, and since this future is an ecosystem as complex as any we’ve attempted to build, we need to get on the stick and figure that out.

I have 88 telco comments on mobile evolution made to Andover Intel since 2024, with 81 telcos who have made comments on 6G in the last six months. Of the latter group, 12 say that 6G will create a burst of spending, 38 that there will be a bubble of spending, 23 who see no significant change in spending, and 8 who don’t think there will even really be a 6G or any such organized phasing of mobile standards for decades, at least. Why the division?

The biggest factor is the drivers behind any new investment. All of the 12 who see a 6G burst believe that low-latency applications will generate a “significant” or even “vast” new pool of telco revenue. Another 31 think that “some” new low-latency opportunity will emerge, largely from our “bubble of spending” group, and the rest say that they believe there will be no real new service opportunities emerging from 6G at all. The group who sees no actual, meaningful, new mobile standards generations at all believe that no such opportunity will ever emerge.

The problem here is that even those who believe in low-latency services don’t see it being a major market. They point out that consumers, who make up the majority of mobile spending, have never shown any willingness to pay much for any incremental service improvements. Most won’t pay for additional bandwidth, and many are abandoning unlimited plans for metered service to lower their costs. The prevailing view is that consumers will take what’s offered for no cost, which begs any telco business case unless you believe in subsidization via ads, which few telcos do.

The next factor, which operates on both the bubble and nothing-new-from-6G groups, is whether anything else could justify a mobile refresh of any sort. Most see nothing other than technology improvements that could be linked to cost reduction. The majority of the bubble group believe that such improvements are viable, and in fact could provide a bridge to the time when low-latency applications would gain traction after 6G rolls out. Maybe even before; most AI RAN proponents (19 of the group think it’s worth looking at, though only 5 think it’s definitely a reasonable direction to take) believe AI is the path to operations efficiency and would also pave the way for edge hosting. They see AI RAN deploying before 6G. Another 18 think AI RAN might be a part of 6G, but even this group is concerned about costs.

72 of the operators in the 6G comment group say that they believe the primary requirement for 6G is to prove an ROI for any investment, and 66 say that they don’t believe that any significant investment could generate enough ROI, so the goal has to be to minimize any 6G costs. Target bubble thinking, not burst thinking, in short.

The Light Reading piece notes some differences in the views of US telcos versus those in the EU, and perhaps also those in Asia/Pacific. My comments validate this to a variable extent. It’s true that US telcos are more likely to be influenced by vendor positioning, which of course favors anything that results in more spending. However, they are still largely cautious; only 1 of the 12 burst-thinking telcos are from the US. Asia/Pacific telcos have, in general, higher demand density than any others in the world, and thus get a higher return on infrastructure spending and value cell capacity and efficiency more. The EU, which has more competition than other geographies, is the home of the most skeptical telcos. There may be a link there to the move to get an EU commitment to telco subsidies from OTTs, of course.

I think that what this shows overall is that 5G had a major impact on telco thinking, and a largely negative one. A few telcos characterize 5G as “the death of the Field of Dreams”, and most telcos seem to embrace the thought if not the exact terminology. They were caught up in what was clearly a vendor-induced hype wave, which resulted in a huge ROI shortfall and a more cautious attitude. However, a slight majority (49 of 88) telcos have, over time, said that they believed that some credible new revenue source was essential for their business, and I think that leads to the size of the “bubble” group; they want to believe but were 5G-bitten and so doubtful of 6G. They’re also doubtful of things like Open RAN, V-RAN, and AI RAN, but to return to a historical analogy of a past blog, to a Titanic survivor in a lifeboat, any light looks like a rescuer coming because the alternative of no-rescue is simply too dire.

There’s a risk here, of course. Being too willing to believe in baseless hype is never a good strategy, but being closed to real opportunity is no better. The challenge is to recognize what real opportunity is, and what 5G has done is debunk the notion that visible market consensus in a hype-and-click-bait age is rarely real consensus. What is? That’s the challenge facing all these telco evolutions.

People talk and listen and see with biological equipment. Thus, they’re prepared to exploit network services that rely on those senses. Unless you believe in remote touch and smell, we have to move beyond sense-exploiting if we need new service opportunities, which means we need to develop an ecosystem to build up applications that exploit those senses in a different way, and that use a service like low-latency connectivity to do that.

Here’s my view. 6G can’t be good, but it can be bad. Other “Gs” are even worse, because as long as there’s a formal body with Field-of-Dreams historicity, vendors will use it to try to push the same sort of hype that gave us the 5G disappointment. It’s those vendors who’s pursuit of profit drives them to innovative thinking that we’ll have to rely on to give us a telecom future, so we have to drive them to do that by shutting off the Gs once and for all. Telco service standards cannot save telecom, but false hope could kill it.

The biggest problem that network operators cite is that AI RAN is too much of a moving target in both cost and benefits. “You talk about building AI into the RAN,” one technologist said, “as though there was one sort of AI and one model of RAN, and neither is true.” Another: “How much energy can you save if you’re relying on a technology that needs new power plants to run?” There is no real definition of just what’s needed to run an AI RAN model, which means both its capital cost and opex is impossible to predict accurately. The benefits AI RAN targets are only real under certain conditions of deployment, both in terms of density of cells and customers, and in terms of age of existing infrastructure. It’s also uncertain whether an advance in wireless standards to 6G could justify a shift to AI from ASICs, given that telcos don’t want 6G to require a forklift because 5G hasn’t returned on the investment in it.

How do you fix this? “The AI RAN camp needs to put its technology on a diet,” says one operator expert. “We aren’t going to run an AGI [artificial general intelligence] model at a cell site.” Most of the dozen operators told me that they believe AI RAN should perhaps be called “ML RAN” because they think the real needs of AIops could be realized with machine learning and a modest hosting requirement. That would lower both the cost of the gear and the power and cooling requirements. But, they say, all the impetus behind AI RAN is being created by chip giants like Nvidia, who don’t want a watered down model.

That gives rise to the second problem, which is AI RAN has become a theoretical on-ramp for edge computing. If you can’t lower costs with superchip AI RAN, sell AI services as edge services, the theory goes. “Who do we sell it to?” one operator asks. “Why would we win against hyperscalers who are already selling AI?” Not at the network edge, perhaps, but every cloud provider does offer an on-premises middleware tool that’s clearly a camel’s nose for any edge service tent that becomes feasible. “So because we can’t make an AIops business case for AI RAN because it’s too suppositional, we should add some other value thing in that’s even more iffy.”

Edge services at the network edge rather than in the metro, according to operators, it just too big a step. If you want extreme latency control, host on premises next to the processes under control, which is and has been the established practice. The only way to break out of that would be to lower the cost of your edge service radically, which can’t be done profitably unless you can achieve a mighty economy of scale. At a cell site? Get real. Even metro hosting could be challenging, but that’s where you have to start with edge computing. Instead of moving expensive assets out to the cell edge, you lower latency between customer and metro, something that was a goal for 5G and is expected to be one for 6G.

The third question raised comes out of this evolutionary approach. Given that AI technology is changing rapidly, and that many of its value propositions are under pressure, how do you justify a long-term investment in it? Telcos typically depreciate over a longer cycle than enterprises, and if AI is something that has to be eased into, how long could it take before we have a convincing AI answer? What’s the risk of investing in it without such an answer, especially if the final justification emerges only at the end of a long and as-yet-undefined application evolution to something like real-time, augmented reality, robots, and so forth?

This issue can be seen as a consequence of the other two. Time, they say, heals all wounds, and while that’s nonsense at one level, it is true that many if not all the other issues could be resolved by the evolution of network-dependent applications, particularly those elusive real-world-real-time applications I’ve blogged about in the past. Given that, you could argue that AI RAN benefits are inevitable, so why not get started? The problem is that the realization of the benefits and the evolution of the best-available technology could render current investment obsolete. How then can you justify getting started?

The only possible answer to this one is to work hard, right now, to frame the technical requirements for those future applications, and assess AI/ML directions to align the technology with the needs. That could redirect early investment in AI RAN along lines more likely to create an optimum return on investment for network operators. The problem with this lies in the inherent opportunism of the vendors in the AI space who would almost surely dominate that hard work. We can see today that Nvidia’s focus is on validating its own market position, which tends to create an emphasis on things like large-scale robotics, which would require considerable work and time to integrate into enterprise operations and people’s lives. What these require is not the question that early evolutionary steps would need to answer. It’s not the final, most exciting destination, but the first steps on the route, that really matter.