ModelOps: catalog and per-model fallback
Choose the models enabled for your company and configure an alternative for temporary provider failures.
Choose the models enabled for your company and configure an alternative for temporary provider failures.
How to use it
In Admin ModelOps, enable the required models and assign each fallback. Configure both provider connectors and validate the tools, images and structured outputs required by the agent. The fallback must also be enabled in the company catalog.
Limits and prerequisites
Temporary failures such as 429 and 5xx trigger one fallback attempt. Authorization, validation and tool errors do not trigger switching. Provider-bound resources such as VectorStoreId may prevent cross-provider switching. External voice platforms do not use this fallback.
Validate in your operation
Test the alternative in staging and inspect the actual model, attempts and cost. Switching does not change the agent's saved model. A company without its own configuration does not automatically receive the global catalog.
Planned agent model migration
Administrative migration changes a company agent’s provider and model while preserving prompts, owner, groups and other settings. Reading this inventory requires ViewTenantConfig; migrating requires UpdateTenantConfig. The administrative inventory differs from the agents visible to an ordinary user.
The target must be enabled in the company catalog, be a Normal model and have an enabled provider connector. Cross-provider migration is rejected when knowledge is linked through VectorStoreId. Plan knowledge adaptation before changing providers; do not remove the link merely to bypass validation.
The operation checks the source provider and model. If the agent changed since selection, it can return false without migrating: refresh the inventory and review the current configuration. After confirmed migration, validate tools, knowledge, quality and cost using representative cases. Saving the new configuration does not execute an AI test or guarantee behavior equivalent to the previous model.
Configuration checklist
- Confirm that the model is active globally and enabled in your company catalog.
- Register and enable its provider connector with company credentials.
- Choose an enabled fallback compatible with agent capabilities.
- Check images, tools, structured outputs and provider-bound knowledge resources.
- Test the normal path and a temporary failure in staging. Check the actual model, attempts and cost.
An empty company catalog does not inherit all global models: it leaves no available models. An empty fallback disables that model alternative rather than automatically inheriting the global fallback.
When switching happens
| Situation | Behavior |
|---|---|
| Temporary provider error: 429, 408, 504, other 5xx or transport. | One attempt using the configured alternative, when compatible. |
| Authentication, validation, tool error or cancellation. | Does not trigger fallback. Correct the underlying error. |
| Fallback also fails. | Execution ends; there is no unbounded model chain. |
| Knowledge using provider-specific files or indexes. | May prevent cross-provider switching. Migrate and validate the resource first. |
| Agent executed on an external voice platform. | Does not use internal conversational fallback. |
Validate the outcome, not just the absence of errors
The alternative may produce a different answer. Use the same evaluation cases as the main path and check tool continuity. Switching happens during execution and does not modify the agent’s saved model. Records identify the actual provider, fallbackUsed and modelAttempts; costs follow the model actually used.
ModelOps improves resilience to temporary failures but does not replace human handover for out-of-scope decisions or correction of credentials and permissions.
Availability
Feature identified in the platform code in October 2026. Availability depends on the deployed version, permissions and environment connectors. Contact Zild if it is not visible yet.
Documentation reviewed: 2026-10-28.