AI Agents · Ai

AI Agent for Production Quality Monitoring

AI Agent for Production Quality Monitoring is the work that defines the next phase of enterprise software. ERP systems hold the most valuable business data in the company —.

John Kihiu12 min read

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.

PYTHON · CONTROL-CHART FLAG, DETERMINISTIC
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.

Don't let the agent close or reclassify quality records

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.

LayerOwned by
Anomaly detection (control charts, thresholds)Deterministic statistics
Correlation with related shop-floor eventsAgent, clearly labeled as correlation
Root cause determinationQuality engineer, human judgment
Nonconformance record closureHuman, 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.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.