---
title: "Why 'Bring Your Own Agent' Is Key to MCP Infrastructure"
description: "Platforms and models change fast. Here's why MCP infrastructure should work with any agent or model you're using, not just the one that's popular today."
canonicalUrl: "https://zuplo.com/blog/2026/08/24/bring-your-own-agent-mcp-infrastructure"
pageType: "blog"
date: "2026-08-24"
authors: "billDoerrfeld"
tags: "MCP, AI Gateway"
image: "https://zuplo.com/og?text=Why%20%27Bring%20Your%20Own%20Agent%27%20Is%20Key%20to%20MCP%20Infrastructure"
---
Enterprise AI is fragmented. Anthropic, OpenAI, and Google continue to
[compete for market share](https://a16z.com/leaders-gainers-and-unexpected-winners-in-the-enterprise-ai-arms-race/),
but there's no clear winner yet. Developer teams are constantly testing new
models, agents, and AI features to get an edge in software engineering, and
balancing that never-ending innovation with stability is challenging for CIOs.
AI is unusually volatile compared to historical IT cycles, and enterprises are
already becoming multi-model and multi-agent. These environments are also
configuring more and more
[Model Context Protocol (MCP) servers](/docs/mcp-server/introduction) to let
agents connect with external data, tools, and APIs. Organizations are quickly
finding that securing and governing MCP usage at scale requires
[a new layer of infrastructure](/mcp-gateway) to operationalize it in practice.
The problem is that these new MCP infrastructure layers, including server
generation, configuration, authentication, discovery, tool curation, and threat
detection, could easily become bespoke to a single agentic platform, limiting an
organization's ability to switch providers.
But given how rapidly platforms and models change, MCP infrastructure should
work regardless of what agents you're using or what models are underneath them.
Below, we'll review the evolution of the AI market and consider why "bring your
own agent" is so important for MCP infrastructure. The agentic infrastructure
platforms that succeed will be the ones that abstract underlying agents and LLMs
and are built to be malleable. This separation-of-concerns philosophy is key to
applying consistent authentication and guardrails across any agent in vogue,
whether it's Cursor, Windsurf, Copilot, Claude, or whatever's next.
## AI models are a moving target
AI models are constantly shifting, with no signs of slowing down. The large
language models (LLMs) themselves are changing day to day, and developers are
constantly using different models in their day-to-day work. F5's
[2026 State of Application Strategy Report](https://www.f5.com/resources/reports/state-of-application-strategy-report)
found organizations use seven AI models on average.
Given models are fine-tuned for different tasks, multi-model approaches are on
the rise. An early 2026
[global survey](https://a16z.com/leaders-gainers-and-unexpected-winners-in-the-enterprise-ai-arms-race/)
of 100 companies by Andreessen Horowitz found 81% of enterprises use three or
more AI model families in testing or production. Models are continually
differentiated for specific tasks, whether it's high-level reasoning,
general-purpose chat, knowledge management, customer support, or programming.
Some organizations also chain multiple models together to compare, critique, and
refine responses.
Academic research and development into AI models is constantly churning out new
advances, quickening the pace of commercial model changes. Just look at
Anthropic's release cycle as evidence: Claude Sonnet 4.6 launched February 17,
2026, Sonnet 3.7 was retired two days later, and Sonnet 4 was retired by
June 15. In 2025-26 alone, Anthropic retired about ten models.
Models that look foundational today may be outmoded in months, or less. Models
can also go offline due to regulatory actions, as we witnessed with the
[Claude Mythos 5 and Fable 5](https://leaddev.com/ai/ai-models-can-disappear-overnight-is-your-engineering-team-built-to-survive-it)
temporary suspension. DeepSeek's rapid emergence was another reminder of how
quickly the AI market changes. All this equates to uncertainty and unusual
volatility for enterprise IT.
## AI agents are constantly shifting
Not only are models undergoing constant development, but agents are constantly
shifting too. Claude Code has quickly become one of the most widely used coding
AI assistants, yet is remarkably only a year and a half old. Before that,
everyone was excited about Windsurf, Cursor, and Copilot. Now, OpenAI Codex is
gaining steam, as is [Goose](/blog/ai-gateway-with-goose), an open-source
alternative that decouples the agent from underlying model providers.
Developers tend to move quickly to whichever agent grants the most value, so
allegiance to specific platforms is low. As proof,
[JetBrains 2026 research](https://blog.jetbrains.com/research/2026/04/which-ai-coding-tools-do-developers-actually-use-at-work/)
found Claude Code use at work jumped from about 3% in spring 2025 to 18% in
January 2026, while Cursor's growth slowed. What matters now is output: as
agentic development becomes common, GitHub says commits on its platform nearly
doubled year over year, surpassing
[1.4 billion per month](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/).
Fluctuation will likely continue as engineering chases velocity and multi-agent
architectures become more common. Stack Overflow's
[May 2026 pulse survey](https://stackoverflow.blog/2026/05/27/agents-on-a-leash-agentic-ai-remains-mostly-monitored-at-work/)
found 17% of developers use multiple specialized agents, and
[OpenAI reports](https://openai.com/index/how-agents-are-transforming-work/)
that its heaviest Codex users generate over 60 hours of work per day across
multiple agents working in parallel.
There are downsides to agent sprawl. For one, it could lead to
[shadow agents](/blog/how-to-avoid-shadow-mcp-servers), which feels probable
given more than half of employees
[surveyed by Okta](https://www.okta.com/newsroom/articles/ai-agents-at-work-2026-agentic-enterprise-security/)
report using AI tools without explicit approval.
With more agents in use, the chances for
[scope overload](/blog/fine-grained-authz-ai-agents) and
[permission drift](https://nordicapis.com/how-to-manage-privilege-drift-in-multi-agent-systems/)
also increase. Beyond the security implications, as more AI tooling is acquired,
the chances of wasting time re-implementing agents due to incompatibilities with
surrounding tools or digital infrastructure also rise.
## AI infrastructure must be adaptive
IBM surveyed 1,000 senior executives in 2026 and found that 71% say switching
their primary AI vendor or model would be difficult, and 91% don't fully
understand their dependencies across AI vendors, models, and infrastructure.
There are no clear winners in enterprise AI, and guessing "what's next" is a
losing game. The answer, then, is to reduce the cost of being wrong by
[architecting for reversibility](/features/gitops).
As I wrote on InfoWorld recently,
[open infrastructure will define the AI era](https://www.infoworld.com/article/4186382/why-open-infrastructure-will-define-the-ai-era.html).
With all the fluctuation going on in the model and agent layer, you can't assume
you'll be using the same model or agent day to day. The surrounding AI-native
infrastructure must be adaptable to this reality: designed to be model- and
agent-agnostic, so enterprises can [swap models](/ai-gateway) and agents at the
drop of a hat.
With this in mind, the industry is progressing toward vendor-neutral AI
infrastructure. This is where neutral, MCP-compatible infrastructure shines. A
[new category of MCP infrastructure](/docs/mcp-gateway/introduction) is
emerging to abstract the governance and connectivity surrounding agent-to-tool
interactions, providing functionality such as:
- [Governing and monitoring agent tool access](/blog/audit-agent-mcp-tool-calls)
- [Authenticating agent-to-MCP connections](/docs/mcp-gateway/auth/overview)
- [Optimizing how agents connect and make requests](/docs/mcp-gateway/how-it-works)
to MCP servers and APIs
- Static security testing and
[runtime threat detection](/blog/7-common-mcp-security-flaws)
- [Usage monitoring for chargeback use cases](/blog/charge-agents-for-mcp-tool-calls)
Such infrastructure should use standard protocols like MCP to remain
interoperable and reusable regardless of what agents you're using or what models
are underneath them. In this way, the governance of agentic environments is
treated as a separate, portable infrastructure concern, rather than being
intrinsic to every individual agent platform.
## MCP gateways should be agent and model agnostic
Most enterprises that need to govern MCP use are also juggling multiple AI
platforms and various underlying LLMs. When you spin up MCP servers, ideally the
servers and configurations for their use should be abstracted from the AI
platform, or else you risk significant rework when switching LLMs and agent
providers.
As such, [MCP gateways](/mcp-gateway) should be built agent and model agnostic
in order to appeal to multi-model, multi-agent realities. Then, you can plug
your MCP servers and tools into whatever agent or model happens to be trending
now or next year, and preserve repeatable settings across an MCP portfolio. In
doing so, you avoid reinventing the wheel or replacing infrastructure with
every model or agent change.
In traditional enterprise IT, you already have a
[separation of concerns](https://nordicapis.com/separation-of-concerns-soc-the-cornerstone-of-modern-software-development/)
across many areas: removing identity from applications, API management from
individual APIs, observability from individual services, and
[networking from workloads](https://www.infoworld.com/article/3830687/how-ebpf-is-changing-container-networking.html).
MCP gateways are arguably the next evolution, acting as an abstraction layer
between the tumultuous AI market and the need to retain durable foundations.
MCP gateways like Zuplo's are built to be flexible by design, letting you bring
your own agent and deploy unified authentication, routing, and
[observability](/docs/mcp-gateway/observability/analytics) across MCP server
interactions. By decoupling MCP server generation and governance from
individual AI platforms, you retain the ability to adapt to frontier technology
with more agility.