AI agents put a different kind of pressure on enterprise networks: automated work can increase traffic, consume tokens, and make decisions that demand closer oversight. Cisco’s partner announcements bring those pressures into the buying relationship, with tools that give service providers greater visibility into customer infrastructure and new ways to build models around operational data. For technology leaders, the strategic question is how much responsibility those partners should carry, and how that responsibility will be governed.
Partner Access Changes the Operating Relationship
With roughly 90% of Cisco’s bookings moving through partners, the channel has substantial influence over how customers plan and operate their infrastructure. At Cisco Partner Summit, the company outlined changes that extend that influence beyond equipment selection and support. Partners are gaining access to lifecycle intelligence and model-building capabilities that could place them closer to operational decisions.
Cisco IQ, the company’s AI-enabled lifecycle and support platform, is generally available to partners. Its capabilities include access governed by role, infrastructure risk information, APIs, and a Model Context Protocol (MCP) server. President and Chief Product Officer Jeetu Patel said its data is also being brought into Cisco Cloud Control, connecting lifecycle information with operational management.
That access should change the substance of a planning discussion. A partner with visibility into support status and infrastructure risk should be able to explain which investments deserve priority and which can wait. Leaders should make that assessment an expected deliverable, rather than accept a product proposal as a substitute for understanding the environment.
The potential improvement is concrete. Generali, an insurance and asset management group using Cisco IQ, cut its assessment time for one security advisory covering 16,000 devices from four days to 10 minutes. That example demonstrates faster analysis, though customers should distinguish it from the separate work of approving and completing remediation.
Partners can also offer Cisco IQ support using their own branding. That may simplify the customer-facing relationship, but it makes escalation terms more consequential. Contracts should specify when a problem moves to Cisco, who retains responsibility during that handoff, and how the customer receives progress updates.
Custom Models Create a Longer-Term Dependency
Cisco Model Foundry introduces a different architectural decision. Through the service in Cloud Control, partners can post-train specialized Cisco models using customer data and expose the results through an API. The models cover networking through Deep Network, operations through a time-series model, and security.
Cisco claims Deep Network performs up to 20% better than general-purpose alternatives on networking tasks. A demonstration involving World Wide Technology showed a model adapted using WWT troubleshooting information outperforming a frontier model on 12 previously unseen scenarios. Those results offer a reason to evaluate specialized models, but they do not establish how a particular customer deployment will perform.
Availability also needs to remain part of investment planning. Model Foundry is entering controlled availability with partners taking the initial role, and Patel put planned general availability at June 2027. Cloud Control Studio separately allows customers and partners to create agents, giving them a development path beyond Cisco’s own feature schedule.
For leaders, the lasting concern is what happens after a useful model becomes embedded in operations. A partner may contribute engineering expertise while the customer supplies the operational knowledge that makes the model valuable. Unless ownership and exit conditions are settled early, changing providers could become more complicated than changing a support contract.
Before authorizing that work, customers should establish:
- Who owns the adapted model and what rights survive a contract termination.
- Where training information is held and how its use is restricted.
- How performance will be tested before the model informs operational decisions.
- What the customer can retain or transfer when moving to another provider.
These questions belong in procurement and architecture reviews together. Technical teams need enough freedom to test whether specialized models improve troubleshooting, while commercial teams need to protect continuity. A successful pilot should leave the enterprise with a clearer operating model, including a workable exit path.
Resilience Requires Shared Operational Evidence
Patel described a shift toward agents that perform work with considerable autonomy. He also warned that distinguishing hostile interference from an agent’s poor decision is becoming harder. That creates a strong architectural argument for examining security signals alongside operational telemetry rather than treating them as unrelated evidence.
The response window is another concern. Patel contrasted patching that can take 45 days with exploitation occurring within minutes. Cisco positions Live Protect as an interim defense, using eBPF technology from its Isovalent acquisition to provide compensating protection while a patch remains outstanding.
Cisco says Live Protect now extends to switches, SD-WAN, and wireless LAN controllers, with additional router and firewall coverage planned by year-end. Patel also linked Cisco’s confidence in deploying 85,000 agents for employees to AI Defense. These are vendor descriptions of capabilities and internal use, not a guarantee of protection across a customer’s estate.
An enterprise should therefore ask its partner to map those controls against actual exposure. Which systems can receive interim protection, where does coverage stop, and who verifies that the underlying patch eventually lands? A temporary safeguard needs an owner and a retirement condition, or it risks becoming a permanent exception.
The commercial relationship should support that discipline. A risk-ranked modernization proposal is more useful before an incident than a broad refresh recommendation after one. Partners with access to lifecycle intelligence should be expected to connect their recommendations to service continuity and documented exposure.
Agent Economics Belong in Network Planning
AI consumption can also alter infrastructure economics in ways that conventional capacity assumptions may miss. Patel cited research indicating that agents consume seven times as many tokens as humans, despite meaningful adoption among fewer than 2% of people. He separately said Cisco found an agent used 450% more WAN bandwidth than a person completing the equivalent task.
Patel described agent traffic as more symmetrical, with substantial east-west flows. For network leaders, that is a reason to revisit traffic assumptions before extending automation broadly. A pilot that demonstrates task completion may still leave unanswered questions about bandwidth demand and operating cost at scale.
Cisco’s proposed controls span several layers. Splunk’s federated Cisco Data Fabric supports searching data where it resides instead of requiring everything to be ingested centrally, while AI observability measures GPU utilization and token use. A Tokenomics app provides a way to stop runaway agents, and Patel described four sovereignty options extending from Cisco-managed infrastructure with localized facilities to fully air-gapped arrangements.
The opportunity is better visibility into the cost of automated work. The risk is buying a wider platform without agreeing how its financial benefit will be demonstrated. Each proposed component should have a measurable purpose, such as reducing ingestion expense, controlling token consumption, or shortening recovery.
Put Accountability Into the Purchase
Cisco is also trying to reduce friction around adoption. Patel said ThousandEyes is being included with eligible Wi-Fi access points through Essentials and Advantage licensing after partners raised deployment and licensing difficulties. Ecosystem Deal Registration now recognizes advisors and developers that influence purchases without handling the transaction, potentially bringing more contributors into an engagement.
More participants can add expertise, but customers still need clear responsibility for the service they receive. Someone must own the architecture, resolve conflicting recommendations, and coordinate support when several providers are involved. Incentives that encourage collaboration do not settle those obligations automatically.
Leaders should use the new capabilities to reset partner agreements around evidence and continuity. Request an installed-base assessment, tie modernization proposals to identified risks, and establish data ownership before commissioning customized AI. Then require reporting that shows whether the resulting services are improving recovery, controlling consumption, and keeping the infrastructure supportable over time.
