Models & Labs · United States

At WebexOne, Cisco’s Jeetu Patel argues the agent era will be won on context, cost and control

Credited to SiliconANGLE · siliconangle.com · 5h ago

Photograph · SiliconANGLE

For as long as Cisco Systems Inc. has held its WebexOne event, the show has aimed to drive thought leadership in the collaboration industry. This year, with artificial intelligence on tap, it had its fair share of unified communications and contact center.

But more importantly, it was somewhat of a coming-out party for the “new Cisco,” which consolidated much of its historically sprawling portfolio into a single AI platform, with Webex as the place where people and agents meet.

The “One Cisco” story has been shared at Cisco Live and other events over the past year, but for many Webex buyers, this is their first exposure to it at this depth. President and Chief Product Officer Jeetu Patel opened his keynote by framing the market around five forces: Agents are the new workforce, inference is the new workload, tokens are the new currency, trust is the new catalyst and control is the new moat. The underlying message was consistent with other presentations from Patel: If agents run everywhere, someone has to build and secure the infrastructure beneath them.

“We have moved from the age of chatbots, where we just asked questions of a model and got back answers, to agents that are now conducting tasks and jobs for us almost fully autonomously,” Patel said. “These agents act more like digital workers than like just a software tool.”

In many ways, the more interesting commentary came during the post-keynote analyst Q&A, when Patel explained how Cisco got here. Six years ago, he said, Cisco “looked much more like a holding company than a platform company,” with roughly 250 acquisitions and siloed general managers. Webex Control Hub was the first platform experiment. Cisco Cloud Control, which he said came together in nine months, is now the management plane for everything Cisco sells, alongside Cisco Data Fabric for data and Silicon One for silicon.

“Over time, Meraki as a brand will be gone. Over time, Catalyst as a brand will be gone,” Patel said. “We will all be feature managers, not product managers, because all we’re doing is building features for the platform.” I’ve heard Cisco talk about platforms for years, but this is the first time the org chart, sales compensation and roadmap point in the same direction.

The platform discussion laid the foundation for the following takeaways from the keynote:

1. Context, not the model, is the scarce resource

Every vendor has the same frontier models. What makes an agent useful is context: who’s on the team and what was decided last week. Glean CEO Arvind Jain, who joined Patel onstage, explained that without that knowledge, agents “work like a day-one employee.”

He estimated that 80% of enterprise knowledge is buried in meetings, making Webex more strategic than “meetings software” suggests. That’s why the most important Webex announcements focused on integrations. Claude in Webex, built on Anthropic’s Claude Managed Agents, will let teams analyze data, generate content and act on shared context. A Model Context Protocol integration brings Webex context into OpenAI’s dots personal agent. Users can also invite agents into spaces, meetings and calls. Cisco isn’t trying to own the model. It’s trying to own where the work happens.

While all the collaboration vendors espouse the value of data, Cisco has a unique asset, namely data from Splunk, security and networking, which provides an additional dimension into what users are doing and where they are located.

2. Token budgets will become a line item, and the network will feel it

Citing OpenRouter data, Patel said agent token consumption surpassed human consumption in February and is now five times higher. He also said that an agent consumes 450% more network bandwidth than a human performing the same task and that 60% of global compute this year will be used for inference rather than training.

“The costs of tokens coming down are nowhere near the demand going up,” he said. “So all of us are going to have a human budget as well as a token budget.” Patel told the audience that by the end of this month, every Cisco manager will know their token budget.

Jain called out how unusual that is. “Technology is always supposed to be a fraction of the cost of your labor,” he said. “It cannot be like this forever.” Until that changes, agents that run around the clock reshape information technology cost models and network capacity planning, areas where Cisco has a clear interest.

3. Trust has moved from brake to accelerator

“Historically, in everything we’ve seen in tech, trust has never been a catalyst,” Patel said. “It’s always been an impediment to adoption.” Agents deliver value only when granted access to calendars, email, and credit cards, which requires trust. He compared agents to teenagers: “They’re supremely intelligent. They have no fear of consequences.”

More important is his argument that security and observability are converging because both prompt injection and agent drift appear in telemetry. “You cannot be doing security enforcement through static policy at design time,” he told analysts. “They’re dynamic policies that are enforced at runtime.”

He went further: “He who wins agent security is going to win the security stack.” The proof point is that Webex AI Agents run within Cisco AI Defense guardrails, with live telemetry and observability from Splunk. Cisco can do this natively, while other collaboration vendors will need to partner, which always adds complexity.

4. The office isn’t going away, but it’s being rebuilt

One interesting question in the analyst Q&A asked why a company should invest in offices if agents eventually outnumber people in meetings. During the event, Cisco took several press and analysts to its newly redesigned Austin office to showcase what modern workspaces should look like. Patel said, “Humans are social creatures.”

He noted that 1.4 billion square feet of commercial real estate is up for renewal and that Cisco’s campus and branch business, historically tied to GDP growth, has grown by more than 20% over the past couple of quarters as companies re-equip offices.

If the refresh is done right, the office itself becomes a data source, as at Cisco Austin. “We see the workplace as an intelligent ecosystem, where the office is an active participant in work,” explained Wayne Andrew of Asahi Beverages.

Intelligent Workplace Experiences combines networking, devices, experience assurance, and space data under Cloud Control, with Workplace Designer, Experience Metrics, and Workplace Insights as new components. RoomOS 27 adds an AI Assistant in 32 languages, and the Ceiling Speaker Pro delivers IP-connected audio over a single Ethernet cable.

Openness is almost a new muscle for Cisco. Through a new partnership with Google, Cisco devices now run fully featured Google Meet natively alongside Webex, Microsoft Teams, and Zoom. “If you’ve invested in a competitor of ours, we owe it to you to make sure that you can actually get the most out of that investment,” Patel said. That’s a smart hedge in a platform war Cisco doesn’t need to win. Historically, Cisco wanted the whole pie, which cost it some deals. Under Patel, Cisco understands that a slice of the pie is fine and often better for the customer.

5. Customer experience is about to be intermediated by agents

Patel said fewer than 2% of people use agents as power users today and predicted that number could reach 30% to 40% within 12 to 15 months. Then consumers send their agents to deal with brands. “Not only does your website need to be dexterous at going out and influencing humans,” he said, “they also have to be dexterous in influencing agents.”

Brands will see far more inbound agent traffic and will need their own agents to maintain direct customer relationships. Patel described the goal as “a relationship concierge for every single one of your customers.” Anurag Dhingra, who leads Cisco’s intelligent workplace efforts, described today’s problem: “Every time a customer engages with you, it feels like they’re starting over.”

Dialog, the new agentic harness for the Webex AI Agent platform, is Cisco’s response. Its agents continue working after the conversation ends, carry context across channels, and learn from human agent judgment. It’s the right shift; execution will depend on how well Dialog integrates with the back-end systems where outcomes are finalized.

Final thoughts

Patel told analysts that “the turnaround is complete” and that Cisco’s innovation pace will only accelerate. The platform work supports both claims. The risk is that customers struggle to absorb it all, a challenge Patel acknowledged. Cisco’s financial performance appears to support Patel’s claim, with Cisco’s stock price up over 50% year-to-date and over 70% since WebexOne 2025. The growth in valuation has come on the backs of product innovation, which Cisco has accelerated despite the massive breadth of its offerings.

For IT leaders, I’d focus on four things. First, track token consumption by team now, before agent spend becomes a surprise. Second, treat agents as identities: Inventory them, assign owners and enforce policy at runtime. Third, bring networking, collaboration and facilities to the same table for workplace refreshes, since their budgets are converging. Finally, ask your CX team how the business will respond when a customer’s agent, not the customer, calls in.

That day is closer than most companies think.

Zeus Kerravala is a principal analyst at ZK Research, a division of Kerravala Consulting. He wrote this article for SiliconANGLE.

Support our mission to keep content open and free by engaging with theCUBE community. Join theCUBE’s Alumni Trust Network, where technology leaders connect, share intelligence and create opportunities.

Are you an AWS customer? Support SiliconANGLE financially by buying your AWS services from our Marketplace portal page and links: https://siliconangle.com/aws-marketplace/

Founded by tech visionaries John Furrier and Dave Vellante, SiliconANGLE Media has built a dynamic ecosystem of industry-leading digital media brands that reach 15+ million elite tech professionals. Our new proprietary theCUBE AI Video Cloud is breaking ground in audience interaction, leveraging theCUBEai.com neural network to help technology companies make data-driven decisions and stay at the forefront of industry conversations.

Google debuts SynthID Detector tool for flagging AI-generated content, but it's far from perfect

Samsung forecasts world record-breaking $80B profit

With GPT-6, ChatGPT's responses are much more visually appealing and interactive

Nvidia, Samsung back $90M round for AI agent startup Nous Research

US government, tech giants and Biohub commit $1.8B to AI biology initiative

Anthropic releases Claude Haiku 5.5 small model and halves Sonnet 5.5 cache read prices

EMERGING TECH - BY MARIA DEUTSCHER. 4 HOURS AGO

Join our community

Models & LabsUnited States

GitLab is adding tools to govern enterprise AI coding

Credited to Tech in Asia · techinasia.com7h ago

Useful

Please enable JavaScript to make this website work.

View the articleTech in Asia

Front Method

Models & Labs · United States

Why AI Inference Infrastructure Fails Differently From Traditional Services

Credited to HPCwire · hpcwire.com · 10h ago

Most engineers know what an overloaded web service looks like. Latency goes up. Queues start growing. CPU gets busy. Eventually requests begin timing out and autoscaling tries to catch up. AI inference systems can fail in some of the same ways, but I’ve found that the usual mental model does not always hold up very well once models, accelerators, batching, and long startup times get involved.

The confusing part is that the service may still look healthy from the outside. Pods are running. GPUs are busy. Requests are still completing. And yet users are already waiting much longer than they should. That is where inference reliability starts to feel different.

Average Latency Can Look Fine While Users Are Already Unhappy

One of the first things I would be careful with is average latency. Inference servers often batch requests together because that makes better use of expensive accelerator capacity. From a throughput point of view, that can be exactly what you want. But the request does not necessarily start executing the moment it arrives.

It may sit in a queue while the server waits for a batch to form. As traffic increases, those waits can get longer. Some requests may also require more work than others, which makes the distribution even less predictable. The average can still look surprisingly normal. The tail usually tells the real story.

If p99 latency is climbing while average latency and overall throughput still look acceptable, I would not call that a healthy serving path. I want to know how long requests are sitting in the queue, how batches are forming, and what the accelerator is doing at the same time. Looking at any one of those signals by itself is usually not enough.

A New Worker Is Not Necessarily New Capacity

Another thing that trips people up is cold-start behavior. Starting a conventional application instance may involve loading configuration, opening connections, and becoming ready to serve traffic. An inference worker can have much more to do.

The model may need to be downloaded or mounted. Large weights have to be loaded into memory. Accelerator state has to be initialized. Caches may need warming. Some serving stacks also perform compilation or optimization before the worker reaches useful performance.

So Kubernetes may tell me another pod exists. That does not mean I actually have another unit of serving capacity yet.

I think this distinction between allocated capacity and ready inference capacity is important, especially during recovery or a traffic spike.

If demand is rising quickly, adding five workers does not help much if all five are still loading models while the existing workers are already overloaded. The scheduler sees capacity coming. The users are still waiting.

GPU Utilization Needs a Different Reading

GPU utilization is another place where habits from conventional infrastructure can be misleading.

With CPU-based services, teams often get used to treating utilization as an obvious scaling signal. Accelerators are different. High GPU utilization can be a good thing. These are expensive resources, and keeping them busy is usually the point.

So when I see high accelerator utilization, my first question is not simply, “Is the GPU too busy?” I want to know what is happening around it. Is queue depth rising? Is accelerator memory becoming tight? Are batches becoming larger? Is p99 moving? Are requests spending more time waiting before execution?

A GPU running near full utilization could describe a very efficient system. It could also describe a system with almost no room left for the next traffic burst. The percentage alone does not tell me which one I am looking at.

The Q ueue Is Where a Small Problem Can Become a Large One

The failure pattern I find most interesting usually begins before anything actually crashes.

Traffic increases. The accelerators are busy, so requests start waiting. The queue grows. As queue time rises, end-to-end latency rises with it. Eventually some clients hit their timeout limits. Then some of them retry.

Those retries go straight back to the same service that was already struggling. Now the queue grows even faster. Autoscaling may eventually add more workers, but those workers still have to load the model before they can take useful traffic. Meanwhile, retries keep arriving.

Nothing in this sequence requires the model server itself to fail. Every component may be doing exactly what it was configured to do.

That is what makes this kind of incident tricky. The failure is not one broken component. It is the interaction between queueing, retries, startup time, and the amount of capacity that is actually ready.

By the time request failures become obvious, the system may already be well into the feedback loop.

Autoscaling Can Arrive After the Problem

This is why inference autoscaling deserves more thought than simply attaching a scaling policy to CPU or GPU utilization.

If queue depth is the first sign that demand is outrunning usable capacity, waiting until the accelerator is fully saturated may be too late. Startup time makes the delay worse.

Imagine the platform decides it needs more workers only after queues are already unhealthy. Those workers now need time to initialize before they help. The scaling decision is effectively responding to traffic that arrived several seconds or even minutes earlier.

For steady workloads, that may be manageable. For bursty inference traffic, it can be painful. I would rather look at queue depth, queue growth, concurrency, ready serving capacity, and worker startup time together.

The important question is not only whether the hardware is busy. It is whether the system can absorb what is coming next.

Sometimes the Right Answer Is Not More of the Same Model

Fallback behavior is another reliability decision that I think teams should make before they need it.

Suppose the preferred model is overloaded and requests are beginning to wait too long. The obvious response is to add more capacity. But that may not be the only option.

For some applications, temporarily serving a smaller model may be better than allowing requests to sit in a queue until they time out. In other cases, a reduced response may be safer than accepting work the system knows it cannot finish within its latency target.

There is no universal fallback strategy. The questions are application-specific. Which requests can use the fallback? How different can the output be? When should traffic move back to the primary model? How will operators know that fallback behavior is happening?

What I would avoid is designing that behavior for the first time during an incident.

The SRE Fundamentals Still Apply

I do not think AI infrastructure needs a completely new reliability discipline. The familiar things still matter. Latency matters. Capacity matters. Load testing matters. Error budgets matter. Observability and failure isolation matter. What changes is the shape of the failure.

An inference service can be unhealthy even while accelerators are busy and errors are low. It can appear scaled because new workers exist even though their models are not ready. It can make its own overload worse because retries arrive faster than useful capacity. And sometimes the safest response is not simply adding more replicas of the same model. Those are the behaviors I would design monitoring and recovery around.

AI infrastructure is still distributed infrastructure. Model serving just adds a few new ways for familiar reliability problems to hide. The sooner teams treat those behaviors as ordinary production concerns instead of unusual AI edge cases, the easier these systems become to operate.

About the author: Sai Joshitha Kathari is a Senior Site Reliability Engineer specializing in distributed systems, Kubernetes, AI infrastructure, observability, and production reliability.