This is an important distinction. A fallback shouldn't just be “model B instead of model A” the application should know what guarantees model B can actually provide.

I’ve seen this become especially important in production AI systems: tool calling, structured output, latency, and even context handling can change enough that blindly keeping the same workflow creates more failure modes. A capability matrix per model route, tied to explicit product modes, makes the fallback behavior much more predictable.

This is also the kind of thinking we apply at IT Path Solutions when productionizing AI workflows: design the degradation path before the primary model actually goes down. A graceful reduction in capability is far better than pretending the fallback is equivalent.