Building for "Zero Bars": Local-First AI and CRDTs on Flaky Networks

Modern AI applications share an invisible assumption: the network is always there. Every chat turn pings a cloud endpoint, waits for a model response, and renders the result. When the round-trip completes in 200 milliseconds on WiFi, the illusion holds. When a field sales agent in rural Odisha drops to a single bar of 3G — or no bars at all — the illusion shatters into a blank screen and a stuck spinner.

This is the cloud-tethered trap, and it is a structural flaw. The architecture bakes in persistent connectivity, and when that assumption breaks, the application breaks with it. For users in high-growth markets across Southeast Asia, India, and Africa, intermittent connectivity is not an edge case. It is Tuesday.

The Cloud-Tethered Trap

Consider a typical AI chat application. User sends a message. Client serializes, ships to an API gateway, routes to an inference endpoint, streams tokens back, renders. Every step requires a live TCP connection. Drop the connection at any point, and the entire interaction is lost.

The problem compounds with agentic workflows. An AI agent chaining five tool calls across a flaky 3G connection in rural Maharashtra spends more time re-establishing dropped connections than doing useful work. This is not a bandwidth problem — a Tier-3 city tower might deliver 10 Mbps — but a reliability problem: the connection drops for 30 seconds every few minutes as the user moves through signal shadows. Streaming architectures built for consistent low-latency connections cannot handle this pattern.

The CRDT-Agent Architecture

Conflict-Free Replicated Data Types provide the missing piece. A CRDT is a data structure with a specific mathematical property: concurrent updates from any replica can be merged deterministically without coordination. There is no central authority that decides whose edit "won." Every replica applies the same merge function to the same set of operations and arrives at the same result.

Applied to an AI agent:

Local State as the Source of Truth. Conversation history, tool outputs, and user edits live in a CRDT-backed local database — not a cache of cloud state, but the canonical record. Messages and edits are appended as concurrent operations on the same CRDT structure.

On-Device Inference as the Default Path. A quantized model runs locally, handling the most common query types — classification, structured extraction, short-form generation — without a network call. A 1-3B parameter model serves mid-range Android devices in emerging markets via llama.cpp or MediaPipe. Complex queries are queued for cloud dispatch, but the user never sees a blank screen while waiting.

Deterministic Sync, Not Conflict Resolution. When connectivity returns, local CRDT state syncs with the cloud replica. The cloud agent processes queued inference requests and appends responses to the same CRDT log. User edits merge deterministically with the cloud's version — there is no "conflict" to resolve, only concurrent operations the merge function handles automatically.

The key insight: the user's local state is never invalidated by a sync. The cloud enriches it, but the local view remains consistent throughout. This is the opposite of the cloud-tethered model, where the cloud owns the state and the client is merely a viewport.

Optimistic UI and Eventual Consistency

Traditional "optimistic UI" — showing a result before the server confirms — is a pattern bolted onto cloud-first architecture. CRDT-based local-first inverts this: the UI is always optimistic because the local database is the real database.

When a field sales user submits an order form, the data is written to a local CRDT store and the UI confirms immediately. A background queue handles sync negotiation. Cloud-side validation failures arrive as follow-up operations, not rejections that erase the user's work. This is not a retry loop — it is a state-based sync protocol: client and server exchange version vectors, compute the delta of unseen operations, and apply them. There is no "request timed out" modal. The queue negotiates network drops silently while the user continues working.

For AI, this means the agent's reasoning chain survives network partitions. A sales agent that analyzed local inventory and drafted a proposal while offline does not lose that work on reconnect. The cloud agent picks up the partial chain, enriches it with fresher data, and appends its contribution — but the local agent's work is preserved as an immutable part of the CRDT log.

Real-World Implementation Patterns

The principles are clear, but field deployments surface realities the literature does not cover.

Payload Structure for Variable Networks. Building the driver app for a major Southeast Asian ride-sharing platform, the network profile was brutal: 5G for a few seconds, then 4G for ten minutes, then LTE for twenty — each transition shifting available bandwidth and latency by an order of magnitude. The standard approach of streaming full JSON payloads on every sync cycle failed immediately; a driver crossing a signal shadow mid-sync would lose the entire payload and restart. The fix was a structured chunking protocol: outgoing mutations split into fixed-size envelopes with sequence numbers, incoming state deltas streamed as progressive fragments. The client could resume a partial sync from the last acknowledged envelope rather than re-downloading everything. CRDT version vectors gave each envelope a deterministic place in the merge order regardless of how many fragments arrived out of sequence.

Model Sizing for the Device Tier. Across the same deployment, drivers used Android devices in the ₹8,000-12,000 range with 3-4 GB RAM. A 1.5B-parameter quantized model (Q4_K_M) consumed ~900 MB and delivered 8-12 tokens per second — sufficient for address autocomplete, structured form filling, and route note extraction. The device handled high-frequency inference; the cloud handled occasional heavy queries like multi-stop route optimization. The CRDT layer made this split invisible to the driver.

Conflict-Free Is Not Loss-Free. CRDTs guarantee deterministic merge, not semantic correctness. Two dispatchers concurrently editing the same ride note produce a multi-value register — both edits survive, but the application must flag the conflict for review. Production systems layer domain-aware merge functions on top: "keep the most recently verified address," not "keep whichever write had the higher Lamport timestamp."

The Offline-First Testing Gap. Standard CI tests against localhost are inadequate. Offline-first applications need property-based testing: random sequences of concurrent operations across replicas, arbitrary network interruptions, and convergence assertions after every sync. Without this, a missing commutativity property surfaces only in the field — where a driver on a motorbike in Hanoi traffic is not filing a bug report.

Why This Matters Now

Three trends are converging to make this urgent rather than aspirational:

First, model compression has crossed a usability threshold. A 1-3B parameter model running at 10+ tokens per second on a $150 Android device is no longer a research demo — it is a shipping product, with inference engines (llama.cpp, MediaPipe, ExecuTorch) and quantized models available off the shelf.

Second, CRDT libraries have moved from papers to production-grade implementations. Yjs, Automerge, and their derivatives handle the hard distributed-systems problems — vector clocks, merge functions, tombstone garbage collection — so developers can work at the level of "append to this document" rather than implementing a state-based merge for a two-phase set.

Third, agent frameworks are proliferating, but nearly all assume a persistent cloud connection. The first framework that integrates a local CRDT store with on-device inference as a first-class primitive will capture the "next billion users" that cloud-tethered products structurally cannot reach.

Building for zero bars is not a niche concern. It is a reorientation of application architecture around the actual connectivity conditions of the majority of the world's smartphone users. The tools exist. The gap is in the integration — and in the willingness to treat offline capability as a foundation, not a feature request. At Unbound Apps, this is how we build for high-growth markets — starting from the network conditions on the ground, not the conference room WiFi.