The questionWhich model do you use, and what happens when it changes?
AiDN is fully model-agnostic. The agent layer, tool framework, skills system and data connectivity are all decoupled from the underlying language model, so when the model changes — a better frontier release, or a regulatory requirement for a self-hosted alternative — nothing in the operational stack changes with it.
What we can evidence
Change the model without changing anything else.
Agents, tools, skills and the data layer remain unchanged when the model changes. Studio assigns a model per assistant from a governed registry, so a swap is a configuration decision rather than a re-implementation.
Run frontier and self-hosted models side by side, per assistant.
The registry carries frontier tiers — fast, balanced, intelligent and reasoning — alongside self-hosted open models from the Gemma and Nemotron families, deployable entirely inside the operator's perimeter. One assistant can use a frontier tier for multi-step reasoning while another runs a local model for volume classification.
Why coupling to one model is the expensive mistake
The most consequential architectural decision in any AI platform is how tightly it couples its capabilities to a specific model provider. Platforms that build their tooling, prompting and data access around one vendor's model inherit that vendor's roadmap, pricing and jurisdiction. When the landscape shifts, and over the last three years it has shifted roughly every six months — the cost of moving is a rebuild rather than a setting.
The governed registry
Model assignment is managed through a governed registry inside Studio. Each assistant is allocated a model at configuration time, and an administrator can see and change every assignment in one place rather than hunting through code.
| Tier | Where it fits |
|---|---|
| Fast | High-volume, low-complexity work — classification, extraction, routing |
| Balanced | The default working tier for most operational questions |
| Intelligent | Cross-domain synthesis and report generation |
| Reasoning | Complex multi-step investigation and root-cause analysis |
| Self-hosted (Gemma, Nemotron families) | Volume workloads and any case where policy prohibits an external API call |
The trade-off, stated plainly
Frontier models are genuinely better at complex, multi-step reasoning. Local models are the right choice for high-volume classification, routine summarisation, and any workload where data sovereignty requirements prohibit external API calls. We will not tell you a local model matches a frontier model on hard reasoning, and we will not tell you that you need a frontier model to classify alarms. The commitment is to show you the difference on your own data before you commit to any configuration.
Telecom-specialised models on the roadmap
The GSMA OTel family — telecom-tuned language models, embedding models and rerankers released under the Apache 2.0 licence — is on the roadmap. These bring domain-specific language understanding without compromising openness: a model that already knows what an eNodeB, a PRACH configuration index and a VoLTE anchor are does not have to be taught from the prompt every time.
Roadmap item, presented as direction rather than as available capability.