Single-provider agents are a liability

An agent wired to a single provider has a dependency that can change price, quality, or availability on any given Tuesday, without your consent and mostly without notice. That's not an architecture. That's an unhedged position. A multi-provider strategy is how you hedge it, and the argument for one is much broader than "what if they go down" — outages are actually the least threatening item on the list, because at least you find out immediately.

I'll make the case, and then I'll take the counterargument seriously, because multi-provider has real costs and pretending otherwise is how teams end up half-committed to it, which is worse than either extreme.

Four ways one provider hurts you

Outages are the obvious one, and the one with the best-developed playbook — I've written about what happens to agents when a provider goes down, and the short version is that a hardcoded agent inherits every incident on its provider's status page as an incident of its own. But outages are loud, brief, and nobody's fault in procurement's eyes. The other three are quiet.

Unannounced quality drift. Providers change things — index freshness, ranking, extraction fidelity, model snapshots behind an unchanged API version. Your integration keeps returning 200s while the substance degrades. No status page, no changelog entry, no error to alert on. If you're single-provider, you have no baseline to notice the drift against; your only reference point is the provider's own past behavior, measured by nobody. The teams that catch drift are the ones evaluating providers on their own traffic, and the cheapest way to have a comparison point is to already be running a second provider on part of your traffic.

Pricing changes. The price you integrated at is not a contract; it's an opening offer. I've made the longer argument in tool prices didn't fall, but the strategic point is simple: your willingness to pay a repriced rate is a direct function of how expensive it is to leave. A single-provider agent is maximally expensive to move, and vendors can price to that. The gap is real money — the identical web search runs $0 to $0.005 per call across providers today, a spread that only helps you if you can actually route across it.

Quota cuts. The least discussed and, for growing products, the scariest. Rate limits and quotas are granted, not owned. A provider having capacity trouble, changing its tiering, or deprioritizing your segment can cut your throughput with a fraction of the notice a price change gets. If they're your only provider, their capacity planning is your product roadmap.

Notice the shape: only the first of these four announces itself. The other three you discover on your own timeline — usually late — and a single-provider agent has no move available when you do.

Portability is a constraint, not a project

The standard objection: "we'll add a second provider when we need one." That plan has a hidden assumption — that switching cost stays constant over time. It doesn't. It compounds.

Every month single-provider, the provider's quirks sink deeper into your stack. Response fields nobody documented get depended on. Prompts get tuned to one SERP's shape. The provider name shows up in tool definitions, in eval fixtures, in the mental model of everyone who debugs the agent. By the time the pricing email or the quota cut arrives, "add a second provider" has become a migration project competing against feature work — during whatever emergency prompted it.

The alternative is to make portability a day-one design constraint, which costs almost nothing at day one. Concretely: your agent's tools are named for capabilities, not vendors — search, not providername_search. Responses are normalized to a shape you own before anything downstream touches them. Provider choice lives in one routing layer, in config, instead of being smeared through the codebase. That's it. You're not running two providers yet. You've just refused to weld the first one in. This is the same discipline as treating your API dependencies as a price ladder: the ladder only works if rungs are swappable.

Insurance you've already tested

Here's the part I care most about, as someone who operates this daily: a fallback chain is a multi-provider strategy that has already survived contact with production. Not a runbook. Not a "we could switch to X" slide. Live traffic, flowing through your second and third choices, every day.

That matters because untested insurance is where reliability plans go to die. If your backup provider only receives traffic during emergencies, the emergency is when you discover its response quirks, its rate limits, and the normalization bugs in your adapter — all at once, alongside every other agent fleeing the same outage. A free-first ladder avoids this by construction. The cheap rungs handle real queries daily; the paid rungs catch real fall-throughs daily. Every rung is warm. When one disappears, traffic reshuffles across providers you already trust, because you've been grading them continuously without setting up a grading project.

And the insurance premium is negative. The routing layer that gives you provider independence is the same one that stops you paying $0.005 for searches a free index answers. You're getting paid to hedge.

The honest counterargument — and how to bound it

Multi-provider is not free, and the costs land exactly where advocates tend to mumble. Every provider you add is an integration to maintain, an API to track, a set of quirks to normalize. Worse, it's an eval burden: claiming two providers are interchangeable for your traffic is an empirical claim, and verifying it takes ongoing work. Unbounded, that work eats the savings.

So bound it. Cap the ladder — two or three providers per capability is a hedge; five is a hobby. Normalize once, at the routing layer, so downstream code has exactly one response shape regardless of rung count. Evaluate on sampled production traffic rather than bespoke benchmarks, so the eval cost scales with your attention, not your call volume. And let the receipts do the monitoring: if every result carries provider_used and cost_usd, the per-provider quality and spend questions become grep queries instead of quarterly investigations. Bounded this way, the second provider costs a few days up front and hours per quarter after. Against the four risks above, that's cheap.

Where to start

If you're single-provider today, don't start by signing up for three competitors. Start by making your one provider swappable: capability-named tools, normalized responses, provider choice in config. Then add one rung below your current provider — free if your workload allows it — and route real traffic down the ladder. You now have a tested fallback, a drift baseline, a pricing hedge, and a smaller bill, from one integration.

The pattern generalizes past search and extraction; it's the core of everything on the provider routing hub. Single-provider isn't a simplicity win. It's a risk position with a monthly premium you're paying in rack rates. At minimum, know that you hold it.