← Back to Concept Contrast

Concept Contrast Fable

Swapping in a backup when the model fails vs. still making do when the system fails

Conclusion first:Model fallback only swaps out the model that has the problem, while degradation requires the entire system to still provide limited but usable service after some functions fail. When designing a high-availability agent, switching to a backup model can only solve engine failures, while degradation can solve a break in any link of the dependency chain.

Model fallback only swaps out the model that has the problem, while degradation requires the entire system to still provide limited but usable service after some functions fail. When designing a high-availability agent, switching to a backup model can only solve engine failures, while degradation can solve a break in any link of the dependency chain.

Fable

Changing sails and beaching a damaged ship

The mountain road postal station originally ran on a set of familiar methods. When the main road was clear, the station master sent fast horses to deliver entire bags of letters, and following the old rhythm rarely caused problems.

Later things grew bigger. After the main road collapsed, letters still had to be delivered, and the urging voices lined up from early morning to evening. The newcomers thought this was a volume problem, solvable by sending more people and adding more hours; the veterans saw that many details had already crossed the boundary that the old methods could bear.

The steward tried the first approach: temporarily finding another fastest horse. In the first few days there was indeed improvement, the queue got shorter, and outsiders felt this craft had finally caught up with the new situation.

But trouble quickly changed shape. Some people skipped inspections to rush progress, some forced unsuitable work into old processes, and the most skilled people were dragged down by trivial matters. Errors were not always visible on the surface and often only emerged after delivery. The old ledger could still explain where things came from, but it could not explain how to change for the next step.

The person in charge added more rules, requiring everyone to sign more, report more, and add another layer of protection. On paper it looked thorough, but on site it was slower; the craftsmen were busy proving they were not wrong, while the real cracks continued to widen in place. Onlookers only saw results fluctuating between good and bad, and people on site found it increasingly difficult to judge whether to save speed, quality, or responsibility first. Everyone felt they had done a little more, yet the whole thing did not become more stable because of it.

A silent old craftsman laid several failures on the table. He blamed no one, only had everyone look at the same detail: the new restriction had never entered daily practice, and only suddenly appeared before delivery. He laid the several reworks out in the order they occurred, and only then did everyone discover that mistakes were always amplified at the same corner.

So the workshop adopted new rules: if even the fast horse has no path, switch to sending summaries, delay heavy items, and prioritize urgent letters. At first everyone was uncomfortable, feeling tied up; but after several rounds, rough shortcuts were blocked, and truly reliable actions gradually remained.

The next time the same pressure came, delivery didn't become fancier, but it was noticeably more reliable. The post station master finally understood: switching to an equivalent route is one thing, degrading to protect the core is another. If you wait until the end to remediate, the cost is often already baked into every earlier choice; this new route didn't eliminate cost, but it made cost surface early, so it could be handled while change was still possible.

Model fallback

Automatically switching to a backup model or returning a preset result when the primary model is unavailable, times out or fails to meet quality standards is an availability strategy at the model layer.

Degradation

When some system functions or dependencies fail, the whole still provides limited service by reducing capability, cutting features, or simplifying paths.

Story Mapping

  • Swap the spare sail: model fallback, replacing the failed component at the model layer
  • Hull taking on water, pumps at half capacity, navigation intermittent: a complex failure with multiple systems damaged simultaneously
  • Whole-ship degradation plan: reallocation of resources, functions and paths in a degradation strategy
  • Degradation table: preset trigger conditions and degraded behavior for each dependency failure
  • First determine whether the sail is broken or the boat is broken: locate the failure level before choosing a strategy

Down to Agent high-availability architecture

High availability for an agent system cannot rely only on model fallback. You must plan degradation behavior for retrieval, tools, approvals, storage, messaging channels, and other layers at the same time. For example, if retrieval goes down, should you force an answer from conversation history? If a tool times out, should you skip it and tell the user? If approval times out, should you use an emergency channel?

京ICP备2026014272号