Small AI models on warehouse handhelds

Suppose the employee already has the correct receiving record open. After looking at the packaging, they type: “two cartons, one torn on the side, other wet underneath, haven't checked inside, photo of torn one only.” They attach a photo of the torn carton. The next person handling the report needs to distinguish the cartons and know which one appears in the photo.

For this example, the application could suggest: “One carton is torn on the side; the other is wet underneath. The attached photo shows the torn carton. The contents of both cartons have not been inspected.” The employee reads the description and corrects anything that does not match what they observed. They then approve the text for attachment to the record.

The description separates the observations about the two cartons and keeps clear that their contents have not been inspected. For shorter, repetitive reports, a form with a choice of damage types may work just as well. A model is worth comparing when observations vary and do not fit easily into a few fixed fields.

The employee approves the observation

The proposed description needs to be easy to read on the handheld's screen. Scrolling through a long answer or switching to a separate chat adds work. This task calls for a short draft alongside the original observation, with a way to edit it before approval.

Missing information should remain missing. If the employee does not say how many packages were affected, the application should not guess. If the form requires a count, the employee needs to supply it. Decisions about what happens to the goods still follow warehouse procedures and the employee's authority. Rewriting an observation gives the model no basis for making those decisions.

The receiving record's identifier should come from the record already open in the warehouse application. The employee should not have to type it into a chat and then check whether the model preserved it. For tasks that involve reading a barcode, the existing scanning function is the place to start.

AI on a handheld can mean different things

Zebra describes its AI Data Capture SDK as tools for computer vision, including barcode reading and recognizing text in images. Those capabilities do not establish that a particular device can run a language model to rewrite a note. Reading a label and composing a sentence from a typed observation are separate tasks.

Google provides LiteRT-LM for running language models on Android. Its older MediaPipe LLM Inference API is now in maintenance-only mode, and Google recommends moving to LiteRT-LM. That is a reason to confirm current support for the proposed software and specific handheld with the supplier.

The hardware discussion should therefore start with the devices employees actually carry: the exact model, operating system version, and applications running during a shift. “Small model” does not guarantee a short wait or negligible battery use. Memory requirements and application behavior need to be assessed on the chosen device.

A finished note may still be waiting to reach the WMS

A local model can prepare text without sending the generation request to an external server, provided the required software and model are available on the handheld. Saving the approved note in the warehouse management system, or WMS, may still require a connection to that system's server.

If the application holds a note on the device while the connection is unavailable, the employee should be able to see that it is waiting to be sent. Once the WMS receives it, a clear confirmation should appear against the correct receiving record. The employee then knows whether a colleague handling the issue can read the description in the system. A generic “saved” message would leave that unresolved.

We also discuss application dependencies in our article on factory manuals without internet access. On a warehouse handheld, the question is whether the employee can finish recording an observation and recognize when the warehouse system has actually received it.

Does the helper earn its place on the device?

Working with several common kinds of notes on the actual handheld will give the buyer a useful comparison. Employees should be able to try the application alongside their current method. If they regularly delete invented details or wait for a sentence they could write faster themselves, the case for deployment is weak. For repetitive reports, a list of categories and a short text field may be enough.

Waiting time includes the first launch as well as routine use alongside the warehouse application. Google's LiteRT-LM documentation notes that loading a model can take a noticeable amount of time. Responsiveness and battery use need to be assessed over a period that reflects the intended workload. One completed note cannot show how the device will behave throughout a shift.

Syntalith can help build a custom AI application that organizes a typed observation, shows the draft to the employee for approval, and passes it to an agreed destination in the warehouse system. A small trial on a handheld used in the warehouse is a practical starting point. Its results can inform whether to develop the application further and how it should connect to the WMS. See our pricing page for pricing information.

The first conversation can start with what employees currently write and who uses those notes later. The handheld's model name will also help. There is no need to share WMS data or prepare a full specification at that stage.