As the landscape of enterprise IT shifts toward autonomous operations, the role of the infrastructure expert has evolved from managing servers to orchestrating complex AI ecosystems. Dominic Jainy stands at the forefront of this transition, bringing decades of insight into how artificial intelligence, machine learning, and high-performance networking converge. His work focuses on the “missing middle”—the gap between raw data collection and the actionable context that modern AI agents require to function without human intervention. In an era where organizations are rushing to deploy AI site reliability engineers and automated security analysts, Jainy’s perspective on balancing operational control with the sheer scale of machine-generated data provides a necessary roadmap for the modern enterprise.
This discussion explores the recent integration of advanced telemetry and data management strategies within large-scale platforms. We examine how the shift from rigid data indexing to flexible data lakes is solving the “cost-risk tradeoff” that has long plagued troubleshooting teams. Jainy also breaks down the technical nuances of observing the AI stack itself—from GPU health to the “tokenomics” of model routing—while highlighting how native hardware integrations are providing a level of visibility that traditional polling methods simply cannot match. The conversation concludes with a look at the emerging “Agentic SOC” and the critical importance of maintaining a clear audit trail for every automated action taken within a corporate network.
Traditional indexing often forces teams to discard data that later proves vital for troubleshooting. How does the shift toward a machine data lake change the way engineers decide what to keep and what to ignore?
For years, we’ve lived in a state of operational anxiety where we had to play a guessing game at the ingest pipe, deciding which data was “gold” and which was “trash” before we even knew what problem we were trying to solve. It was a brutal tradeoff; if you indexed everything, your budget exploded, but if you filtered too aggressively, you ended up with massive blind spots. I’ve seen teams realize, far too late, that a connection-pool debug message they’d been discarding as noise for 11 months was the only evidence of a checkout service timing out. By the time they noticed the failure, the evidence was already gone.
The introduction of the Machine Data Lake, which became generally available this past July, fundamentally flips that script by allowing full-fidelity logs and events to land in low-cost storage without being indexed upfront. Instead of making a high-stakes decision during ingestion, engineers can now let the data sit in a managed, schematized tier until a crisis occurs. If an SRE is investigating a failure, they can simply promote a relevant slice—say, an hour of load balancer logs—into an index for active analysis. This changes the philosophy from “what can we afford to remember” to “what do we need to activate right now,” ensuring that AI agents have access to the raw evidence they need without the organization taking on a massive financial risk.
For an AI agent to operate autonomously, it requires more than just raw logs. What kind of operational and business context is necessary for these agents to make decisions that humans can actually trust?
An AI agent without context is like a high-speed car driving in a thick fog; it has power, but it has no idea where the road is. To truly trust an AI site reliability engineer, it needs to see the world through three distinct lenses. First is the core telemetry—your standard metrics, traces, and events that tell you what is happening. But that’s just the baseline. The second layer is contextual data, which includes code releases, identity information, and application dependencies. If the agent doesn’t know that a new container was deployed three minutes ago, it can’t possibly correlate a spike in latency with that specific change.
The third and most critical layer is the operational and business context, which involves pulling in data from ticketing systems, standard operating procedures, and even cost-usage reports. Imagine an agent that identifies a root cause, finds a solution in a runbook, and then calculates the cost of the fix before proposing it to a human for approval. This level of insight allows the agent to not just “fix things,” but to do so within the clearly defined boundaries of the business. It’s the difference between an agent that blindly restarts a server and one that realizes it shouldn’t restart that specific server because it’s currently handling a high-priority financial transaction.
You’ve mentioned that while many platforms can collect data via standard protocols like SNMP, native integration offers a significant advantage. Can you walk us through a scenario where this difference in resolution becomes a “make-or-break” moment for a network team?
The difference between standard polling and native streaming telemetry is often measured in the seconds that determine whether an application stays online or crashes. Consider a checkout API that starts stalling for two seconds, but only a few times every hour. On a competing platform using standard SNMP profiles, you might have a polling interval of one to five minutes. When you look at your dashboard, you see a smooth average of network traffic that looks perfectly healthy, because a microburst—a massive spike in traffic lasting only a few milliseconds—is completely smoothed out by the averaging process. You’re essentially flying blind to the real cause of the latency.
However, with native integration from devices like those in the Cisco and Meraki portfolios, those per-second queue drop counters arrive at a streaming cadence. On the Splunk platform, these counters are already tied to the device’s topology and health events within the network intelligence app. Instead of a long, manual integration project where you’re trying to stitch together custom collectors, the correlation between a microburst on a leaf switch port and an application trace becomes a simple search. You move from “something is wrong but we can’t see it” to “here is the exact millisecond the buffer overflowed” in a fraction of the time.
As organizations deploy more AI agents, the focus is shifting toward “observing the observers.” How does monitoring the AI stack itself—GPUs, vector databases, and model performance—differ from traditional infrastructure monitoring?
Monitoring the AI stack is a completely different beast because the failure modes are so much more subtle than a simple “server down” alert. We are now looking at the health of GPUs and the efficiency of vector databases, but we also have to look at the actual logic of the agents. This is where tools like Splunk Agent Observability and the Luna evaluation models come into play. Luna allows us to grade every single piece of agent traffic in real-time, rather than just taking a random sample. This is vital because it provides the speed and low cost needed to implement guardrails that can block an unsafe action before a tool call is even executed.
Beyond the hardware, we have the concept of “Tokenomics,” which is basically the heartbeat of AI operations. Enterprises are already starting to route inference tasks from massive frontier models to smaller, cheaper open models sitting on branch servers to save money. But if you change the model, you might change the accuracy of the output. By integrating cost and usage attribution with per-action evaluations, we ensure that cost management doesn’t come at the expense of safety. You can’t have Tokenomics without evaluation; otherwise, you’re just finding a cheaper way to be wrong, which is a dangerous game to play with enterprise infrastructure.
The concept of an “Agentic SOC” sounds like a major shift for security teams. How do these autonomous agents assist in threat hunting, and how do we maintain accountability when an agent takes a drastic action, like deleting thousands of files?
The “Agentic SOC” is about augmenting the human workforce so they can focus on high-level strategy rather than getting buried in the noise of a thousand alerts. These agents are designed to handle detection engineering, threat hunting, and even investigation and response by looking at the business risk context. However, the “delete 10,000 files” scenario is the perfect example of why we need a unified timeline. If an agent deletes a massive amount of data, the agent observability layer helps us reconstruct the exact workflow and tool calls that led to that decision. Was it a faulty script, or was it a legitimate response to a detected ransomware attack?
By bringing the identity of the agent, the resources it affected, and the security implications onto a single timeline, we can distinguish between an authorized operation and a malicious attack. With the new Essentials and Premier editions of Enterprise Security, we can apply different levels of autonomous defense depending on the organization’s comfort level. This transparency is what builds trust. We also have a multiyear agreement with AWS to develop even more sophisticated capabilities for fighting AI-driven attacks, ensuring that as the threats become more autonomous, our defenses are staying one step ahead.
With the rise of the Cisco AI Pod and the ability to run these stacks in air-gapped environments, how are you seeing the balance shift between public cloud and private infrastructure for AI workloads?
We are seeing a very strong pull back toward the private cloud for high-stakes AI workloads, primarily driven by data sovereignty and the need for low-latency decision-making. The Cisco AI Pod for Splunk is a great example of this; it allows companies to run the entire stack—including Nvidia acceleration—on-premises or in air-gapped environments. This is particularly attractive for industries like finance or defense where the data simply cannot leave the building. It provides a “single point of accountability,” which is a huge relief for infrastructure teams who don’t want to be caught between a software vendor and a hardware provider when something goes wrong.
Of course, this also raises the question of vendor lock-in, which is something every CIO has to weigh. But for many, the trade-off is worth it because of the pre-integrated nature of the stack. You get the templates, the Model Context Protocol tools, and a choice of models all ready to go. Since June, the free edition of the Observability Cloud has lowered the entry price, making it easier for teams to experiment with these private setups before committing to a full-scale deployment. It’s about giving organizations the flexibility to choose where their intelligence lives without sacrificing the visibility they’ve come to expect from the cloud.
What is your forecast for the evolution of AI agents in the enterprise over the next few years?
I believe we are moving toward a “federated intelligence” model where the network itself becomes the computer. Within the next two to three years, we won’t just be talking about agents sitting in a central cloud; we will see agents living at the edge, on branch servers, and within the switches themselves. These agents will be capable of making micro-adjustments to traffic flow and security postures in real-time, responding to microbursts or security threats before the data even reaches a central dashboard. The “Fabric” we are building today is the nervous system for that future.
The real test for the industry will be the “Trust Gap.” We will see a massive surge in agent adoption, followed by a brief period of retrenchment as organizations realize they haven’t properly instrumented their AI for “explainability.” The winners will be the companies that invest in a unified data layer now—shifting from reactive monitoring to proactive, agentic control. By 2028, the idea of a human manually investigating a network hiccup or a security alert will seem as antiquated as manually patching a server does today. The infrastructure will finally be smart enough to look after itself, provided we give it the context and the guardrails it needs to succeed.