Fallback Is an Architectural Transition

The Architectural Observation

Model routing is becoming an operating capability within enterprise AI infrastructure.

A workflow can select among models according to task requirements. It can also transfer execution to an alternative model when availability or operating conditions change.

Databricks Unity Gateway provides a concrete example. Its Smart Routing capability supports model selection for delegated coding-agent tasks. The main agent session retains its configured model while eligible subagent tasks can receive independently selected models.

The capability is currently designated beta.

This architecture introduces a distinction between model selection and execution continuity.

Selecting an available model establishes a new execution path.

The enterprise must determine whether that path remains suitable for the work already underway.

Model Compatibility Is an Execution Property

Models can differ in the interfaces and capabilities they support.

OpenAI's Agents SDK documentation identifies compatibility differences between model interfaces and providers. Tool availability and structured-output support can vary across configurations.

These differences become material when a workflow depends on a particular execution contract.

Consider an agent that retrieves a customer record and prepares a contract amendment.

The initial model produces structured output consumed by a downstream application.

A fallback model supports the same general task but offers different output guarantees.

The downstream application still expects the original contract structure.

The fallback decision therefore requires more than a model endpoint.

It requires confirmation that the replacement configuration satisfies the workflow's execution requirements.

The Transition Changes Several Conditions

A model substitution can affect four operating properties.

Capability

The replacement must support the required task and tool interfaces.

Authority

The replacement environment must operate within the approved access conditions.

Evidence

The workflow must preserve the context and execution history needed for continued accountability.

Economics

The replacement changes the cost and potentially the latency of the remaining work.

These properties can vary independently.

A lower-cost model may satisfy the task requirements.

A more capable model may introduce additional latency.

A provider change may require renewed approval for the destination receiving enterprise information.

The appropriate route depends on the complete execution obligation.

A Practical Failure Condition

Consider an enterprise agent preparing an approved supplier payment.

The initial model produces a payment instruction with an authorized transaction identifier.

The model service becomes unavailable before the workflow receives a complete response.

A fallback model receives a summary of the previous interaction.

The summary describes the payment objective but omits the original transaction reference.

The replacement model can generate another payment instruction.

The workflow now faces a transaction-integrity problem.

The relevant question concerns the external payment state.

The execution system must retrieve the authoritative transaction record and establish the correct continuation.

The fallback model remains a participant in the workflow.

The transaction controls govern the financial effect.

This is an illustrative scenario. It demonstrates the architectural requirement and represents a proposed design response.

Fallback Qualification

An enterprise fallback policy should establish the conditions under which a replacement configuration becomes eligible.

The assessment should examine:

• ·Task capability and interface compatibility
• ·Approved provider and data-access conditions
• ·Preservation of execution identity and relevant state
• ·Current authorization for consequential actions
• ·Remaining resource allocation and acceptable latency
• ·Evaluation evidence for the replacement configuration

The qualification belongs to the execution system and its governing control environment.

A routing service can participate in this process.

Authorization and transaction integrity remain responsibilities of the systems enforcing those boundaries.

The Architectural Principle

Model routing creates flexibility.

Execution continuity gives that flexibility an operating discipline.

The enterprise gains the ability to change its inference configuration while preserving accountable execution.

A fallback is an architectural transition. Its eligibility depends on the obligations carried by the work.

Research Foundations

Databricks. Select Models or Use Smart Routing. Product documentation describing model selection and independently routed subagent tasks. Smart Routing is a beta capability.

https://docs.databricks.com/aws/en/ai-gateway/coding-agent-model-selection

OpenAI. Agents SDK: Models. Technical documentation describing model interfaces and provider compatibility considerations.

https://openai.github.io/openai-agents-python/models/

Connected Work

The Enterprise Agent Control Plane Flagship research publication.

Execution Continuity Framework Original framework examining obligations across execution transitions.