# Running AI on intermittent links: a design guide

> How to run AI at sites with satellite, cellular or radio links that drop: local inference, store and forward, thin-link model updates and clock discipline.

- URL: https://www.sector88.co/blog/ai-on-intermittent-links-design-guide
- Author: Taskin Karlar
- Published: 2026-05-26
- Updated: 2026-05-26
- Category: Guides
- Tags: edge-ai, intermittent-connectivity, offline-ai, store-and-forward, inference

## Quick answer

To run AI on an intermittent link, make every decision path work with the link down. Run inference at the site, queue results and telemetry locally, send them when the link returns, ship model updates as signed, resumable packages, and keep the site clock disciplined so records still line up afterwards.

Most AI is designed by people who have never worked on a link that drops. A mine site on a microwave hop, a vessel on satellite, a substation on cellular backup, a field team on radio. The link is there most of the time. Then it is not, sometimes for minutes, sometimes for weeks.

If your AI system was designed for the data centre, that gap is where it fails. Requests time out, results are lost, an update half lands, and nobody can tell afterwards what the system did while it was cut off. This guide sets out the design rules that make AI on intermittent links boring, which is the goal.

## What counts as an intermittent link?

**An intermittent link is any connection whose availability, bandwidth or latency you cannot rely on at the moment you need it.** That includes links that are slow all the time (geostationary satellite), links that come and go on a schedule (low orbit passes, shift changes on shared radio) and links that fail without warning (weather, damage, congestion, deliberate interference).

The design question is not how good the link is on average. It is what the system does in the worst hour of the year.

## Rule 1. Every decision path works with the link down

Start by drawing the path from input to decision. Sensor or operator input, preprocessing, retrieval, inference, post-processing, action. Mark every step that touches the network. Each one is a place where the system stops working when the link drops.

For AI on intermittent links, the target is zero marks on that path. In practice that means:

- **Model weights live at the site.** Not cached on first use, but installed and verified before the system goes live.
- **The serving engine runs locally** and exposes the same API the application already calls, so the application does not need a second code path for offline mode.
- **Retrieval data is local.** If the model uses a document index, the index is replicated to the site and refreshed opportunistically.
- **Authentication works offline.** Operators can log in and the application can authorise requests against local credentials, with revocation lists that sync when they can.
- **Licence checks do not phone home.** A licence server on the other side of a satellite link is an off switch you did not mean to install.

The link becomes something the system uses when available, not something it waits on.

## Rule 2. Store first, forward later

Anything the site produces that someone elsewhere needs to see goes to durable local storage before it goes anywhere else. Results, alerts, telemetry, operator actions and logs all follow the same pattern.

1. Write the record locally with a sequence number and a timestamp.
2. Add it to an outbound queue on disk, not in memory.
3. Send when a link is available, in order, in batches sized to the link.
4. Delete from the queue only after the receiver acknowledges.
5. On reconnection, resume from the last acknowledged sequence number.

This is the core idea of delay tolerant networking, described in [RFC 4838](https://www.rfc-editor.org/rfc/rfc4838) and carried into the [Bundle Protocol](https://www.rfc-editor.org/rfc/rfc9171). You do not need to adopt the full protocol to use the idea. A durable queue, sequence numbers and acknowledgements get you most of the way.

Two details matter more than they look.

**Size the queue for the longest outage you are prepared to ride out.** Estimate records per hour, multiply by the outage you plan for, add a margin, and alarm well before the disk fills. Decide in advance what gets dropped first if it does fill: debug logs before results, results before the audit record.

**Prioritise the queue.** When a link comes back after a week, it may only be up for twenty minutes. Alerts and the audit record should go first, bulk telemetry last.

## Rule 3. Budget the link like a scarce resource

On a thin link, every byte competes. Write down a link budget the same way you would write a power budget.

| Traffic class | Direction | Priority | Typical handling |
|---|---|---|---|
| Alerts and safety events | Out | Highest | Send immediately when any link is up |
| Audit record and operator actions | Out | High | Send in order, never drop |
| Inference results for remote users | Out | Medium | Batch and compress |
| Model and configuration updates | In | Medium | Resumable chunks in link windows |
| Bulk telemetry and debug logs | Out | Low | Summarise at the site, send raw only on request |

Compress structured records before sending, and summarise at the site where you can. A thousand raw readings rarely need to cross the link when a summary and the anomalies will do. Leave the raw data at the site, retrievable on request.

## Rule 4. Ship updates as signed, resumable packages

Updating a model at a remote site is where most intermittent-link designs break. A multi-gigabyte download over a link that drops every few minutes needs a different approach from a data centre pull.

- **Package the model as an artefact with a manifest.** The manifest lists every file and its checksum, and the whole package is signed. Frameworks such as [The Update Framework](https://theupdateframework.io/) set out how to do this so a compromised mirror cannot push a bad update.
- **Transfer in chunks that can resume.** Verify each chunk as it lands. A dropped link costs one chunk, not the whole transfer.
- **Stage beside the running version.** Never overwrite the model that is serving.
- **Check locally before switching.** Load the new version, run a small evaluation set stored at the site, and switch only if it passes.
- **Keep the previous version on disk.** Rollback must not depend on the link.
- **Record the switch.** Which version, when, who approved it and what the local check showed.

The site should also be able to accept an update from physical media when there is no link at all, with the same signature checks.

## Rule 5. Keep the clock honest

When a site is cut off, its clock drifts. A few seconds a day does not sound like much until you try to line up a site record with events elsewhere after a month offline.

- Use a local time source where you can, such as a GNSS receiver at the site.
- When the link is up, discipline the clock with [NTP](https://www.rfc-editor.org/rfc/rfc5905) and record the offset you corrected.
- Give every record a monotonic sequence number as well as a timestamp, so order survives even when time does not.

[NIST guidance on log management](https://csrc.nist.gov/pubs/sp/800/92/final) makes the same point for security logs: records you cannot order are records you cannot trust.

## Rule 6. Size the model for the site, not the demo

At a remote site you cannot add a GPU on Tuesday. Choose the model that passes your own evaluation on the real workload and fits the memory at the site with room to spare.

Room to spare matters. Long inputs, bursts of requests and a second model running beside the first all need memory. If the model only just fits on a quiet day, it will fail on the busy one. Our guide to [fixing vLLM out of memory errors](/blog/how-to-fix-vllm-oom) covers the settings that set that headroom, and tiering memory across VRAM and system RAM is the usual answer when a model does not fit VRAM alone.

## Rule 7. Make the offline state visible

Operators at the site need to know the link is down and the system is still working. People elsewhere need to know what they are not seeing. Show both clearly.

- At the site: link state, queue depth, time since last sync, model version in use.
- Elsewhere: last contact time for each site, and a clear marker that data is stale.

A dashboard that shows a site as healthy because it has not reported anything is worse than no dashboard.

## A checklist before you deploy

1. Can the full decision path run with every network interface unplugged?
2. Does the outbound queue survive a power cycle?
3. How long an outage can the queue hold, and what is dropped first?
4. Can a model update resume after the link drops mid-transfer?
5. Is every update signed and checked at the site before it runs?
6. Can you roll back with no link at all?
7. Can an update arrive on physical media?
8. Does every record carry a sequence number and a disciplined timestamp?
9. Can site operators see the link state and the model version in use?
10. Have you tested a week-long outage, not just a five-minute one?

## Where Sector88 fits

Sector88 is one system to deploy, run and govern AI at every site, connected or completely cut off. It is built around the rules in this guide: inference at the site, behind an OpenAI-compatible API, with the link treated as optional.

The test for any AI system at a remote site is simple. Unplug the link and watch what happens. If the answer is nothing, you designed it right.

## Frequently asked questions

### Can AI inference run without an internet connection?

Yes. Once the model weights, the serving engine and any retrieval data are at the site, inference needs no network at all. The link is only needed to move results out, bring updates in and let people elsewhere see what happened. Design for that split from the start rather than adding an offline mode later.

### What is store and forward for AI systems?

Store and forward means the site writes every result, log entry and telemetry record to durable local storage first, then sends it when a link is available. Nothing is lost when the link drops, and the sender retries until the receiver confirms. It is the same idea behind delay tolerant networking and email relays.

### How do you update an AI model over a slow satellite link?

Package the model as a signed artefact with a manifest of checksums, transfer it in resumable chunks during link windows, verify every chunk and the signature at the site, stage it beside the running version, and switch only after local checks pass. Keep the previous version on disk so rollback needs no link.

### Why does clock synchronisation matter for offline AI?

When a site is cut off its clock drifts. If records carry drifting timestamps, events from the site cannot be lined up with events elsewhere after the link returns. Use a local time source such as GNSS where possible, record clock offset with each sync, and keep a monotonic sequence number on every record.

### Should an offline site use a smaller model?

Often, but not always. Choose the smallest model that passes your own evaluation on the real workload, quantised to fit the memory at the site. A model that fits comfortably leaves room for concurrency and long inputs, which matters more at a remote site than a slightly better score in a benchmark.

## Sources

- [RFC 4838: Delay-Tolerant Networking Architecture](https://www.rfc-editor.org/rfc/rfc4838), IETF
- [RFC 9171: Bundle Protocol Version 7](https://www.rfc-editor.org/rfc/rfc9171), IETF
- [RFC 5905: Network Time Protocol Version 4](https://www.rfc-editor.org/rfc/rfc5905), IETF
- [The Update Framework (TUF) specification](https://theupdateframework.io/), The Update Framework project
- [SP 800-92: Guide to Computer Security Log Management](https://csrc.nist.gov/pubs/sp/800/92/final), NIST