Describe the difference between a retry that helps and a retry that just costs money.

Fenwick Mutual runs an AI damage-assessment tool that scores photos of storm damage for auto and home claims. Teodor Vance is a field inspector who stands in customers' driveways all day, tablet in hand, submitting photos the tool either scores or kicks back.

How to answer this, stage by stage

Nobody is grading whether you know what a retry is. They're grading whether you can tell, for one specific failure, if trying again could possibly change anything.

Let's learn

What actually happens the second time an AI model is shown the exact same photo it just failed to score?

Fenwick Mutual's tool scores a photo of storm or accident damage in seconds, instead of a claim sitting in a queue for a human adjuster to review by hand. Before it, every claim waited two to four days for a person to look at the photos.

The old system skipped straight from the first box to a blind third attempt, missing the check that actually matters.

Now most photos score instantly. On a failure, the tool automatically resubmits the identical photo up to three times before giving up and routing it to a human anyway.

Here's the turn: the extra attempts were never actually fixing anything for a whole class of failures. A photo that fails because of glare or a genuinely ambiguous damage pattern will fail the exact same way every single time, since nothing about the photo changed between attempt one and attempt three.

At its worst, Fenwick pays for thousands of pointless resubmissions a month while claimants wait through a delay that bought nothing.

One of these looks like the slower option. It is not the expensive one.

What I would leave alone: network timeouts and dropped connections should still auto-retry without asking a human anything. That failure really is transient, and the same photo really can succeed the second time.

The lesson: a retry only ever buys you something new to look at. If nothing changed, you didn't retry, you just paid twice for the same wrong answer.

Now here is the same thing as a story

The short version above is what you'd say defending this fix to Fenwick's claims-technology council. Read this one for how the waste actually got found.

Teodor Vance has inspected storm damage for Fenwick Mutual for four years, standing in driveways with a cracked tablet, snapping roof and siding photos while a homeowner watches from the porch. He can usually tell hail damage from wear damage before the tool even finishes scoring.

For months, Teodor noticed his queue never actually moved faster on cloudy, glare-heavy days, even though the tool was supposedly "smart" about retrying. He assumed it was just a harder day for photos. He never timed it, so he never noticed the nine extra seconds per failed shot, three times over, quietly stacking up behind every glare-blown roof.

Nine seconds spent proving something that was true from the very first attempt.

A finance-side audit, run to understand why inference spend had crept up faster than claim volume, pulled a sample of logs and found it: nearly a third of all model calls were identical resubmissions of photos that had already failed once, for reasons that had nothing to do with a bad connection.

The audit traced it to one merged step: the system checked "did this fail," not "why did this fail," and treated every failure as worth an automatic second and third try.

Three failure types cluster in the same corner. Only one belongs anywhere near "retrying helps."

With the redesigned check, a failed photo is first classified: glare or ambiguous damage routes straight to a human reviewer with no further model calls, blur triggers an on-screen prompt asking Teodor to retake the shot, and only a genuine network timeout auto-retries. Run the same driveway forward: the glare-heavy roof photo goes straight to a human on the first failure, at a third of the cost and none of the wasted seconds.

The old system asked the model the same question three times and called that effort. The new one asks once, then asks the right next question.

I built the retry logic to fail safe, when in doubt, try again. It took an inference-spend audit to see that "try again" and "actually try something different" were never the same move.

PICK, in one screenNot a debate about whether retries are good. PICK is what tells you which one is a real second chance.

Four conditions. If none of them are true, the retry was never going to help.

The recap, one line per letter: position is that only new information makes a retry real, impact is a tap versus a silent inference bill, cost asymmetry is the blind retry being the expensive one despite looking automatic and free, and kill criteria is watching for any failure category where resubmission genuinely does help.

Four questions, asked once per failure, instead of one blind loop repeated three times.

And if you want to be sure it really works, try it somewhere elseSame four letters, a farm's crop-disease scanner instead of a storm-damage photo. Same wasted loop, a different field entirely.

Thornbank Agritech makes a phone app that scans a photo of a crop leaf and flags disease risk. Anouk Ferreira runs a mid-sized vineyard and scans suspicious leaves most mornings before the day heats up. Her app, like Fenwick's, used to auto-retry any failed scan up to three times against the same photo.

Mapped onto PICK: position is that a blurry or backlit leaf photo will fail identically no matter how many times it's resent, so the fix is a recapture prompt, not a resend; impact is Anouk losing a few seconds to retake a shot versus Thornbank quietly paying for three scans of a photo that could never pass; cost asymmetry is the same one, the automatic-feeling option is the expensive one, not the one that asks the farmer to do something.

Same shape as Fenwick's driveway, a vineyard instead of a windshield.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "a retry only helps if new information enters between attempts, otherwise you're paying twice for the same answer," and stop.
Cost: there's no time to rebuild the retry logic this sprint. Say so honestly, and start by turning off blind retries for the failure categories already proven not to improve on resubmission, that alone stops most of the waste.
The model gets better, for real: if the underlying model's accuracy improves and fewer photos fail at all, that's still not a reason to bring back blind retries on the ones that still do fail, since an improving model doesn't change whether the same input produces the same answer.

Where people run it wrong.
They treat "add a retry" as a free safety net, without ever checking whether the failure could possibly resolve differently.
They measure retry success by whether the claim eventually gets handled, not by whether the retry itself changed anything.
They let a genuinely helpful case, like network drops, justify auto-retrying everything else by association.

How to use it live. When someone asks you this question, ask yourself one thing first: between this attempt and the next one, does anything actually change? If the honest answer is no, it isn't a retry, it's a repeat.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0