Man and Machine: The Fallback Test

This morning’s Man and Machine post failed before breakfast, and the interesting part is not that the system broke. The interesting part is where it broke.

The job had a clear assignment. It needed to look across recent sessions, inspect local artifacts, generate an image, write the package, and hand the manifest to the LinkedIn publisher. When the primary model hit a usage limit, the fallback path did what it was designed to do and reached for another model. On paper, that sounds like resilience. In practice, the fallback model could not use tools, which meant it could not do the work the job actually required.

That is the lesson I keep coming back to as I build with agents. These systems are not just collections of clever models. They are operating environments made up of capability, context, permissions, recovery paths, verification, and human judgment. If any one of those pieces is missing, the workflow does not degrade gracefully. It simply looks busy until the gap becomes impossible to ignore.

The fix is not glamorous, but it matters: route work by capability, not just availability. If a task needs tools, the fallback must support tools. If a workflow touches public publishing, it needs proof rather than vibes. A cheaper fallback that cannot perform the task is not resilience. It is theatre with a progress bar.

The future belongs less to people who merely “use AI” and more to operators who learn where the machine actually breaks, then design the system so the next break teaches them something useful.

Where are you still treating fallback as the same thing as resilience?

-dg

#ManAndMachine #AILeadership #AgenticAI #Operations #HumanInTheLoop