Every AI employee on Wetel runs on the platform’s default model unless someone deliberately picks a different one, for the whole AI employee or for a single step in its workflow. If a call to the default provider fails, the platform automatically tries a second provider instead of failing the call.
Think of a company car pool. Most trips use the standard pool car. A manager can book a different car for one person or one trip, the fleet office can rule some cars out for your department, and if the pool car breaks down, a spare is sent without you having to call anyone.
How is the model chosen?
The most specific choice wins. The docs give this order for a workflow step:
- The step’s own model choice (
modelOverrideon anllmstep) - The AI employee’s model choice (
llmModelOverride) - Your workspace’s model choice
- The provider’s own default model
By default none of these is set, so an AI employee runs on the default. Choosing a model for a whole AI employee or a whole workspace is a pilot today: ask your Wetel contact to enable it for your account.
Can one step use a different model?
Yes. A single llm step in a workflow can name its own model, for example a cheaper one for sorting messages into categories, while every other step stays on the AI employee’s model.
Here the two levels behave differently on purpose. If the AI employee’s own model is unavailable, it degrades gracefully to the provider’s default. If a step names a model that is not in the model catalog, the step fails, and with it the whole run, with an error that says why. The docs explain the reason: otherwise the step would quietly be answered by a model you did not pick. Check the model name before you publish.
Who can restrict which models we use?
A Wetel administrator, on your request. You cannot change the list yourself, but you can read it: myTenant { allowedLlmModels } returns null when there is no restriction (the default) or the list of allowed models.
- Per workspace: the model catalog your team sees then lists only the allowed models, so a model picker never offers a blocked one.
- Per API key: an administrator can also restrict a single key, for example a key your developers use. A key can only narrow the workspace’s list, never widen it. Conversations started with that key keep the restriction for every later turn. You cannot read a key’s list yourself yet; ask your Wetel contact.
What happens when a blocked model is requested?
You get a clear refusal that names the model, not a quiet swap to another one. Saving an AI employee or publishing a workflow that would use a blocked model is rejected. A step that asks for one fails, and the run record shows the message. AI employees and workflows that already used a model before it was blocked are not rewritten; they fail when they run until someone changes them. One nuance from the docs: the default provider can still answer through its own built-in fallback, unless that fallback model is itself excluded.
What do I see when a provider fails?
It depends where you look. When your systems call a model directly through the API, the response tells you which provider and model actually served the call, which can differ from the one you asked for after a fallback. In a conversation, the docs do not describe any message telling the person talking to the AI employee which provider answered. Requests that fail for other reasons come back as errors with a code your systems can act on.
What we do not claim
We do not publish speed or answer-quality figures for any model, and a fallback model may answer differently from the default. If a model choice matters to your work, test it on your own conversations first. Your workspace owner stays in charge of what each AI employee may do; the model is only one part of that.
Related reference docs
- Agents: LLM provider override: the resolution order and the pilot settings for an AI employee or workspace
- Agents: restricting which models a tenant can use: reading the list and what a blocked request looks like
- Agents: restricting one API key: how a key narrows the workspace list
- LLM step:
modelOverride: naming a model for one step, and why an unknown model fails the run - LLM API: choosing a model: the model catalog and which model served a call
- Error handling: error codes and how to retry
If you are deciding which work an AI employee should take on, tell us which work you’d hand over first and we will tell you plainly what is live today.