This is The Internet Report, where we analyze outages and trends across the Internet through the lens of Cisco ThousandEyes Internet and Cloud Intelligence. I’ll be here every other week, sharing the latest outage numbers and highlighting a few interesting outages. This week, we’re taking a break from our usual programming for a conversation about agentic AI and the key things NetOps teams need to take into account in this new agentic world. As always, you can read more below or tune in to the podcast for firsthand commentary.
Agentic AI and the Future of Data, Resilience, and Innovation
The transformation of our digital landscape is accelerating. The latest wave isn’t just a matter of higher bandwidth or better uptime. What we’re witnessing now is the rise of autonomous software agents acting as tireless digital citizens—agentic AI. If you’ve ever wondered how AI might evolve beyond chatbots or how the Internet’s fabric might adapt, you’re in for a fascinating exploration.
In this episode of The Internet Report, we explore a new breed of AI agents that don’t merely assist humans, but operate independently, executing complex workflows, making decisions, and transacting across multiple services without human intervention. We touch on some profound implications of this advance for businesses, infrastructure, and data management. We also address the new requirements for agentic AI success that necessitate a significant shift in priorities for NetOps teams.
We’ll discuss:
- The rise of autonomous AI agents: Hear how agentic AI is transforming the Internet and reshaping how organizations design and manage their networks.
- Why data quality is more critical than ever: Find out why data accuracy, provenance, and freshness must be validated for agentic AI success; and the business risks that can result from poor data quality.
- The impact of agentic AI on networks: Discover how the unpredictable behavior of AI agents is driving a shift in bandwidth management toward end-to-end resource orchestration—and demanding new strategies for service resilience and capacity planning.
To learn more, listen now and follow along with the full transcript below.
A Conversation on How Agentic AI Shakes Up the Internet Landscape
BARRY COLLINS: Hi, everyone. Welcome back to the Internet Report, where we uncover what's working and what's breaking on the Internet, and why. This week, we're examining how agentic AI is resetting the Internet as we know it, shifting focus from bandwidth and uptime to data quality, service resilience, and end-to-end assurance.
I'm Barry Collins, and I'll be hosting today with the amazing Mike Hicks, Principal Solutions Analyst at Cisco ThousandEyes. As always, we've included chapters in the episode description, so you can skip ahead to the sections that are most interesting to you. And if you haven't already, we'd love you to take a moment to give us a follow—over at Spotify, Apple Podcasts, or wherever you like to listen.
Today, we're chatting about agentic AI and its impact on network infrastructure.
To start, give us a quick overview of agentic AI, Mike. What makes it fundamentally different from previous generations of AI or automation?
MIKE HICKS: When we're talking about agentic AI, we're talking about autonomous software agents. These are agents that are capable of making decisions and executing tasks on our behalf. We're not talking just about chatbots or recommendation engines. These are digital actors, so they can complete entire workflows. They're taking their place as digital citizens; they're sort of acting, deciding, and transacting at machine speed.
So, where we had a normal operations system there, these are sort of operating 24/7, and they're participants in the Internet ecosystem. So they're not just tools, they’re not just actioning predictive workflows. They're actually going through and making these decisions.
So distinguish that from AI and automation in the past. You effectively had these tools that assist humans, so they add onto the system. You ask it, you ask a question and they answer, and then you take action across there. Whereas when we talk about agentic AI, so these are digital citizens, they act autonomously. You set a goal and they figure out how best to achieve that. So they dynamically determine their own path, they make decisions, they handle the exceptions.
And because of this, they can span multiple services: different APIs, different data sources, all without human intervention. They're making that decision to go on. For example, if we were looking to search a flight, we wouldn't just say “Find me flights,” we’d say "Book my entire trip based on my preferences and handle any issues that come up from there.” So, when we think about this in the context of the infrastructure network itself, these are now users that sort of run alongside the human users themselves. So, these are digital citizens that don't sleep, and they don't slow down, but they create complex, independent workflows that aren't easily predictable.
BARRY COLLINS: Can you share examples of how poor data quality could impact the decisions and actions of AI agents in real-world scenarios?
MIKE HICKS: When we think about this, it’s actually about orchestrating the entire ecosystem.
So we have to have validated data, we've got to have resilient paths, and we've got to this dynamic capacity that comes around there—which then means when we're thinking about this from a metrics perspective, it's not so much a question of just “Is it up?” We've got to say “Is it right, is it fast, and can we actually trust that data?”
Let’s put that into a use case of a financial institution. In this case, we have an AI agent validating thousands of transactions across multiple banking systems. If we think about all these different paths that we can have there, these dynamic transactions that have to take place, one delayed or corrupted data feed could actually equal sort of a halted trade or compliance failure, or you could actually miss a fraud. We failed to retrieve some part of information because it either timed out, we didn't get it in time, or we're acting on invalid data so we make the incorrect decision. Therefore, then, the actual overall task has failed.
BARRY COLLINS: What strategies should organizations adopt to validate data quality and help ensure trustworthiness, especially when dealing with numerous external data sources?
MIKE HICKS: So, data quality is actually critical. It's not a nice-to-have, it's a necessity.
If we're thinking about AI agents that depend on these data feeds to make decisions and automate these processes, any one part of the bad data can actually have significant consequences. It can result in financial losses or compliance failure. You know, for example, the financial service agent with that corrupted data could mean halted trades or missed fraud.
So, it's not just about the data, but better data that agents can trust to act on. So then, if we have sort of, validation points, or validation requirements we're looking for in an agentic AI system, we need to know what the data is, so there's accuracy and completeness: Do we complete the actual flow we go through? Do we complete that service?
We need to know where it came from. So, provenance tracking: Can we trust this source? Where did we actually retrieve this data from?
And then the validation itself: Is this data accurate to where we can actually use it to make a decision.
We take all those three together and they combined can lead to an automated action?
BARRY COLLINS: How do you go about validating data for AI agents?
MIKE HICKS: If we're thinking then of how to validate that stuff, we've got to have data freshness checks: How current is each source? Are we retrieving data from 1989, or prior to that? Is the information we've got about a price or other information—is what we've gotten up to date? How current is each source?
And then, that cross-source verification: Do multiple sources agree? Because also, we're not necessarily always going to have this agent, or it won't necessarily check that from just one source. It might verify it across other ones.
You build that into that process. When we're checking this weather condition or when you're checking this system, can you confirm this price from different sources? But also then, this sort of fallback hierarchy: If your actual primary source fails, what is your plan B?
What you don't want it to be is, “I couldn't get the data” or “I couldn't verify that data. I'm just going to use what I've got. I'm going to run with that,” because that's when we lead to this failure in the chains. You've got to have this type of [validated] information itself.
Having all those conditions together, then we think about the SLA, and about SLAs prior to this. We're thinking about this consideration where we have loss rate for a particular circuit, or we're having a performance-based SLA from there—availability was what I was desperately searching for—we've actually got a shift from that because an availability system, if we think about those validated sources or that data source we're taking from, just being up and available is no longer sufficient. We've got to now to be able to have an SLA that ensures data is not just available, but it's also current, and it's validated, and it's trustworthy.
This then goes to its completion rate. Now, it isn't just “Were we able to book the flight,” but “Were we able to successfully book the flight and get the flight we want,” for example, in that very simple scenario itself. Because all this data has come across here, we want, then, to have this SLA to reflect what our outcome is. So, we're not just looking at their performance, we're looking at all this data combined.
BARRY COLLINS: In some sectors, such as web publishing, NetOps teams may previously have downgraded or even blocked traffic coming from automated crawlers. But now, with the rise of AI agents, I imagine organizations have to sort valid, nonhuman traffic from types they'd still like to avoid?
MIKE HICKS: So, if we think about traditional crawlers, they are mostly extractive. That is, scraping content, often for search indexing. AI agents are transactional. What I mean by that is, they're actually doing things: They're placing orders, they're checking inventory, they're validating information themselves. So they're acting as representatives of real users of a business and not just collecting data. They're operating with complex workflows, so they might touch multiple APIs and services in one session.
You can't just block these straight away anymore, because it might be a legitimate customer doing the interactions. But you need to understand whose agent it is, what it is they're trying to do, and actually, is the agent authorized to do that? Validation about the intents and capabilities, not just about identifying “this is bot traffic.”
You've got to sort of understand the rate limits: Is it allowed to do this? If it comes from this location, is it allowed to do that? How many queries is it allowed to do? How many times can it actually come back to the world to get information? These sorts of things. The validation change we're talking about here is multidimensional.
So first of all, you have to track provenance: Which AI service and on whose behalf? Which is then the authentication: Now whose agent is this, itself? And then, authorization: What is it trying to do? And is it authorized to do that?
And then this may then, sort of come down into the commercial, or economic side of it: Does it have sufficient quota or credits to actually do that? If we're thinking about retrieving this information, the API calls themselves aren't free. And if we're getting all these agents to do that, then there's a cost involved.
Then you also see this real-time quota checking and the billing validation isn't allowed to do that. And all of this has got to be balanced with the security and accessibility.
Effectively, I don't want to slow this process down while I'm checking it, or I don't want to stop a process there, because although I might have these fallback systems where I go from there, if I actually have information I need somebody to actually use, we also want people to use that—just as long as they're actually sort of coming to the right area there.
BARRY COLLINS: Do you think we might end up with a system where sites have a split design, one for human visitors and another for AI agents, because they have different needs?
MIKE HICKS: Yeah, absolutely. I mean, if you think about a user coming to there, we want a browser front end or website that's going to attract us in and is a simple workflow. And to a lesser extent, that doesn't matter when I'm thinking about it from an agentic perspective or an agent perspective. I just want to get to the data.
So yeah, absolutely, we sort of split there. And whether that then goes to a backend system where we can have this quota checking or we can actually charge that data itself is going to change. And the reason essentially is, you know, these systems are starting to sort of pop up around there, and we're doing it to a degree with API calls. So if I have a developer front end, I'll make an API call to a particular service. I'm not going through the front end, I'm going through the developer tools to actually get to them. That's essentially just an evolution of that.
Does that mean that the front-end web disappears? I don't think so. I think that remains because, as said, humans still exist. We want to go and sort of check and validate this information. But maybe the content, and some of that in the backend, maybe that kicks off a sub-agentic system that actually goes and does this or retrieves this data. So it's actually already in, sort of prefetched to a degree, when we start to come in there based on user patterns.
But yeah, I can quite easily see that split happening.
BARRY COLLINS: Tell us more about the concept of service resilience. What are some of the biggest challenges that enterprises face when it comes to service resilience in an agentic AI world?
MIKE HICKS: Service resilience has sort of fundamentally shifted from keeping the systems up to ensuring the AI agents can reliably complete their missions. We talked about this concept, then, where we have workflow completeness; I need to be able to complete the tasks we're actually doing. I can't just time out, or I can't miss information, or jump something around there.
If I think about that, then, you know, unlike a traditional workflow, which has fixed paths, the agents themselves decide their own approach per task. So this thing creates more complex dependencies compared to what we'd consider from a traditional service architecture, which effectively has these spreading-out dependencies, but they are coming from a mesh scenario. I could have mesh on top of a mesh on top of a mesh.
And then the sources the agent's going to tap into are going to vary by action. I'm not going to have this predictable path. I'm not always going to go from A to B or A to C. I'm going to sort of mix around because there's parts that I'll need information from, parts that I don't. And because of this, you can't actually monitor this for traditional single point metrics anymore.
BARRY COLLINS: Could you explain the concept of end-to-end capacity planning in the context of agentic AI and how it differs from traditional approaches?
MIKE HICKS: Think about the traditional approach; we had: Do you have enough bandwidth? And do you have enough compute? Can I get to the system? Can I run what I'm actually going to do there?
And if we think about the agentic AI reality, we need to think about that entire service delivery chain. We don't know, let's say, where each part of that service delivery chain is going to be. So, it's not just about raw connectivity. It's every step from data source to the agent, which could include the validation layers, the payment gateways, the edge computing nodes, yeah? And effectively, all of it together.
As to how that differs then from the traditional—we've often talked about a service delivery chain, but essentially, even though they were arranged in a mesh, we knew the components that were involved in that service delivery chain. Now these can sort of be ‘dynamically allocated,’ as it were. We don't necessarily know which service or which tool I'm going to call to complete a task because it's making decisions about where it's going to go.
With the old model, you could effectively—well, let's go right back in time—I could throw bandwidth at a problem. I could just up the bandwidth, and everything would actually work. Then we moved to distributed architecture and effectively, we could increase our bandwidth, but we didn't control the entire path. But we still had an idea of where our services were, these dependencies where we're actually going to. We knew we would go from here to there. If we had a particular latency column, we could actually move a CDN there and we have bandwidth coming into that one there.
Now, if we're thinking about that, we sort of added to that again. The agents now create complex multi-hop workflows that touch dozens of services. The bottleneck can be anywhere in that chain, and any slowdown can compromise the entire operation. Not only do we not control these components or this bandwidth in between, but also we don't necessarily control the compute side of it. We do not control the path we're going to go from. We don't know which path we're going to take to actually service that particular task itself. It could be sort of anywhere on that journey.
If we think of that from a bank perspective: The bank's backend is supporting thousands of customers, their queries and regulatory checks per second. We have to do that. It's not just about buying more bandwidth into the main data center itself. We need to optimize every single link. We need to be able to understand the model usage patterns so we can understand the spikes. So now, it's ensuring there's no single bottleneck that can slow everything down as we go through that process.
Think about streaming services. They preload popular content to the edge service based on anticipated demand. Now, this is a similar concept for the AI agents, but with a key difference: The agents are going to choose their own path.
So we're working with probabilistic predictions where we're analyzing historical patterns to anticipate the likely agent behaviors. Therefore, we can dynamically allocate resources based on those patterns, even though we can't predict each path. The goal, essentially, is to ensure this seamless performance even during these unexpected surges that take place.
BARRY COLLINS: Finally, how do NetOps teams need to think differently when it comes to agentic AI?
MIKE HICKS: This creates a shift in the mindset. We've moved from “How much capacity do we need” to “How do we orchestrate capacity across this entire service delivery chain?” It's about understanding and predicting, as much as you can, the likely agent behaviors and then prepositioning resources accordingly. In this end-to-end view, every dependency, every hop, every potential failure point needs to be understood, so that if something does go wrong, we want to be able to see where it is but more importantly, you can actually start to optimize that delivery.
So this capacity planning then becomes a continuous predictive exercise rather than just a periodic procurement decision. What you're doing essentially is, you're planning for intelligent workflows, intelligent networking, not just traffic volumes.
BARRY COLLINS: And that's our show. Please give us a follow and leave us a review on your favorite podcast platform. We really appreciate it. And not only does this ensure you're in the know when a new episode's published, it also helps us to shape the show for you. You can follow us on LinkedIn or X @ThousandEyes or send us questions and feedback to internetreport@thousandeyes.com. Until next time, goodbye!
By the Numbers
Let’s close by taking our usual look at some of the global trends that ThousandEyes observed across ISPs, cloud service provider networks, collaboration app networks, and edge networks over recent weeks (November 3-16).
Global Outages
- From November 3-9, ThousandEyes observed 74 global outages, representing a 23% decrease from 96 the prior week (October 27 - November 2).
- During the week of November 10-16, global outages increased 73%, rising to 128.
U.S. Outages
- The United States saw outages decrease to 25 during the week of November 3-9, representing a 44% decrease from the previous week's 45.
- During the week of November 10-16, U.S. outages increased 76%, rising to 44, mirroring the global pattern of increased network disruptions that week.
- Over the two-week period from November 3-16, the United States accounted for 34% of all observed network outages.
