A technician arrives at a customer site with a work order on a mobile device. The equipment is in front of them. The network is not.
The device still holds the job details downloaded that morning, the relevant equipment manual, part of the service history, and perhaps a small model able to interpret an error code or retrieve the next diagnostic step. The technician takes photographs, scans a serial number, records a measurement, replaces a component, and asks the assistant to prepare the service note.
It looks like an ordinary field-service application with an AI feature added to it.
It is, in fact, one of the better production AI architecture exercises I can imagine.
A Representative Problem
Richard Feynman was known for keeping a set of favourite problems in mind. New knowledge could be tested against those problems instead of remaining another isolated fact.
Raul Junco recently applied the same idea to system design: learn a small number of representative systems deeply enough to recognise their patterns elsewhere. A URL shortener teaches partitioning and caching. A payment system teaches idempotency. Collaborative editing teaches conflict resolution.
An offline field-service assistant belongs in the production AI version of that list because it refuses to keep the model separate from the system around it.
The exercise is not to draw a box labelled “LLM” next to a mobile application. It is to decide what happens when the assistant has incomplete context, when the connection disappears halfway through an operation, and when the physical repair disagrees with the state held by the back-office system.
Those are not edge cases added after the architecture review. They are the architecture.
Start With the Work
The technician has to identify the asset, diagnose the problem, replace or repair a component, test the equipment, record the result, and obtain the customer’s signature.
AI may retrieve the relevant manual section, compare symptoms with previous service notes, interpret unstructured observations, suggest diagnostic checks, and draft the final report.
But the workflow also contains deterministic facts. A part has a stock identifier. A technician has a certification. A work order has a status. A component either left the vehicle inventory or it did not.
The assistant can interpret the situation. It should not silently redefine those facts.
This gives the architect a first question: which operations can continue using local information, which can be queued, and which must stop until the device confirms current authority with the server?
Reading a cached manual may always be allowed. Drafting a service note can happen locally. Recording a measurement can be queued. Consuming a controlled part may require a valid cached entitlement. Closing a regulated inspection may require an online confirmation.
The network state alone does not decide. The action, evidence, authority, and consequence decide together.
Local State Needs an Operational Journal
Suppose the technician scans a replacement component and confirms its installation. The device sends the inventory movement to the server. The server commits it, but the connection drops before the acknowledgement returns.
The device cannot know whether the operation failed or merely lost its response.
If it creates a new request, the same component may be consumed twice. If it assumes success, the inventory record may never move.
The application therefore needs more than a cache of the latest screen. It needs a journal of intended operations.
Each operation can receive a stable identifier, such as a UUIDv7, before leaving the device. A local SQLite journal records the actor, device, work order, local sequence, operation type, evidence reference, permission snapshot, and synchronisation status. The server stores that identifier in the same transaction as the business change.
The idempotency record also binds the identifier to the actor, operation type, target object, and payload hash. Otherwise accidental reuse of an identifier can suppress legitimate work instead of preventing a duplicate.
A retry then means “apply operation 019… if it has not already been applied,” not “perform another inventory movement.”
This does not create magical exactly-once delivery. The request may still arrive several times. It creates an idempotent business effect that both sides can inspect.
The same pattern transfers to an agent calling an ERP, issuing a refund, updating a CRM record, or submitting a document for approval. Tool retries are business events that need stable identity.
Offline Authority Is Borrowed Authority
The technician may have been authorised when the route was downloaded. Their certification may expire that afternoon. The asset may be placed under a safety hold. A supervisor may revoke access after the device loses connectivity.
An offline device cannot continuously know current organisational state.
Any authority carried offline is therefore borrowed authority. It should travel as a signed, scoped, expiring capability tied to the sponsoring user, device, work order, permitted actions, and policy version.
Offline continuity creates a bounded window in which central revocation cannot be observed. The design response is a short lease, narrow scope, protected device, and review after reconnection, not a promise of instant revocation that the network cannot keep.
The assistant can still explain a procedure after permission expires. It can draft observations or prepare a recommendation. It should not use an old permission snapshot to create an irreversible action simply because the model remains available.
This is where probabilistic assistance and deterministic policy meet. The model proposes. A local policy decides whether the action may proceed, wait for approval, or stop until connectivity returns. If the server later rejects a queued operation, the workflow needs a visible exception path rather than a silent overwrite.
Every long-running agent carries some version of borrowed authority between the moment a task begins and the moment an action occurs.
Preserve Observation, Inference, and Decision
Imagine the assistant recommends replacing a controller after reading an error code, a photograph, and version 4.2 of the service manual. The technician accepts the recommendation. Before synchronisation, the manual is updated and the server receives a new diagnostic bulletin.
The final database state can show that the controller was replaced. It cannot explain what information was available when the decision was made unless the system preserved it.
The record should separate three things:
- Observation: serial number, error code, measurement, photograph, and technician note.
- Inference: model version, retrieved manual section, relevant context, recommendation, and stated limitation.
- Decision: what the technician approved, rejected, or changed, including the reason for an override.
Combining all three into one generated service note makes the workflow look clean and the audit trail almost useless.
This separation also makes improvement possible. If a recommendation was wrong, the team can determine whether the problem came from the observation, the retrieved source, the model, the permission state, or the human decision.
The Physical World Is Part of the State
When the device reconnects, uploading the local copy is not enough. Another technician may have updated the work order. Inventory may have been corrected centrally. The asset may have moved to a different contract.
Last-write-wins is attractive because it is simple. It is also a poor default for business events with different meanings.
A note may be appended. A status transition may require a version check. An inventory movement may be accepted once by operation identifier. A signature may be immutable. A recommendation may be retained as evidence even when the server rejects its proposed action.
Reconciliation belongs to the domain, not to a generic synchronisation engine.
And the database still does not own the physical world. A repair is not complete because a status field says so. It is complete because someone changed a component, tested the equipment, and recorded suitable evidence.
The technician is not a fallback added because the model is imperfect. The technician is one of the authorities through which physical reality enters the system.
Observe Both Sides of the Disconnection
The system also needs measures that survive the gap.
On the device, useful signals include journal growth, storage pressure, age of the oldest unacknowledged operation, failed evidence capture, model availability, and time remaining on the permission lease. During synchronisation, watch duplicate deliveries, rejected or conflicted operations, cursor divergence, and time to convergence after reconnection.
The business measures remain separate: job completion time, repeat visits, technician override rate, inventory corrections, cases completed without AI, and exceptions requiring supervisor review.
Telemetry should be buffered locally with lower priority than business events. Losing an observability upload should not block a repair, but the system must report the blind period when connectivity returns.
Break the System Deliberately
Do not review only the normal sequence. Inject failures:
- Disconnect before the technician opens the work order.
- Drop the server acknowledgement after an inventory movement commits.
- Upload the same synchronisation batch twice.
- Revoke permission while the device is offline.
- Change the manual after the assistant makes its recommendation.
- Let another user update the same work order before synchronisation.
- Move the device clock backwards or return acknowledgements out of order.
- Fill local storage while evidence is being captured.
- Have the technician override the recommendation or continue without AI.
- Reconstruct the event two months later using only retained evidence.
For each failure, ask what remains usable, what the AI may recommend, what the system may execute, which evidence must survive, who owns the exception, and whether the operation can be retried safely.
The quality of the architecture appears in those answers, not in the model diagram.
An offline field assistant is useful as a favourite problem because it makes the dependencies visible. Idempotency depends on stable operation identity. Permission depends on action and time. Provenance depends on preserving the evidence available at the moment of inference. Completion depends on evidence from the physical world.
The model can remain available while the system must refuse an action. The database can be current while its representation is wrong. The technician can make the right decision using evidence the server has never seen.
An architect who can explain those contradictions has learned more than how to connect a model to an application. They have started to design the system in which the assistant will have to live.