Why Your AI Agent Should Never Depend on One Provider
Source: Dev.to
Setup
I run OpenClaw as my persistent AI agent. It handles research, content drafting, code reviews, scheduled checks, and a bunch of automation tasks. Over the past month I built a fairly sophisticated system:
- 14 cron jobs running at various intervals
- A brain‑as‑router architecture where a central model delegates tasks to specialized sub‑agents
- A workspace full of memory files that give the agent continuity between sessions
All of it pointed at a single provider.
I knew this was a risk. “Design for provider independence” was on my to‑do list, but the system worked so well that the migration kept getting pushed to next week. Classic.
The moment of truth
When the provider dropped support I had a three‑day window to migrate. The actual switchover took an afternoon—not because I’m fast, but because the architecture was already right.
OpenClaw separates the model from the system:
- Models are configured in
openclaw.json. - Cron jobs specify which model to use as a parameter.
- Sub‑agents accept a model argument when you spawn them.
The prompts, memory files, workflow definitions, and tool configurations don’t care which model runs them.
So the migration was mostly:
- Change the model name in OpenClaw’s config.
- Update the cron payloads.
- Restart the gateway.
Done.
The panic wasn’t about the migration itself; it was about not having tested it before I needed it.
What actually breaks
When you switch providers the obvious thing changes: the model. But there are subtle things that can trip you up.
| Issue | What to watch for |
|---|---|
| Thinking modes work differently | One provider may expose “extended thinking” as a visible stream; another may handle reasoning internally. Identical prompts can produce different behaviours because the model interprets instructions through different training. |
| Tool‑calling conventions vary | Function‑call syntax, error handling, and result reporting aren’t standardized. A sub‑agent that works perfectly on one model might hang on another (e.g., my first sub‑agent on the new provider stalled for 21 minutes after a connection drop). |
| Rate limits and pricing flip your cost model | Moving from an unlimited subscription to pay‑per‑token forces you to reconsider which tasks truly need the premium model and which can run on a cheaper alternative. |
| Context‑window sizes differ | Going from 200 K tokens to 1 M tokens sounds like a pure upside, but it changes when compaction triggers, how much history the model sees, and how your memory management works. More isn’t always better if your compaction strategy was tuned for a smaller window. |
The architecture that saved me
Models as configuration, not code
In OpenClaw the default model appears once in openclaw.json. Everything else references it indirectly. Changing the primary model updates every session, cron job, and sub‑agent on the next run.
// openclaw.json
{
"agents": {
"defaults": {
"model": "google/gemini-2.5-pro",
"thinking": "low"
}
}
}One line. Update the provider, restart the gateway, and every component picks up the new default. If your model is hard‑coded in prompt templates, scattered across cron definitions, or baked into deployment scripts, you’ll have a bad time.
Fallback chains
OpenClaw lets you configure a primary model and a list of fallbacks. If the primary fails (rate‑limit, outage, authentication error) the system automatically tries the next one.
// openclaw.json
{
"agents": {
"defaults": {
"model": "google/gemini-2.5-pro",
"fallbackModels": [
"google/gemini-3.1-pro-preview",
"google/gemini-2.5-flash"
]
}
}
}The primary handles normal requests. If it hits a rate limit or returns an error, OpenClaw tries the next model in the chain automatically. You can even keep your previous provider at the end of the fallback list as a last resort while you still have access.
This isn’t just for migrations; it improves everyday reliability. Provider APIs go down, rate limits get hit—fallback chains keep your agent running.
Task‑based routing
Not every task needs your best model. I ended up with three tiers:
| Tier | Role |
|---|---|
| Brain | Stable, mid‑range model that handles conversation and routing decisions |
| Heavy‑lift | High‑capability model for coding tasks and complex analysis |
| Light‑weight | Cheap, fast model for notifications, formatting, and simple generation |
The brain decides which tier a task needs, then spawns a sub‑agent on the appropriate model. In OpenClaw, cron jobs and sub‑agents accept a model parameter directly:
// Cron job — runs on the cheap model
{
"label": "morning-news",
"schedule": "0 9 * * *",
"model": "google/gemini-2.5-flash",
"thinking": "off",
"task": "Deliver today's top 5 news items"
}// Sub‑agent spawn example
{
"name": "code-reviewer",
"model": "google/gemini-3.1-pro-preview",
"task": "Review the pull request and suggest improvements"
}Takeaways
- Treat the model as a config value, not a hard‑coded constant.
- Build fallback chains to survive outages and rate limits.
- Route tasks by capability so you only pay for the power you need.
With those three design decisions, a provider shutdown that could have taken a week to remediate became an afternoon fix. If you’re building a persistent AI agent, bake provider independence into the architecture from day one.
Cron job — runs on the expensive model
{
"label": "weekly-review",
"schedule": "0 18 * * 5",
"model": "google/gemini-2.5-pro",
"thinking": "medium",
"task": "Run the weekly strategic review"
}What I’d do differently
If I could go back, I’d do three things from day one.
-
Test failover before you need it.
Once a month, temporarily switch your primary model to the fallback and run your system for a few hours. You’ll find the subtle incompatibilities while you still have time to fix them. -
Keep a migration checklist.
Not a plan— a checklist. The kind of thing you can execute under pressure when your provider announces a breaking change. Mine has 15 items. I wish I’d written it before the clock was ticking. -
Track which models your cron jobs actually need.
Audit this quarterly. You’ll almost certainly find tasks running on expensive models that could run on cheaper ones.
The real lesson
Provider independence isn’t about distrust. I liked my old provider—the models were great, the developer experience was smooth. But companies change pricing, drop platform support, shift strategy, or just have bad days where the API goes down for hours.
Your prompts, your context files, your workflow definitions, your memory system—those are your real assets. The model is the most replaceable part of the stack. Build like it is.
The migration forced me to see my system clearly. And honestly, it’s better now: multiple models, each doing what they’re best at, with automatic failover if any single one goes down. That’s not a compromise. It’s an upgrade.
If you’re running an AI agent today and everything works great on one provider, that’s wonderful. Now go test what happens when it doesn’t.
This is part 1 of a series on model migration and multi‑model architecture. Next up: how to set up task‑based routing so different models handle different types of work.
Have you gone through a provider migration? What surprised you? I’d genuinely like to hear, especially if you found gotchas I haven’t hit yet.