Most AI customer service vendors pick one model provider, build their entire product around its quirks, and call it done. It is the easier path to ship: one API, one prompt format, one set of guardrails to tune. It also means every client inherits that provider's outages, price changes, and blind spots — whether or not the provider is actually the right fit for their store.
We built Wrennon the other way. The agent's reasoning, tool-calling, and conversation state live in a model-agnostic orchestration layer built on LangGraph. The language model underneath is a decision we make deliberately for each client, not a default we ship because it's the one we know best.
What "model-agnostic" actually means underneath
In practice, this comes down to a separation most off-the-shelf chatbot tools don't bother making. The parts of an agent that matter most — how it decides when to look up an order, when to escalate to a human, how it handles a policy exception — are written against an abstraction layer, not a specific vendor's SDK. The model itself is swapped in as a configuration, the same way you'd swap a payment processor without rewriting your checkout flow.
That separation is what makes a genuine provider switch possible later without a rebuild. Your prompts, your evaluation test set, your integration with your store's order and catalog data all carry over. Only the underlying model call changes, and we re-run the same evaluation harness against the new model before anything goes live.
Why locking to one provider is a bigger risk than it looks
The risk of single-provider lock-in rarely shows up on day one. It shows up eighteen months in, when the provider you built on quietly deprecates the model version your prompts were tuned against, or raises per-token pricing right as your traffic scales, or simply isn't the strongest option anymore for the specific job your agent does. By then, a generic chatbot vendor's customers are stuck: their prompts, guardrails, and evaluation suite are all written in that provider's dialect, and migrating means rebuilding from scratch, not swapping a setting.
There's also a capability mismatch that's easy to miss until it costs you. A model that's excellent at natural, on-brand conversation isn't necessarily the strongest at reasoning over a 40,000-SKU catalog with overlapping variants, and a model built for long-context document reasoning isn't necessarily the fastest at sub-second responses during a flash sale. No single provider currently wins on every axis that matters to an ecommerce support agent, and betting your entire build on one means accepting its weaknesses along with its strengths.
Public benchmarks don't resolve this either. A model that tops a general-purpose leaderboard can still underperform on the specific reasoning your catalog demands — parsing a return policy with three seasonal exceptions, for instance, or correctly matching a customer's vague product description to the right SKU. Benchmarks measure averages across generic tasks; your support conversations are not generic, and the only score that matters is how a model performs against your actual data.
What this looks like for your store
At build time, we evaluate your catalog size, expected conversation volume, latency expectations, and any compliance or data-residency constraints you already have — the same inputs covered in a normal process mapping session. From there we recommend a model, or build against one you've already specified for cost or procurement reasons. Either way, your plan pricing and chat allotment don't change based on which model is doing the work underneath.
If a stronger-fit model ships later, or your traffic pattern changes enough that a different tradeoff makes sense, moving your agent to it is scoped and quoted like any other re-engineering work — not a migration project. Your integrations, your data, and your evaluation history all carry over, because none of it was ever tied to a single vendor's API in the first place.
The underlying belief here is simple: the agent should be engineered around your business and your customers, not around whichever model happened to be state-of-the-art the week we built it. Providers will keep leapfrogging each other. Your agent shouldn't have to get rebuilt every time they do.
A quick example of why the choice matters
Picture two clients we might onboard in the same month. The first runs a mid-size apparel brand with a few hundred SKUs, mostly straightforward pre- and post-purchase questions, and a strong preference for a warm, on-brand conversational tone. The second runs a industrial parts distributor with a catalog running into the tens of thousands of SKUs, technical spec questions, and a hard requirement that customer data never leaves a self-hosted environment for compliance reasons.
Building both agents on the same default model would mean over-serving one client and under-serving the other. The apparel brand doesn't need a model optimized for massive technical context windows; the parts distributor can't use a model that only runs on someone else's cloud. Evaluating each workload on its own terms, instead of reaching for the same provider every time, is what actually produces an agent that performs well on day one instead of one that's merely functional.
This isn't a one-time decision
Model selection at build time isn't the end of the conversation. We monitor how your agent performs against real conversations after launch, the same way we monitor any other part of the build. If usage patterns shift — a new product line with different question types, a spike in a language your agent wasn't originally tuned for, a change in your compliance requirements — the model choice can shift with it, without touching the parts of the system that already work.
That flexibility is the actual point of building model-agnostic in the first place. It's not a marketing checkbox. It's what lets your agent stay the right fit for your store a year from now, not just on launch day.
If you're evaluating AI customer service vendors right now, it's worth asking each one plainly which model powers their agent, and what happens if that provider has a bad year. If the honest answer is "we'd have to rebuild," that's a constraint you're inheriting whether it's stated in the sales deck or not.