Two engineers, the output of a ten-person standards commission
A multinational German automotive supplier gave 300 to 400 engineers a multi-agent assistant for DIN and ISO standards. Pexon built it on LangGraph with Azure AI Search, MLflow and pseudonymised query tracing. It answers single-shot definition queries at 100% accuracy and complex multi-standard queries at 70 to 80%.
The engagement at a glance
Written for the head of engineering or quality at an industrial group where design reviews wait on somebody reading DIN and ISO standards by hand, and where the last AI proposal died in the group security review.
| Customer | Multinational German industrial group, automotive supplier, precision components |
|---|---|
| Users | 300 to 400 engineering users at production go-live |
| Cloud | Microsoft Azure |
| Stack | LangGraph, Deep Agents, Azure AI Search, MLflow, Azure Application Insights, Prefect, Python, SAP integration, pseudonymisation layer |
| Compliance | DIN and ISO engineering standards, group security review passed including a constraint on model selection, all user queries pseudonymised before tracing |
| Status | Production, with a multi-region roadmap requested at go-live |
The standards are public. Reconciling them is the work.
Engineers at a precision components supplier work against a dense stack of DIN and ISO standards, internal and external. Answering a design question often means finding which standards apply, reading each one, and working out what they jointly require. None of those steps is difficult. Together, at volume, they are a bottleneck sitting directly in front of every CAD review.
The failure mode of the obvious solution is worth naming. A single retrieval chain over a corpus of standards answers definition questions well and then quietly falls over on anything that spans two documents, because it retrieves passages rather than reconciling requirements. It returns something plausible, an engineer trusts it, and the error surfaces later in a review.
There was a second constraint that had killed earlier attempts: the group security review. Any system touching engineering queries had to satisfy a compliance constraint on model selection and could not turn observability into staff surveillance.
Multi-agent, because the question decomposes
The system is built on LangGraph with Deep Agents over Azure AI Search. A complex query is decomposed rather than answered in one shot: identify the applicable standards, read each, then reconcile what they jointly require. That structure exists because it mirrors what an engineer actually does by hand, and because the reconciliation step is the one that cannot be recovered from a single retrieval pass.
Accuracy is published as a split rather than a blended figure. Single-shot ISO definition queries are answered at 100%. Complex queries spanning several standards run at 70 to 80%, with an active feedback loop improving them. A blended average across those two classes would be a more flattering number and a less useful one, because it hides which questions the system can be trusted with.
Observability runs through MLflow and Application Insights, orchestrated with Prefect, with SAP integration for the surrounding engineering context.
Trade-off: A multi-agent graph is slower and considerably harder to debug than a single chain, and every additional hop is a place for the reasoning to drift. It was worth it only because multi-standard reconciliation is the question with the actual business value. For definition lookups, the single chain would have been the better engineering decision, and the system still routes those the short way.
Pseudonymisation as a design constraint, not a compliance afterthought
All user queries are pseudonymised before they enter the tracing layer. The team runs a sentiment analysis loop over query patterns to find where the system frustrates people and tune it, and individual engineers remain unidentifiable in the observability stack.
This was required to pass the group security review, alongside a compliance constraint on which models could be selected at all. It is also the right default independently of that. An internal AI tool whose logs let anyone reconstruct what a named engineer was unsure about will be used carefully and sparingly, which is another way of saying it will not be used.
For anyone assessing EU AI Act exposure: an internal retrieval assistant supporting engineering judgement sits far from the prohibited and high-risk categories, but the transparency, logging and oversight obligations still shape the build. Pseudonymised tracing, a documented accuracy split by query class and a live feedback loop are exactly the artefacts a readiness assessment asks to see, and building them in costs a fraction of retrofitting them.
What changed
Production go-live ran as a live call with 300 to 400 engineering users. The customer's own assessment was that a Pexon team of two delivered the engineering output of a ten-person commission.
The tool then went viral internally, and the customer reordered 700 additional hours of engineering. A multi-region scaling roadmap across Germany, Poland and Shanghai was requested during the go-live call itself. Adoption of internal tooling that follows usefulness rather than a mandate is rare enough to be worth reporting as an outcome in its own right.
CAD reviews run 20 to 30% faster where the standards question used to be the gating step.
What this case study does not prove
The 70 to 80% accuracy on multi-standard queries is a real number and not a good enough one to remove a human from the loop. It supports engineering judgement; it does not replace it, and the system was built and communicated on that basis. Anybody proposing an agent system for standards compliance who quotes a single blended accuracy figure above 90% is either measuring only the easy class of question or is not measuring at all.
The adoption result is also less transferable than it looks. This tool went viral internally because the bottleneck it removed was one engineers felt daily and personally. A system that removes a bottleneck management feels but engineers do not will need a mandate, and mandated internal tools decay the moment the launch communication stops.
Nor does passing one group security review mean the architecture passes yours. The constraint here included model selection policy and pseudonymised tracing; a different group will care about data residency, retention or subprocessor lists, and those are answered by different engineering. The generalisable part is the sequence: settle the review constraints before building, not after.
Before and after
| Dimension | Before | After | Effect |
|---|---|---|---|
| Multi-standard question | Manual reading and reconciliation across documents | Decomposed and reconciled by agent graph at 70–80% accuracy | The gating step in a CAD review stops gating |
| Definition lookup | Search the standard, find the clause | Answered at 100% accuracy | Trivial questions stop consuming senior time |
| Observability | No AI tooling had passed the security review | Pseudonymised tracing with a sentiment feedback loop | Review passed, engineers not surveilled |
| Adoption | Previous attempts stalled | Viral internally, 700 hours reordered | Multi-region roadmap requested by the customer |
Questions buyers ask about this
How accurate is an AI assistant for standards and norms?
In this system, 100% on single-shot ISO definition queries and 70 to 80% on complex queries spanning several standards, with an active feedback loop improving the second figure. Publishing the split rather than one blended number is the point: a buyer needs to know which class of question the system is actually reliable for.
Why a multi-agent architecture rather than one retrieval chain?
Because a question spanning several standards is not one lookup. It decomposes into finding the relevant standards, reading each, and reconciling what they jointly require. A single chain collapses that into one retrieval step and loses the reconciliation, which is exactly the part an engineer cannot do quickly by hand.
How do you monitor an AI system without surveilling your engineers?
All user queries are pseudonymised before tracing. The team can run sentiment analysis over query patterns to tune the system, but individual engineers are not identifiable in the observability stack. This was required to pass the group security review and it is a reasonable default even where nobody demands it.
How does an internal AI tool actually get adopted?
This one went viral internally after a production go-live call with 300 to 400 engineering users, and the customer reordered 700 additional hours of engineering. Adoption followed usefulness rather than a mandate, which is the only version that survives once the launch communication stops.
Does the EU AI Act apply to a standards assistant like this?
An internal retrieval assistant that supports engineering judgement is far from a prohibited or high-risk system, but transparency, logging and human oversight obligations still shape how it should be built. Pseudonymised tracing, a documented accuracy split by query class and a feedback loop are the artefacts a readiness assessment asks for, and they are cheaper to build in than to retrofit.
If the security review is what kills your AI projects
The constraint that decides whether a system like this ships is rarely the model. It is pseudonymisation, model selection policy and what the logs reveal. The two-week blueprint puts those on the table first, so you find out in a fortnight rather than after the build.