Bring your own LLM
The model layer changes faster than anything else in this stack. Building an agent around one specific model is a decision you will have to unmake.
Two years ago the strongest model for customer conversation was not the one that is strongest now, and that will be true again. A platform that hard-codes a single model forces a migration every time the landscape shifts, and migrations are where prompt behaviour, guardrails and evaluation quietly break.
The model is configuration, not architecture
In Dialog365 the reasoning model sits behind an interface. What surrounds it — retrieval, grounding rules, tool calls, routing, escalation, transcription and synthesis — does not change when the model does.
Commercial APIs and self-hosted open-weight models are both supported Deployment in your own cloud or region where residency requires it Different models for different contact types within one deployment Changing model does not change prompts, tools, guardrails or routing
Different contacts justify different models
Treating every contact as needing the same model is expensive. A large fraction of contact centre traffic is classification and lookup — identifying intent, reading a record, confirming a fact — and a smaller, cheaper, faster model handles that well. Reserve the strongest model for the conversations where nuance genuinely changes the outcome.
| Contact type | What it needs | Practical choice |
|---|---|---|
| Intent classification | Speed, consistency | Small fast model |
| Lookup and confirmation | Accuracy on tool calls | Small to mid model |
| Complex explanation | Reasoning and nuance | Frontier model |
| Sensitive or regulated | Control and residency | Self-hosted open weights |
What does not change with the model
Reliability comes mostly from what surrounds the model, not the model itself. Grounding to your content, restricting scope, defining tool calls and routing on low confidence are all model-independent, which is why a well-built agent survives a model change without a rewrite. That is covered in the piece on grounded answers.
Residency and self-hosting
For regulated deployments the constraint is often not capability but where inference happens. Open-weight models running in your own environment satisfy residency requirements that no commercial API can, at some cost in raw capability — a trade worth making when the alternative is not deploying at all.
Frequently asked questions
Which LLM does Dialog365 use?
Whichever you choose. Commercial APIs and self-hosted open-weight models are both supported, and different models can serve different contact types in one deployment.
Can we run the model in our own cloud?
Yes. Self-hosted open-weight deployment is supported where data residency or regulation requires inference to stay in your environment.
Does changing model mean rebuilding the agent?
No. Retrieval, grounding, tool calls, routing and escalation sit outside the model, so they carry across a model change unchanged.
Is a frontier model needed for every conversation?
No, and using one everywhere is expensive. Classification and lookup are handled well by smaller, faster models; the strongest model is best reserved for genuinely complex conversations.
See it on your own calls
Tell us how your contact centre runs today and we will map it to your setup.
Related
How Dialog365 stops the AI inventing answers
Grounding, closed-domain retrieval and refusal behaviour.
One platform for AI agents and human agents
Why integrating two vendors costs more than it saves.
Choosing STT and TTS engines
Deepgram, ElevenLabs, Cartesia, Sarvam and Azure.
Why latency decides whether people talk to your voice agent
Sub-second turn-taking and what breaks below it.