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.
Tool drift is one of those problems that feels like it should not exist in a protocol with a handshake, and yet here we are. The two-gate approach you built makes sense. Pinning the definition hash and authorizing the call separately catches the cases where the description alone would be taken as instruction.
One thing worth considering: the drift problem gets harder when the server is itself an agent that can mutate its own tool list based on context. When the hash changes legitimately, the diff turns into noise. That shifts the problem from tool verification to identity verification, proving the entity presenting the tool list is the same one you approved across sessions. There is work on verifiable agent identity that pairs well with this kind of policy enforcement, and the combination feels like the right shape of the answer for the hard cases.