A few weeks ago, I was brainstorming with a Principal Engineer from our Customer Experience (CX) Engineering team. We were discussing our CX transformation via AI-native workflows, specifically about the role that harnesses play in that work. During our discussion, one thing stood out: almost nobody in the team used just one harness, myself included. Most of us run several harnesses and several models, picking the one that best fits the task. Evaluations and reasoning, adversarial analysis, and deployment considerations are examples of tasks that yield better (and many times different) results when leveraging distinct harness and model combinations. Nobody told us to work that way. It’s simply how the best work gets done.
That conversation sent me back in time.
I joined Cisco in 2000, in the middle of the internet buildout. So when people compare today’s AI buildout to the late 1990s, I understand why. The capital, the speed, and the sense that everything is about to change; it’s all familiar. The one real difference is the pace. This time it moves much faster.
But I think there’s a more useful comparison to consider. The internet analogy explains the buildout. It does not explain how AI moves from our personal lives into the enterprise, from consumer to business, and from chat to agentic work. For that, don’t look at the internet. Look at the iPhone.
The Pattern We Have Seen Before
Apple debuted the iPhone in January 2007. It was a consumer device, and it set a new bar for what a personal computing experience could be. The iPad reinforced that shift. Within a couple of years, employees were walking into the office with a better computer in their pocket than the one IT had issued them. They did not ask for permission. They asked why their work experience could not be as convenient as the rest of their life.
The industry gave that pressure a name. “Bring your own device” entered workplace jargon in 2009. By early 2011, BYOD had gone mainstream. What I remember most about that time is how the corporate conversation changed. It started with “no,” but after many meaningful conversations with employees, it ended with “how.” The companies that came out ahead did not ban the devices. They made their systems safe to reach from them. That forced change and evolution on identity, policy, and device management in the workplace, among others. That experience taught me that saying “yes” safely is an architecture problem, not just a policy memo.
The Same Pattern, Much Faster
AI has already had its consumer moment. Chatbots were the Business-to-Consumer (B2C) sensation. Then something more interesting happened. During 2025, the harness arrived. A harness is the “software around the model”. It plans the work, makes the calls to tools, reads and writes files, checks its own results, fans out sub-agents for help, and keeps going until the task is done. A chatbot answers a question. A harness gets the work done. And just like smartphones, people who use a harness at home or on a side project do not want to go back. Examples today include Claude Code, Codex, Cursor, Grok Build, and OpenCode.
So here is how I see things playing out (and the trajectory I am watching): We are about to see BYOH, Bring Your Own Harness, gain momentum. Engineers, operators, and consultants will bring the harness they already trust into their day job, as well as into their customers’ projects. In many teams, it’s already happening, sanctioned or not.
The New Question Is Not Only Security. It Is Trusted Context.
In the BYOD days, the hard question was security. Is the device safe? Can we wipe it if it’s lost?
With BYOH, the security question is still there, and it gets bigger. A harness does not just display data. It acts on it. But there is a second set of questions that BYOD never had to answer: Is the harness working from the right context? How do you keep the context consistent and up to date across different harnesses?
A harness without trusted context will sound confident, but it may be wrong about your network, your risk, and your overall resilience.
That gives us two failure modes. The first is overreach, where a harness sees or changes more than it should. The second is under-grounding, where it fills the gaps with guesses. Most AI risk discussions focus on the first. In my experience, the second is the one that quietly erodes trust.
Bringing your own harness (BYOH) also means choosing where the customer’s context travels; which model provider sees it, and under what terms, is a decision the partner and the customer should make together, not one the harness makes by default.
In other words, trusted context has become part of the security perimeter.
Where Cisco IQ Fits
During Cisco Partner Summit 2026, Liz Centoni explained why Cisco IQ is the engine and partners are the business. Vikas Butaney described the new partner operating model it enables. Bhaskar Jayakrishnan covered Cisco IQ’s design and associated principles. Here, I want to look at the pattern around it: What happens when partners bring their own harnesses, and what it means for how they work.
This is where I see Cisco IQ playing the role of trusted context for BYOH when it comes to Cisco partners. The parallel with BYOD holds up closely:
With the APIs and MCP capabilities announced at Cisco Partner Summit (shown in use in Figures 1 and 2), a Cisco partner can bring their own harness to a customer project, a services proposal, or a support engagement, and connect it to generate personalized insight from Cisco IQ. The harness does not need to guess the facts. It can ask, and Cisco IQ answers with information grounded in that customer’s environment, but only the information the Cisco partner is allowed to see (as granted by the customer). Reading and changing are separate permissions, so a harness can be given the right to ask without the right to act.
A typical baseline for a Cisco partner project is to understand the installed base of Cisco assets (devices and components) in a customer environment. Cisco IQ provides that trusted context upfront, from where a partner can check if some of that installed base is without support coverage and, if so, whether there is exposure to critical security vulnerabilities, increasing the customer’s risk profile even further.
Here’s an example of how the BYOH approach with Cisco IQ helps a Cisco partner with the first step in that chain (Figure 3). We have an internal demo account in the Cisco IQ production environment, which our teams use to validate and demo scenarios like this. The Cisco IQ UI shows that around 59% of the assets in that account are without support coverage, and you can click through to the full list and details.
In the example below, we leverage BYOH with Cisco IQ and ask the same question in Claude Code, Codex and Cursor: “Out of my IQ Prod environment (available via Cisco IQ MCP server, XRE account), what’s the percentage of all assets (devices and components) without support coverage as of today?”
The point of Figure 3 is not the answer itself. All three harnesses arrived at around 59%, because they all drew from the same trusted Cisco IQ context. What differed was how they got there. Each harness and model reasoned its own way through the data and raised its own observations along the way. For the partner, that means different insights on the same facts, and new perspectives to enrich the proposal and the engagement with the customer.
MCP matters here because it is an open standard, not a Cisco invention. This way, partners are not locked into one AI vendor to work with Cisco IQ, and they can switch harnesses and AI models as the field moves.
The partner chooses the harness. Cisco IQ provides the trusted context and the guardrails. Together, they let a partner move from reacting to customer requests to acting proactively, before the customer asks, with advice shaped by that customer’s own environment, rather than generic best practice.
What I Would Do As A Partner
Three suggestions, from an architecture point of view.
- Find out which harnesses your own teams already use. BYOH is probably already happening in your organization. It’s better to design for it than to discover it.
- Start with read-only. Let harnesses ask questions of Cisco IQ as a trusted context source before you let them change anything. Earn the right to automate.
- Treat trusted context as an asset. The value of a harness is limited by the quality of what it can reach. Customers will judge your AI work as a Cisco partner by how grounded it is, not by which model you picked.
BYOH will move faster than BYOD did. And for Cisco partners, it is less of a risk to contain than a flexibility to use. Your people keep the harness, and the models, they are most productive with. Cisco IQ gives that harness the customer’s real context, under the customer’s rules. That combination is what makes proactive and personalized service possible at the partner scale.
And if you want a place to start, the Cisco Builders Challenge kicks off early next year to reward partners who build new managed services on Cisco IQ. Bringing your own harness is a good way to build them.
