How do you preserve user work when an AI operation fails midway?

Inkbridge drafts multi-section grant applications for Cascade Relief Collective, a small housing nonprofit. Here is the night a job failed midway on Noemi Castellanos, and the design that would have cost her ninety seconds instead of a redone night.

How to answer this, stage by stage

Nobody is grading whether you'd add a "save" button. They're grading whether you can name the exact unit of work that should never be thrown away.

Let's learn

Inkbridge is an AI tool that drafts a six-section grant application, need statement, goals, methodology, budget narrative, evaluation plan, and org background, for a small nonprofit's program officer.

Before Inkbridge, Noemi wrote a full application by hand, section by section, over several evenings, roughly six hours total for a mid-sized foundation grant.

Now Inkbridge drafts all six sections in about eighteen minutes, when the job completes successfully end to end.

The whole method, in five rows. The hard one is the third.

Here's the turn: the extra speed was never the problem. The real cost showed up the first time a job failed partway, because the product only ever delivered anything at all once every section finished, so one stalled step could erase three completed ones.

At its worst, a program officer loses an entire evening's work the night before a deadline, redoing three sections that were already correct, because the fourth one alone happened to stall.

What I would leave alone: short, single-section tasks, like rewriting one paragraph, don't need this treatment. A quick retry costs seconds, so per-step saving there is effort spent on a problem that barely exists.

The lesson: the unit of work you design around is a promise. Promise the whole job or nothing, and the whole job becomes the only thing that's ever safe.

Now here is the same thing as a story

The short version above is what you'd say defending this fix to Cascade Relief's board. Read this one for how the habit actually formed.

Noemi Castellanos has been a program officer at Cascade Relief Collective, a small housing nonprofit, for four years, and she can weave board-approved language into a grant narrative without ever making it read like a form letter.

Inkbridge arrived and the first months were good. She'd start a draft after dinner, and by the time she'd made tea it had produced all six sections, clean enough that she only needed to tighten a sentence here and there.

In her first month, she kept a personal backup, pasting each section into a notes app as it appeared, the same habit she'd used writing by hand. By month two she'd stopped, since Inkbridge had finished cleanly every single time. By month three she didn't even watch the screen while it ran, she'd start it and go make tea, trusting it completely.

Her own backup habit didn't fade evenly. It ran flat at zero for two months, then jumped straight back to full the night she lost work.

The night before a foundation deadline, Noemi started a draft after her kids were asleep. Sections one through three appeared cleanly, methodology at 10:41pm looking especially strong. At section four, the budget narrative, the job stalled and the screen returned only: "Something went wrong. Please try again."

She tried again. The whole job restarted from section one, twenty-five minutes, and produced a methodology section noticeably weaker than the one she'd already read and liked. There was no way to get the first version back.

This is the private process Noemi builds for herself, starting the very next time she opens Inkbridge.

It wasn't really about the twenty-five minutes. It was that Inkbridge had never actually protected any of her three good sections, it only looked like it had, because nothing had failed yet.

Noemi never had a dial she could trust a little more or a little less. She only ever had a switch: copy everything herself, or copy nothing.

Starting the next week, Noemi pastes every section into her own scratch document the instant it appears, before letting Inkbridge move to the next one, adding several minutes of manual copying to every single draft, successful or not, because she no longer trusts the tool to hold anything until the very end.

Two months of quiet trust, then one stalled section undid all of it in a single night.

With the redesigned Inkbridge, each section saves the instant it's generated, visible to Noemi as it happens. The same stall at section four now shows: "Sections 1 to 3 saved. Section 4 stalled, resume?" She taps resume. Run the same night forward: she's done by 10:47pm, six minutes after the stall, methodology section intact exactly as she first read it.

Everything Noemi's resume screen needs. The old design showed none of it, because none of it was ever saved.

The old design asked Noemi to trust the whole job or lose everything. The new one just tells her exactly where it stopped.

I built the draft to deliver all at once because that's how every test run behaved, clean, complete, no reason to think about partial states. It took one nonprofit program officer's ruined evening, redoing a section she'd already liked better, to see that "it always finishes" and "it's safe to never check" were never the same promise.

The five steps, if you want to remember it

The recap, one line per letter: find the person is Noemi and her old backup habit, locate the habit is the manual copying she quietly stopped doing, identify the flip is a workaround built the instant the tool's lack of memory was revealed, pinpoint the old decision is an all-or-nothing job nobody revisited, and show the replay is a six-minute resume instead of a redone night.

The bigger the batch, the less anyone can afford to trust it blindly, which is exactly backwards from how trust usually builds.

And if you want to be sure it really works, try it somewhere elseA different flip family, a veterinary clinic instead of a nonprofit. This time it's scope, not workaround.

Thornmeadow Veterinary Clinic uses VetSummary, an AI tool that summarizes a full day's patient charts into handoff notes for the overnight technician. Warrick Osei, a vet at Thornmeadow, ran it on a full day's twenty-two charts at once. This story runs on a different family: the scope flip, not workaround.

After VetSummary once lost an entire day's batch to a single malformed chart partway through, with no partial output at all, Warrick stopped running it on a full day and started feeding it four or five charts at a time instead, small enough that he could hold the whole batch in his head and re-run it quickly if something broke. The old decision behind it: VetSummary was built to process a full day's charts as one batch job, because early testing used small sample sets where nothing that large had ever failed partway.

Same shape of story, a clinic instead of a nonprofit, and a batch of charts instead of a grant draft.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "save each finished unit the instant it exists, show exactly where it stopped, and let the person resume from there, never restart the whole thing," and stop.
Cost: there's no time to rebuild every job as fully resumable this sprint. Say so honestly, and start with the longest-running, highest-stakes job first, since that's where a full restart costs the most.
The model gets better, for real: if Inkbridge's completion rate genuinely climbs to near perfect, that's still not a reason to remove per-section saving, the one night it fails is exactly as costly as it ever was, however rare that night becomes.

Where people run it wrong.
They add a retry button and call the problem solved, without ever saving what already succeeded.
They show "something went wrong" with no detail on which part actually failed.
They assume a person will complain about lost work, when most people just quietly build their own backup habit instead, the way Noemi did.

How to use it live. When someone asks how you'd preserve work through a mid-operation failure, ask yourself one question before describing a single screen: what is the smallest unit of finished work that should never have to be redone? Design the save point around that answer, not around when the whole job happens to finish.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0