When a batch or lot fails inspection, a quality engineer opens a nonconformance report and starts looking. Which line and equipment ran it. Which raw material lots went in. What the sensors showed. What maintenance happened recently. Which procedure applied, and whether the operators followed it. The evidence lives in a manufacturing execution system, a quality system, historians, maintenance logs, supplier records, and procedure documents. Assembling it can take longer than the analysis.
The path of an investigation depends on what the first results show, which is the case for an orchestrator that plans and delegates. The same fact makes the boundaries important. The system gathers and ranks. It does not disposition product, and it never writes to a control system.
The design
- Deviationreport opened
- Orchestratorlists questions to answer
- Gatherbatch, equipment, maintenance, supplier, procedure
- Computecode: SPC, comparisons, trends
- Hypothesesranked, each with evidence
- Quality engineerinvestigates and dispositions
- Brief and logevidence, ranking, decision
- Just-in-time retrieval. The report carries identifiers: batch, line, equipment, lot. The system keeps those and fetches records as questions arise, instead of loading a data dump into context. This is the approach Anthropic recommends for agents working with large data.
- Consolidated tools. One tool returns a batch's context with the fields an engineer would look at, in readable form. Dozens of low-level table queries make the model's job harder. Anthropic's tool-design guidance says to consolidate multi-step operations and return meaningful names, not raw identifiers.
- Statistics in code. Control charts, run comparisons, and trend tests are computed by tools. The model reads their output and the free text around it: operator notes, maintenance comments, procedure steps. Text is where it adds value.
- Hypotheses with evidence. The brief ranks likely causes and, for each, lists the supporting and contradicting evidence with record references. An explicit "what would confirm this" line for each hypothesis tells the engineer where to look first.
- Prior similar events. Retrieval over closed reports finds earlier deviations with similar signatures and what the root cause turned out to be.
Boundaries that matter
Keep the system on the IT side. It reads from replicas or historians through read-only accounts, and it has no path to programmable controllers or equipment. Any action, such as quarantining a lot or opening a corrective action, is a human step in the quality system. In regulated settings, the quality system record is the record. The brief is an input to it, saved with the deviation so the reasoning is traceable.
Limit the run. Cap the number of tool calls and the tokens per deviation, and log each one. Anthropic notes that agents can compound errors, which is a reason to prefer bounded runs with a person at the end.
How to evaluate it
- Closed deviations. Replay past reports whose root cause was confirmed. Did the confirmed cause appear in the top three hypotheses? Grade with code against the closed record.
- Evidence completeness. Did the brief include the records the engineer ended up using? Check against the engineer's notes.
- Reference accuracy. Does each cited record exist and say what the brief says? Code can verify existence, and a model judge can assess support.
- Time to first hypothesis. Measure the current and new process, by deviation type. Report the types where the system is no better.
A good first target is a recurring deviation type with well-kept records, where closed cases give you a labeled set from day one.
This is a reference design. It describes how we would build the system and cites Anthropic's documentation for platform facts. It is not a client case study, and the figures it uses are list prices or worked examples, not results.
Have a process like this?
Bring it to a 45-minute working session.