What is a model agnostic AI platform?

A model agnostic AI platform makes the language model a setting, so the tools built on it stay the same when the model changes. The platform holds the data, the permissions, the prompts and the tools. The model is a component it calls through one interface.

Three neighbors are easy to confuse with it. A platform with a model picker whose tools are written against one vendor’s API offers several models, but is not agnostic: a change means rewriting the tools. A gateway that relays requests to many providers is one part of the answer, without the data and permissions around it. Open weights are a kind of model, not a property of the platform. A platform can run them and still be tied to one.

Every request to a language model has the same parts: instructions, the conversation so far, the records it should read, the tools it may call and a limit on the answer. A provider layer takes those parts from the platform and writes them in the format one provider expects. It reads the reply back into the same shape. The assistant, the agents and the endpoints never call a vendor’s API directly.

Many providers now accept one format. The OpenAI chat completions API has become a common protocol, and most inference servers for open weights offer it. So do the gateways platform teams put in front of their models. A platform that takes any OpenAI compatible endpoint reaches a long list of models without code of its own for each.

Compatible usually means a subset. Ollama’s documentation, for one, describes its support as a subset of the OpenAI API. A provider with a richer API of its own still needs its own adapter, or features such as citations and caching go unused.

The last part is choosing per task. Sorting a thousand tickets by part wants a small, fast model. A long answer that cites twenty maintenance logs wants a larger one. A question over personnel files may have to stay on your own servers. A model agnostic platform lets each assistant, agent or job name its model, with a default for the rest.

Models are retired. OpenAI’s deprecations page says: “As we launch safer and more capable models, we regularly retire older models.” It promises at least 6 months’ notice for a generally available model. Anthropic’s gives at least 60 days, and calls to a model past its retirement date fail. A tool built for one model has a shutdown date, whether or not anyone wrote it down.

Price and quality move. The model that was best for a task in the spring is often not the best or the cheapest one in the autumn. A setting lets you take the better offer without starting a project.

Some records must not leave. For personnel files or export controlled drawings, the model has to run where the records are. A platform that can only call a hosted model cannot serve those records at all. That side of the choice is about law as much as cost, and What is sovereign AI? covers it.

And you cannot compare what you cannot swap. Testing two models on your own questions needs both behind the same tools, reading the same records, under the same permissions.

Changing the setting takes a minute. Getting the same quality afterwards is not automatic, and three things account for most of the difference.

• Prompts tuned to one model. Instructions one model follows closely, the next may ignore or overdo. OpenAI’s prompt engineering guide warns that “Even different snapshots of models within the same family could produce different results.” It recommends pinning a version and keeping tests that measure how prompts behave.
• Tool calls. Providers describe tools, force a tool call and return its arguments in different ways. A compatibility layer hides some of that, not all. Anthropic’s guide to its OpenAI compatible endpoint says the option for strict tool schemas is ignored there. It adds: “Most unsupported fields are silently ignored rather than producing errors.” A tool that relied on strict arguments gets loose ones, and no error says why.
• Limits and features. Context windows, output limits, structured output and caching differ from model to model. A prompt that fit one context window can be cut short in the next.

None of this is a reason to stay on one model. It is a reason to test before you switch, on your own questions rather than a public benchmark.

Ask where the model sits in the architecture, then try it. Five questions cover most of it:

1. Which providers are built in, and can we point it at any OpenAI compatible endpoint, one on our own servers included?
2. Can each assistant, agent or scheduled job use a different model?
3. When the model changes, do the prompts, tools and permissions stay where they are?
4. Is every call logged with the model that answered and the tokens it used?
5. Are permissions applied before the model is called, whichever model it is?

Then run the test that matters. Write down questions your teams really ask, each with what a right answer must contain. Run them on the current model and on a candidate. Change the setting when the candidate passes, and keep the questions for the next change.

In Curiosity Studio the model is a setting of the provider. 19 providers are built in, among them OpenAI, Anthropic, Google, Mistral, Azure OpenAI, AWS Bedrock and Ollama for open weights on your own servers. Any OpenAI compatible endpoint works too, and a provider for any other API can be written in C# inside Studio. Spark serves open weights on your own GPUs behind an OpenAI compatible API.

Administrators switch on the models each provider may use, and a chat or an agent can run on a specific model instead of the default. Every provider call is logged with its token counts, as the LLM configuration documentation describes. The models page lists the current models by where each one runs.

The rest of Studio stays put when the model changes: the graph, the permissions and the tools your teams built. Access is checked per record before the model is called, so a new model sees no more than the old one did. Why that matters when you choose a platform is the subject of What is AI vendor lock-in?