Splunk .conf26: Agents, Observability and the Cisco Connection

There was no shortage of agentic AI at Splunk .conf26. Agents were everywhere: in security operations, observability, infrastructure, application development and even in the discussion of how organizations will pay for AI. But underneath all of that, I heard a more practical story. Cisco and Splunk are trying to solve three problems that come with broader AI adoption:

A swarm of AI Agents.

1. How to run AI where enterprise data already lives.

2. How to understand what agents are actually doing and costing.

3. How to give those agents more autonomy without giving up control.

Agents Change the Infrastructure Equation

Jeetu Patel spent considerable time talking about agents as a new kind of workforce. Yes, agents can do more work, but they also work differently than humans. A human interacts with an application, gets an answer and moves on. An agent can call other agents, invoke tools, access multiple data sources and continue operating long after the original task was initiated. Agentic iteration creates a very different consumption model for compute, networking, data and tokens than linear human efforts.

Cisco cited some fairly dramatic numbers during the conference:

• Token consumption by agents is growing 14x since early 2024,

• Agents consume roughly five times more tokens than humans for comparable tasks,

• Agents use significantly more network bandwidth.

If these numbers are right and if enterprises deploy thousands of agents, infrastructure consumption changes with them, and suddenly token usage is not just an AI development issue. It becomes an operating expense that somebody has to understand and manage.

Tokenomics: Somebody Has to Watch the AI Bill

Splunk announced new Tokenomics capabilities within Splunk Agent Observability. The idea is straightforward: track token consumption across AI agents and employee use of coding agents such as Claude Code, Codex and Cursor, attribute that consumption, and forecast where spending is headed.

Organizations are rapidly adding AI tools without necessarily having a consolidated view of what those tools cost, which models are driving the cost, or whether that spend is translating into useful work. Splunk is essentially applying an observability model to AI economics.

Of course, Agent Observability goes beyond spend. Splunk is extending the capability into Splunk Observability Cloud and Cisco Cloud Control to monitor agent and model behavior, performance and runtime activity. Splunk also described guardrails intended to identify or block problematic behavior, including inaccurate actions and sensitive-data exposure. Observability, in an agentic environment, is about whether an application or network is functioning properly (as in IT observability) but more importantly it becomes about whether the AI operating across that environment is behaving as expected.

AI Where the Data Already Lives

Another important announcement was less flashy but potentially very important to Splunk's installed base. Cisco and NVIDIA announced Cisco AI POD for Splunk, part of the Cisco Secure AI Factory with NVIDIA. It allows Splunk Enterprise customers to run Splunk AI in their own environments, including private cloud, on-premises and air-gapped environments. Splunk AI Assistant is available on this infrastructure, with Agent Launchpad expected later this year. Customers can also self-host a selection of models, including Cisco's Deep Time Series Model, Google Gemma 4 and OpenAI GPT-OSS 20B, with NVIDIA Nemotron models expected to follow.

AI architecture is becoming a workload decision rather than a simple “pick a model” decision.

The broad model choice demonstrates that not every workload needs a frontier model. Cost, latency, data sovereignty and the nature of the task matter. Splunk also highlighted the potential economics of using smaller models for functions such as agent evaluation, including a Verizon example showing a very large reduction in projected inference cost. It is an interesting case study, although I would not extrapolate one customer's economics across the market. The broader point is that AI architecture is becoming a workload decision rather than a simple “pick a model” decision.

Splunk's Data Story Is Possibly the Bigger Story

For all the discussion about agents, I kept coming back to data. Splunk talked about the Machine Data Lake, federated search and AI-assisted data management as part of a much broader data strategy. The goal is to make more machine data available without requiring organizations to ingest every byte into the most expensive storage tier.

Federated search extends that idea by allowing Splunk to work with data where it already resides, including external data platforms, instead of forcing everything into another data island. Agents are only as useful as the context they can access. If enterprises really do move toward larger numbers of specialized agents, they will need access to telemetry across applications, infrastructure, security, identity and networks.

At CiscoLive, Cisco described Splunk as an intelligence layer supporting Cisco's broader infrastructure strategy. At .conf26, I saw considerably more evidence of that direction.

The new Network Intelligence App, for example, brings Cisco network topology, device health and events into Splunk so an operator can move from an alert to the underlying device and surrounding network context. Splunk Agent Observability is also being surfaced through Cisco Cloud Control. These are not simply two portfolios connected by APIs anymore. Cisco is increasingly designing capabilities with Splunk data and intelligence as part of the architecture.

That does not mean Splunk has disappeared into Cisco. It remains a distinct platform, product portfolio and business unit, and maintaining its ability to work across heterogeneous environments is important to the customers I spoke with. But the line is getting harder to see, and that may be the elephant in the room for longtime Splunk customers.

Observability Is Expanding Beyond Applications

Splunk also introduced several updates that broaden its observability story. Observability Studio (available in GitHub and hyperscaler marketplaces) is intended to make applications “born observable,” helping developers establish telemetry and OpenTelemetry instrumentation earlier in the application lifecycle rather than bolting it on later. The Network Intelligence App expands the view into Cisco infrastructure, and Splunk introduced Essentials and Premier editions of Observability Cloud, including more integrated log analytics.

Individually, none of those changes completely redefine observability. Collectively, though, they show where the market is going. Observability began largely around applications and infrastructure. Now the scope is expanding to include networks, security, AI models, agents, token consumption and eventually the actions agents take. The definition of “full stack” is changing along with the stack itself.

The Agentic SOC Is Moving From Concept to Product

Security was the other major piece of the .conf26 story. Splunk expanded what it calls the Agentic SOC Workforce with specialized agents supporting areas such as detection engineering, threat hunting, investigation, response and governance. I think “workforce” is still too much of a "marketecture" term, but the underlying framework is important. Instead of one general-purpose AI assistant sitting beside an analyst, Splunk is moving toward multiple agents with defined security functions while keeping the human-in-the-loop.

We heard a lot at .conf26 about operating at machine speed. I agree that human-only workflows will increasingly struggle against automated attacks, but I am not convinced that means organizations are ready to hand security operations over to autonomous agents. There is a fairly large space between human-led operations and completely autonomous security, and that is where most enterprises are likely to operate for some time: agents performing more investigation, correlation, prioritization and eventually selected response actions, while humans retain oversight for higher-risk decisions.

Splunk appears to understand that distinction. Much of what it demonstrated included governance, explainability and human control rather than unconstrained autonomy. One customer example presented at the conference showed Constellation Energy reducing response time for an identity-related use case from roughly 20 minutes to 39 seconds. That is an impressive example of what automation and agent-assisted workflows can do, but it is still one use case and not evidence that an autonomous SOC has arrived.

Exposure Becomes Part of the Same Picture

Splunk also announced enhancements to Exposure Analytics, including broader asset coverage, historical change tracking and more business-specific risk context. This is another area I am watching closely because exposure management and security operations have traditionally lived in somewhat separate workflows. It's harder to justify separation when agents can continuously evaluate vulnerabilities, asset context and active security telemetry together. If an organization knows that a vulnerability exists, understands the business importance of the affected asset and can see evidence that the vulnerability is actively being targeted, the response decision becomes considerably more informed. The interesting part will be how far Splunk and Cisco take that workflow. Prioritizing exposure is one thing. Recommending remediation is another, and taking the remediation action autonomously introduces an entirely different level of risk and governance.

Splunk Enterprise Security is also being repackaged around this evolution. The first package, Enterprise Security Essentials brings agentic capabilities to a broader customer base, while Enterprise Security Premier adds greater autonomy and the fuller Enterprise Security feature set. That packaging may end up being just as important as the technology because agentic security will not move into the mainstream if it remains available only to the largest and most sophisticated SOCs.

Partnerships Still Matter

Cisco and Splunk also used .conf26 to reinforce that this will not be a Cisco-only architecture. NVIDIA is central to the on-premises AI infrastructure strategy. Intel participated in the broader discussion around inference and infrastructure. Anthropic was part of conversations around reasoning and agent learning, and Splunk and AWS announced a multi-year agreement to jointly develop security capabilities supporting detection, investigation and response.

Historically, Splunk built much of its position in the enterprise around its ability to ingest and analyze data across heterogeneous environments. And, it seems to be maintaining contextual diversity with these partnerships. Many longtime Splunk customers I spoke with at .conf26 are watching closely to see whether that independence remains intact as Cisco integration deepens.

Cisco can integrate Splunk very tightly into its own architecture and still maintain Splunk as an open data and intelligence platform. Those two things are not necessarily incompatible, but Cisco will have to demonstrate it.

What I Came Away Believing

I did not leave .conf26 believing that autonomous agents are about to take over the enterprise or that the human-led SOC is suddenly obsolete. I did leave believing that the operating model is changing.

Agents create more telemetry, more network traffic, more inference cost and more activity that humans cannot reasonably inspect one transaction at a time. That makes observability, governance and machine data more important, not less, and Splunk happens to sit in the middle of all three.

Splunk gives Cisco something much broader than another security or observability product. It gives Cisco a machine-data and intelligence layer that can increasingly connect infrastructure, applications, networks, security and AI, which brings me back to the elephant in the room.

Two years after the acquisition, Cisco and Splunk are becoming increasingly difficult to view as separate technology strategies, but there are very good reasons for Cisco to preserve Splunk's identity and openness.