Discussion on "Build with AI, Run Without It: Designing Business Continuity Into AI-Assisted Operations"

Bonam Bobby · 2026-10-29T00:04:20.086Z

ABSTRACT Teams are quietly making AI a runtime dependency. It runs their jobs, triages incidents, fixes bugs and handles daily chores. It works well, until the service is down, the price changes, or t

I'd run your known-answer canary on the model path as well. The ambiguous remainder still goes to a model behind that thin interface, and one fixed input sent there each run would show a provider-side change before the real queue does. Do you run one there, or only on the compiled workflow?

Fair point to raise. In my setup the model only sees the ambiguous remainder, and what it sees depends on how critical the business data is. Its output goes to a person to approve instead of acting on its own, so the approver is the check and I don’t run a separate canary there. If a provider changes behavior, I update the prompt or interface on my side.

The test at the end is a good one to put in front of any team: if the AI service is down on run day, does the job still finish or fail safely? Many teams would honestly answer that they would wait.

Compiling the judgment is the idea I would repeat. When an agent solves a recurring problem, the output should be a script, tests from real cases, a runbook for someone new and a schedule owned by a team account. That turns a transcript into something the business owns.

Your point about drift is the most important caveat. A script that fails quietly is worse than an agent that varies visibly, so the fail closed layers, strict input contracts, invariants, history comparison and a known answer canary, are what make this approach safe rather than brittle.

On client work we scope recurring automation this way: AI helps build it, ordinary software runs it, and each approval gate is named in the scope with the person who owns it.

Thanks, and the way you scope client work is the version I’d want to copy. Naming each approval gate and its owner in the scope fixes a failure that process advice usually misses: a gate with no named person quietly turns into a rubber stamp.

One addition from my side. Naming an owner covers accountability, but not attention. For high-impact gates I’d also look at structure: a second approver, a cooling-off delay on irreversible actions, and the occasional seeded known-bad item to check the approver is really looking.

Curious how you handle it when a gate owner is out or leaves. Do you name a backup in the scope?

Good question, and the honest answer is that it depends on the job, and the design should say which.

When the timeout fires, that run has already stopped, so a late approval can’t resume it. For anything where the inputs age (market data, feeds, row counts), I’d have the late approval start a fresh run with fresh inputs. Approving evidence that is now stale is the riskier choice. For jobs with a snapshotted, versioned input, a resumable run with reminders and escalation before the timeout can make sense. The point is to decide it per workflow and write it down.

My broader idea is the same either way: use AI to build custom tools for repeated work, so the work still runs when the AI doesn’t. A good example is stock analysis. People reuse one prompt and swap the ticker. Build the analysis once as a tool, and each new ticker costs no model call. I did that with stockverdicts.com. Keep the model for the ambiguous parts.

The timeout in your approval example makes the stopping point clear. If someone approves after that timeout, do they start a new run with fresh inputs rather than resume the old one?

Search Hashnode

Build with AI, Run Without It: Designing Business Continuity Into AI-Assisted Operations

Responses6