Offline-First AI for Deskless Workers

Offline-first architecture principles

Offline-first AI inverts the typical client-server pattern. Instead of assuming connectivity and handling offline as an error case, you assume offline and treat connectivity as an enhancement.

Principle 1: The device is the primary compute environment.

The AI model, the knowledge base, and the application logic all run on the device. There is no "primary server" that the device depends on. The device is self-sufficient.

Offline-First Architecture:
┌──────────────────────────────┐
│ Device (phone/tablet/laptop) │
│ ├── AI model (quantised)     │
│ ├── Knowledge base (local)   │
│ ├── Application logic        │
│ ├── Query history + cache    │
│ └── Sync queue               │
└──────────┬───────────────────┘
           │ (when connected)
           ▼
┌──────────────────────────────┐
│ Server (optional enhancement)│
│ ├── Larger model for complex │
│ │   queries                  │
│ ├── Updated knowledge base   │
│ ├── Cross-user analytics     │
│ └── Sync reconciliation      │
└──────────────────────────────┘

Principle 2: Pre-load everything the worker needs.

Before the worker goes into the field, their device downloads:

• The AI model weights (1.5-4GB)
• The relevant knowledge base (technical documentation, procedures, regulations)
• Any pre-computed embeddings and vector indexes
• The application itself (PWA or native app)

This happens on Wi-Fi, at the office, or at home. When the worker arrives at the job site, everything is already on their device.

Principle 3: Queue and sync, do not block.

When the device has connectivity, it syncs:

• Knowledge base updates (new documents, updated procedures)
• Query logs and analytics (metadata only, not content, per privacy requirements)
• Model updates (new quantised weights, though infrequent)
• Cached responses from complex queries that were escalated to cloud

When connectivity is unavailable, nothing blocks. The worker continues using the local model and local knowledge base. Sync happens opportunistically when connectivity returns.

Principle 4: Progressive enhancement.

Sync-when-connected: queue, reconcile, confirm

The sync layer is what distinguishes a good offline-first application from a disconnected application. Done well, it is invisible to the user.

The sync queue pattern:

class SyncQueue {
  constructor() {
    this.queue = []; // Persisted to IndexedDB
  }

  async addToQueue(item) {
    item.timestamp = Date.now();
    item.status = 'pending';
    item.retryCount = 0;
    this.queue.push(item);
    await this.persistQueue();
  }

  async processQueue() {
    if (!navigator.onLine) return;

    const pending = this.queue.filter(i => i.status === 'pending');

    for (const item of pending) {
      try {
        await this.syncItem(item);
        item.status = 'synced';
      } catch (error) {
        item.retryCount++;
        if (item.retryCount > 5) {
          item.status = 'failed';
        }
      }
    }

    // Clean up synced items older than 24 hours
    this.queue = this.queue.filter(
      i => i.status !== 'synced' || Date.now() - i.timestamp < 86400000
    );

    await this.persistQueue();
  }
}

// Listen for connectivity changes
window.addEventListener('online', () => syncQueue.processQueue());

What to sync:

Conflict resolution:

When both the device and server modify the same data during an offline period, you need a conflict resolution strategy:

• Last-write-wins: Simplest approach. Whichever change was made more recently takes precedence. Works for most AI-related data where the latest version is the correct version.
• Server-authoritative: Server version always wins. Appropriate for knowledge base content where the server maintains the authoritative corpus.
• Merge: Both changes are preserved. Appropriate for additive data like bookmarks, notes, or favourites.

For AI knowledge bases, server-authoritative is usually correct. The server has the latest documentation, the latest procedures, the latest regulatory updates. When the device syncs, it accepts the server's version.

Five deployment scenarios

1. Construction site inspection

A safety inspector walks a construction site checking for compliance issues. Their tablet runs Gemma 4 E4B with a knowledge base containing:

• Current building codes and safety regulations
• Site-specific plans and specifications
• Historical inspection reports for this site
• Photo-based deficiency templates

The inspector photographs a potential issue, describes it to the AI assistant ("Is this rebar spacing compliant with the foundation spec for Building C?"), and gets an answer referencing the specific structural drawings and applicable building code section. No internet needed.

When the inspector returns to the site office and connects to Wi-Fi, inspection reports sync to the central system, and any updated building codes or site plans download to the tablet.

2. Clinical decision support

A nurse in a rural clinic uses a tablet running a local model with a medical knowledge base. The clinic has intermittent satellite internet.

The nurse asks: "Patient presents with crushing chest pain, diaphoresis, and radiating pain to left arm. What is the differential diagnosis and immediate management?"

The local model provides a structured differential (acute MI, unstable angina, aortic dissection, PE) and immediate management steps, referencing clinical guidelines. The answer is available in seconds, without waiting for a satellite link.

When connectivity is available, the query (without patient identifiers) syncs to the central health system for quality monitoring and continuing education tracking.

3. Field maintenance for utilities

A power line technician encounters an unfamiliar transformer model. Their rugged phone runs a local model with a knowledge base of equipment manuals, maintenance procedures, and safety protocols.

"What is the oil sampling procedure for a GE Prolec 69kV transformer with serial number prefix TW-2018?"

The local RAG pipeline retrieves the specific maintenance procedure from the pre-loaded equipment library and generates a step-by-step guide with safety warnings.

4. Retail associate product knowledge

A retail associate at a home improvement store uses a phone-based AI assistant to answer customer questions. The knowledge base contains product specifications, compatibility information, and installation guides for 50,000+ products.

Customer asks: "Will this deck stain work on pressure-treated lumber that was installed last month?"

The associate's device searches the product database, finds the stain specifications and the pressure-treated wood curing requirements, and provides a clear answer: the lumber needs to cure for at least 3-6 months before staining, with a recommendation for an alternative product designed for newly treated wood.

5. Logistics and warehouse operations

A warehouse worker uses a wrist-mounted device with voice input. The local model handles inventory queries, picking instructions, and shipping regulation lookups.

"What are the hazmat shipping requirements for lithium batteries classified as UN3481?"

The local knowledge base contains current IATA and DOT hazardous materials regulations. The response provides the specific packaging, labelling, and documentation requirements, potentially preventing a dangerous shipping violation.

Better when connected, functional when not

The best offline-first AI applications provide a noticeable quality upgrade when connectivity is available, creating a natural incentive for workers to sync their devices regularly.

Enhancement layers:

Connected enhancement 1: Cloud model escalation

When the local model produces a low-confidence answer or the query is particularly complex, and the device has connectivity, escalate to a larger cloud or on-premises model:

async def answer_with_escalation(query, local_model, cloud_client, connectivity):
    # Always try local first
    local_response = await local_model.generate(query)
    local_confidence = estimate_confidence(local_response)

    if local_confidence > 0.7 or not connectivity.is_available():
        return local_response

    # Escalate to cloud/on-prem for better answer
    cloud_response = await cloud_client.generate(query)
    return cloud_response

Connected enhancement 2: Expanded knowledge base

When connected, the device can search a larger server-side knowledge base in addition to its local index:

async def search_with_expansion(query, local_index, server_index, connectivity):
    local_results = await local_index.search(query, top_k=5)

    if connectivity.is_available():
        server_results = await server_index.search(query, top_k=5)
        # Merge and re-rank results from both sources
        merged = merge_and_rerank(local_results, server_results)
        return merged

    return local_results

Connected enhancement 3: Feedback loop

When connected, the device can send usage analytics (queries asked, documents accessed, features used) to inform knowledge base curation. If many technicians are asking about the same equipment model or procedure, the system can prioritise those documents for pre-loading.

The key user experience principle: Never show the user that they are offline unless it affects their immediate interaction. If the local model handles their query, the response should feel identical whether they are connected or not. Only surface connectivity status when escalation or sync would have improved the experience.