Quality data on a shop floor — scrap rates, rework counts, inspection failures logged against a production order in Acumatica's manufacturing module — is usually reviewed after the fact, in a weekly report, by which point a drifting process has already produced a week of bad output. An agent that watches this data as it's recorded and surfaces anomalies in near real time changes the review from retrospective to proactive, without needing anything more exotic than a threshold check most of the time.
Most quality flags don't need an LLM
A scrap rate exceeding a control limit, a run of consecutive rejects on the same operation, a defect code spiking above its historical baseline — these are statistical process control problems with decades of established math (control charts, moving averages, run-length tests) behind them. Compute them with plain statistics, not by asking a model to eyeball a table of numbers and decide if something looks wrong. The LLM's job starts after a flag fires: turning "defect code 4021 spiked 3x on work center WC-12" into a plain-language summary and a plausible set of contributing factors pulled from related data, not deciding whether the spike is statistically real.
def check_scrap_rate(work_center: str, window_days: int = 7) -> dict | None:
recent = get_scrap_rate(work_center, window_days)
baseline_mean, baseline_std = get_baseline(work_center)
z_score = (recent - baseline_mean) / baseline_std
if abs(z_score) > 2.5: # ~2.5 sigma, tune per process
return {
"work_center": work_center, "recent_rate": recent,
"baseline": baseline_mean, "z_score": round(z_score, 2),
}
return None # no flag, nothing for the agent to explain
The agent correlates, not diagnoses
Once a flag fires, an agent with access to related Acumatica data can pull context a human would otherwise have to gather manually: was there a material lot change on that work order, did the operator change mid-shift, was there a recent BOM or routing revision, does the timing correlate with a machine maintenance event. Present these as candidate correlations for a quality engineer to investigate, explicitly labeled as correlation and not root cause — the agent has no way to actually determine causation from ERP data alone, and presenting a correlation as a diagnosis is a good way to send someone chasing the wrong fix.
Nonconformance records and quality holds usually feed into compliance and audit trails (ISO 9001 and similar). An agent should draft findings and suggest a root-cause direction, but closing a nonconformance record or reclassifying a defect is a decision that needs to stay with the quality engineer of record — both because the judgment call requires shop-floor context the agent doesn't have, and because the audit trail needs a human signature on the record.
Context window limits mean summarize before you alert
A shift's worth of inspection records for a busy line can be thousands of rows — don't hand that raw to the model on every check. Pre-aggregate (counts by defect code, by operator, by hour) in code, and give the agent the aggregate plus the specific flagged anomaly, not the raw table. This is both cheaper and produces a tighter, more accurate summary than asking the model to do the aggregation itself from raw rows.
False positive cost is not symmetric
A missed real quality issue costs far more than an unnecessary alert investigated and dismissed in five minutes — so tune thresholds conservatively toward catching real issues, and manage alert fatigue through better triage (grouping related flags, prioritizing by severity) rather than by raising thresholds until fewer things fire. If the alert volume is the actual problem, fix the routing and grouping first before making the detection less sensitive.
Tie flags back to the actual production order
Every flag needs to resolve to something actionable in Acumatica — a specific production order, work center, and shift, with a link a quality engineer can click through to the actual record. A summary that says "quality issues detected in manufacturing" without that traceability is not useful; a summary that says "WO-108822, work center WC-12, second shift, defect code 4021" is something someone can walk out onto the floor and act on.
| Layer | Owned by |
|---|---|
| Anomaly detection (control charts, thresholds) | Deterministic statistics |
| Correlation with related shop-floor events | Agent, clearly labeled as correlation |
| Root cause determination | Quality engineer, human judgment |
| Nonconformance record closure | Human, for the audit trail |
Wrapping up
Detect anomalies with the statistical methods built for exactly this problem, and use the agent for what LLMs are actually good at afterward: summarizing pre-aggregated data and surfacing plausible correlations for a human to investigate. Keep record closure and root-cause determination with the quality engineer, and always resolve a flag back to a specific, clickable production order rather than a vague summary nobody can act on.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.