APP Motors checks shop-floor tasks every five minutes and flags stalled work

The design engineer has not finished a drawing, an assembler is waiting, and the manager is making calls to find out why. At a small manufacturing operation, this chain can easily disappear behind the next urgent assignment. The creator of APP Motors described his own system on Habr: tasks are created by voice on a phone, linked through dependencies, and monitored by software that sends reminders about delays. For developers, the useful takeaway is a concrete way to divide conventional automation from the work of a language model.

According to the creator, development took about three weeks of actual work during evenings and weekends. The system brings together tasks, production work orders, inventory, tools, and drawing versions. Manufacturing staff are already using it, although the material presented includes no independent verification of the results.

From verbal instruction to task

The workflow starts right on the shop floor. A manager dictates an assignment, the phone transcribes the speech, and the model organizes the text into fields: title, description, urgency, deadline, and assignee. A person reviews the result before the task is created.

For example, a request to buy twenty sealing rings becomes a purchasing task card. If dimensions and material are missing, the system suggests clarifying the specifications. It can also suggest a link to an existing task for the same product. This shortens the path from an issue arising to an assignment the assignee can see.

The server looks up the employee in its own database before contacting the model. According to the creator, the name is replaced with an internal placeholder in the text being sent. This reduces the transfer of personal data, but does not in itself prove that the other fields contain no sensitive information.

An instructive bug also surfaced here: a function received context about projects and similar tasks but did not include it in the request to the model. Tests passed because they mocked the call one level higher. The creator added a check of the complete assembled request. For a team implementing an LLM, the practical lesson is to test the data that actually reaches the model, too.

What sends reminders about stalled work

Every five minutes, a background job scans active assignments. Deadline reminders, delay detection, and recipient selection are governed by rules in the code. If the model is unavailable, this mechanism keeps working.

Tasks can be linked through a “needed for” relationship: a drawing is needed for a part, and the part is needed for assembly. The software looks for an active task with no open subtasks and checks how long it has been since the last activity. The threshold is four hours for a critical chain and two days for a normal one. Priority is determined by the most urgent task in the chain.

Once the threshold is exceeded, the assignee receives a reminder explaining who is waiting for them. Those waiting receive a message about the blockage. After a subtask is accepted, the system tells them that work can resume. Repeat reminders are limited, and notifications are not sent at night.

The model is used to prepare recommendations for the manager’s summary. During a nightly scan of production data, SQL first identifies delays; the model then prioritizes them and writes a digest. According to the creator, the AI agent role has no write permissions for production reference tables. A human sends any suggested message on the manager’s behalf.

What to adopt and what to verify

A useful aspect of the case is its explicit accountability rules. The assignee submits the result for review with a photo or file, and the task creator either accepts the work or returns it with a comment. Inventory errors are corrected through reversing entries, drawing versions are stored as separate records, and important actions are recorded in an audit log.

The article describes how the system works, however, rather than demonstrating savings. It provides no before-and-after comparison of downtime, no rate of incorrectly parsed assignments, and no full maintenance cost. The development timeline also cannot automatically be applied to another factory with different processes.

The chosen metric raises another question: a comment counts as activity and resets the inactivity timer. This helps account for explanations of delays, but can conceal work that is not actually progressing. Teams adopting the approach should track activity on the task card separately from changes to the expected deliverable.

A practical starting point for your own team is a single process, such as the path from requesting a drawing to accepting a part. First define statuses, dependencies, and notification recipients, then add voice input. Measure the impact through lost assignments, waiting time, and the number of manual reminders the manager has to send.