The unfinished job is the outage

Infrastructure teams describe outages in minutes. Customers experience them as unfinished obligations. The invoice was not reconciled. The order was accepted but never released. The agent drafted a reply and nobody knows whether it was sent. The refund may have happened, so retrying may pay twice. A business can show green servers while still owing a growing pile of uncertain work.

That is why continuity should be designed around the job rather than the process. For every revenue-bearing or trust-bearing loop, the system should be able to answer five questions after a failure: what was admitted, what was attempted, what changed outside the system, what remains uncertain, and who owns the next decision.

The cloud can fail. A local machine can fail. A model can return nonsense while every monitor says healthy. The operating standard is the same: each obligation is completed and verified, held without pretending, expired by policy, or handed to a named person with the evidence attached.

Name the minimum viable company

The minimum viable company is the smallest operating state that preserves promises during a dependency failure. It is not a miniature copy of the normal company. It is a deliberately reduced mode containing the operator control surface, durable job ledger, current policies, essential customer context, an intake path, an exception channel, and enough identity and communications capability to decide what happens next.

Most work can stop. Bulk research, content production, training, enrichment, optional vision, speculative experiments, and high-concurrency agents are not continuity requirements. A system becomes easier to protect when the operator is willing to say which work may wait.

The critical set should be written by obligation class. Preserve new-order intake without promising fulfillment. Preserve support intake without inventing resolution. Preserve the cash and reconciliation ledger even when payment rails are unreachable. Preserve security alerts and facility monitoring. Preserve the ability to tell a customer that work is held and why.

Map failure domains by obligation

A company with three model providers and one identity provider has one identity provider. Three APIs reached through one dead internet circuit are one unavailable path. Two agents reading one corrupted knowledge store share the same bad memory. Redundancy is not a list of vendors. It is the number of independent failures a job can absorb without becoming invisible or unsafe.

Draw the path for each critical obligation from intake to verified result. Include model access, orchestration, queue, database, retrieval index, credentials, DNS, network, human approval, target system, and customer delivery. Mark every shared dependency. The diagram usually reveals that the most important single point of failure is not the model. It is the ledger, identity layer, integration account, or person who knows what the workflow was supposed to do.

Then classify dependencies by consequence. Some failures reduce quality. Some pause a tool call. Some destroy evidence. Some remove operator access. Continuity investment should follow the consequence to the job, not the prestige of the component.

Write degraded modes before buying redundancy

A second provider or local model is useful only when the business already knows how to operate with fewer capabilities. Define normal mode, continuity mode, and survival mode before choosing hardware. Each mode should state which jobs may enter, which tools remain available, what spend and risk are permitted, what customer promise changes, and which event forces escalation.

In continuity mode, the company may keep classifying, retrieving, drafting, reconciling local records, assembling approval packets, and preserving intake while external writes are held. In survival mode, it may preserve only the ledger, security signals, communications, and the path to restore service. Graceful degradation is not a technical euphemism for poor performance. It is the deliberate refusal to turn missing evidence into false completion.

Make the transition deterministic. A health check, queue age, provider status, network path, or power state can move the system between tiers. Do not give the language model open-ended authority to decide whether the company is healthy enough to keep spending money or changing customer state.

Local AI is a continuity worker, not the company

Small local systems make a useful continuity layer because they can preserve classification, retrieval, drafting, monitoring, and limited agent work when cloud inference or the public internet is unavailable. NVIDIA's DGX Spark is one current example: it combines 128 GB of unified memory with a complete-system power envelope small enough to protect with ordinary battery and generator equipment.

The engineering details belong to Off Grid Labs, where the practical question is how to power and duplicate the nodes. The operating lesson here is narrower: local inference is one actor inside the minimum viable company. It does not replace the job ledger, current policy, credentials, network, target systems, or the person who owns an exception.

A spare brain is not a spare company. The local model should receive a bounded continuity role, a current copy of the context it needs, explicit tool restrictions, and a queue whose work can later reconcile with the normal system.

Keep state outside the model

The model's transcript is not the business record. Persist each job independently with a business identifier, customer or case, workflow and code version, current checkpoint, approval state, attempt count, deadline, external operation key, receipts, verification result, and owner. The worker may disappear. The obligation may not.

External writes need more than completed and failed. A useful state model includes not started, running, waiting for approval, external result unknown, committed, verified, failed, and expired. The dangerous moment is the lost acknowledgement after an email, payment, cancellation, purchase, or record change may already have happened. Retrying without reconciliation converts continuity into duplicate action.

OpenAI's current human-in-the-loop guidance makes paused agent state serializable, while Stripe's error guidance treats ambiguous network outcomes as indeterminate and relies on stable idempotency keys plus later reconciliation. The business pattern is consistent: preserve the record, bind approvals to exact actions, and make the word unknown visible enough that somebody can own it.

Run the supplier-loss drill

Test the company by removing suppliers, not by admiring the architecture diagram. Disable the primary model provider. Break the internet path. Remove the identity service. Make the CRM unavailable. Stop one worker during an external write. Restore service after the workflow version has changed. Ask the local fallback to operate without a cloud retrieval store. Refuse the first recovery attempt.

The drill passes when every admitted job remains visible, the system enters the correct degraded mode, no high-risk action escapes its authority, and every held obligation is later completed, reconciled, expired, or assigned. Measure time to degraded readiness, oldest queue item, unknown external outcomes, duplicate suppression, review minutes, recovery success, and the number of jobs that needed oral reconstruction from the founder.

A dashboard showing that two models answered a test prompt proves very little. The useful artifact is the obligation ledger after the drill.

Continuity is part of transferability

An autonomous business is more valuable when another operator can see what survives failure. Buyers should ask for the dependency map, minimum viable operating modes, last supplier-loss drill, recovery metrics, credential rotation procedure, backup restore evidence, and the recent history of interrupted or indeterminate jobs.

This also improves the business before a sale. Continuity work exposes founder-only knowledge, hidden shared accounts, vague acceptance tests, irreversible tool calls, and queues that exist only in somebody's inbox. Those are operating defects even when no outage occurs.

The company becomes transferable when its promises can survive the absence of a provider, a process, or the founder's memory.

The cloud should supply capability. It should not be the only place the company knows what it owes.

Design continuity around the obligation: preserve the record, reduce the mode, constrain the action, and give every uncertainty an owner.

sources
  1. Restart recoveryOpenClaw, accessed July 26, 2026
  2. Human-in-the-loopOpenAI Agents SDK, accessed July 26, 2026
  3. Advanced error handlingStripe, accessed July 26, 2026
  4. Hardware OverviewNVIDIA DGX Spark User Guide, accessed July 26, 2026
  5. Advanced Tab: Power On BehaviorNVIDIA DGX Spark UEFI User Guide, accessed July 26, 2026
  6. A Battery Is Not RedundancyOff Grid Labs, accessed July 26, 2026