An emergency-management alert agent uses a small on-device model for rapid triage during a network outage and a larger cloud-hosted LLM for detailed after-action narrative summaries once connectivity returns. What principle explains why this design is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Think of it like keeping a battery-powered radio for the actual emergency and saving the detailed incident report for once the phone lines are back up. The small on-device model is that radio — it works when the network doesn't, for the fast triage that can't wait. The larger cloud model steps in afterward for the narrative work that benefits from more reasoning power, once it's actually reachable again.
Full Explanation
Model selection in an agent architecture can be driven by real-time availability rather than by capability alone: during a network outage, an on-device model that doesn't depend on connectivity is the only option that can perform triage at all, while a larger cloud-hosted LLM is reserved for detailed after-action work once connectivity is reliably available and its added reasoning capacity is actually useful.
Assuming the on-device model should permanently replace the cloud model overgeneralizes from a degraded-connectivity scenario to normal operating conditions, discarding the cloud model's advantages for the connectivity-dependent, quality-critical narrative task it was reserved for. Basing the choice purely on cost ignores the actual constraint driving the split in this scenario, which is availability during an outage, not price. Always attempting the cloud model first regardless of connectivity defeats the purpose of having a fallback in the first place, since the whole point of the on-device model is to keep triage working when the cloud path is unreachable.
Scope note: this pattern assumes the on-device model is genuinely capable of the narrower triage task; if triage itself needs more reasoning than the small model can provide, the split needs rethinking. Operational check: simulate a connectivity loss in a test environment and confirm the agent actually fails over to the on-device model rather than stalling while waiting for the cloud model.