If you have only followed LLM discourse online you would be forgiven for thinking every useful deployment is either a chatbot, an agent that can browse the web, or a demo that breaks 10 seconds after you stop recording.

This is not what is actually happening in production.

Four papers dropped on arXiv last week that are far more important than any foundation model announcement. None of them have a chat interface. None of them call themselves agents. All four deliver measurable, repeatable results in real industrial and engineering workflows. All four follow exactly the same design pattern.

The quiet LLM revolution nobody is talking about

None of these teams built a better model. None used GPT-5. All ran standard unmodified Llama 3 70B. All performance gains came from system architecture, not model capability.

The pattern they all discovered is this: you do not ask the LLM to be the expert. You build the expert system first. You use the LLM only as the translation layer between formal engineering representations and the messy unstructured world that humans operate in.

This is the opposite of almost every LLM architecture you see promoted. Everyone is trying to build agents that can plan, reason and make decisions. All the successful deployments are doing the exact opposite.

Gravure printing: the synthetic data hack that actually works

Rotogravure printing produces the packaging for almost every consumer good you buy. Lines run 24/7. Human inspectors stand 12 hour shifts staring at moving plastic film, looking for defects.

Automated inspection has been 12 months away for 15 years. The problem was never the model architecture. It was data. In 12 months of continuous production you might capture 30 usable images of a crease defect. Nobody will intentionally run a $10k/hour production line badly to generate training data.

This team did not ask an LLM to generate fake defects. They first built a physical model of every defect type: crease geometry, ink streak behaviour, misregistration offsets, camera noise profiles, lighting conditions. Every variable that mattered was parameterised and bounded by known physics.

Only then did they use the LLM. It had one job: render the parameterised defect definition into a photorealistic image matching the exact production line camera output, and emit a correct bounding box annotation.

Defect detection benchmark results

They generated 7533 synthetic images overnight for zero marginal cost. They trained RFDETR on this dataset and tested against held out real industrial defects.

The model trained on only synthetic data outperformed the model trained on every real defect image the factory had ever collected. This is not a marginal improvement. This is the difference between a system that works well enough to deploy and one that you throw away.

Petri net guided test generation for concurrent Rust APIs

Everyone has tried asking an LLM to write tests for an API. It produces nice looking code that never hits interesting edge cases. It will never find a race condition. It will happily call methods in an order that violates every precondition documented for the library.

This team did not ask the LLM to write tests.

They first modelled the entire target API as a coloured Petri net. Every resource, every state transition, every ownership rule, every valid execution interleaving was encoded explicitly. The Petri net generates every possible valid execution path, every near-valid path that should fail cleanly, and every concurrency interleaving that will trigger race conditions.

How the test pipeline avoids common LLM failures

Once they have that list of abstract test scenarios, they hand exactly one scenario to the LLM. The prompt is 17 words long: "Turn this sequence of Petri net transitions into valid Rust test code".

That is the only thing the LLM does. Every output is immediately compiled and executed. If it does not match the scenario, the exact error is fed back for repair.

This system found 3 previously unknown deadlocks in a widely used concurrent Rust library that had 100% line coverage from existing hand written tests. 92% of generated tests executed correctly on the first attempt.

Formal encoding of clinical trial protocols

Clinical trial protocols are 100 page natural language documents that define eligibility criteria, event timing, dosing schedules and adverse event rules. Right now every single one is read and interpreted exclusively by humans. There is no way to query them, simulate them, or automatically find matching patients.

Manual formal encoding of a trial takes approximately 80 hours of specialist work. People have been trying to automate this for 20 years.

This team did not ask the LLM to understand the trial. They first defined Temporal Ensemble Logic, a formal language that can express every constraint that appears in a trial protocol. The LLM had one job: translate this paragraph from the protocol into a valid TEL formula.

They ran this pipeline against 23 real trials pulled from ClinicalTrials.gov. Average encoding time dropped from 80 hours to 1.2 hours per trial. Measured semantic retention was 91%. This is not perfect, but it is good enough that you can now run automated cohort queries across every public trial. That has never been possible before.

Automated process control tuning

Every chemical plant, every refinery, every power station runs on PID controllers. Every single one is tuned by hand by a controls engineer. It takes weeks. Nobody does it well.

This team built a structured workflow that takes an existing dynamic simulation model of a plant. The LLM is used exclusively to write glue code between standard, well tested control components, pair manipulated and controlled variables, and set up simulation runs.

All stability analysis, all performance evaluation, all bayesian optimisation tuning runs entirely outside the LLM.

On the standard academic gas preheater benchmark this workflow produced a controller with 26.5% lower combined setpoint tracking and disturbance rejection error than the reference hand tuned controller used in every controls textbook.

The unifying architecture across every success

Every one of these deployments follows exactly the same structure. There are no exceptions.

This architecture solves every problem people complain about with LLMs. Hallucinations do not exist here. They are just another invalid output that gets caught and repaired in the validation loop.

Three rules for industrial LLM deployment

Across all four papers the working rules are identical:

1. All domain logic, all constraints, all correctness rules live outside the LLM. The LLM is never the source of truth.
2. The LLM is only ever given one very narrow translation task. It never makes high level decisions.
3. Every single output from the LLM is immediately validated by a trusted non-LLM system. Invalid outputs are fed back for repair.

That is the entire secret to getting useful work out of LLMs in 2026.

Domain	Formal constraint layer	LLM role	Measured outcome
Printing QC	Physics of printing defects	Generate annotated training data	80.9% mAP on real defects
Rust API testing	Colored Petri Nets	Concretize test scenarios	100% valid precondition compliance
Clinical trials	Temporal Ensemble Logic	Translate protocol text	91% semantic retention
Process control	Dynamic plant models	Generate controller glue code	26.5% reduction in control error

What comes next

We spent the last 5 years trying to make LLMs smart enough to replace engineers. That was the wrong goal. We should have been building systems that use LLMs to remove the boring parts of engineering work that nobody wanted to do anyway.

None of these systems replace anyone. They remove the part of the job that involved drawing 7000 bounding boxes, writing 1000 boilerplate test cases, transcribing 80 hours of legal text into logic, or tuning 12 PID parameters by hand.

The bottleneck is no longer the LLM. The bottleneck now is formal domain models. For every field where we already have good formal representations, LLMs will be deployed and delivering value within 18 months. For every field where we do not, nothing will change.

This is not the AI singularity. This is just very good automation. And that is more than enough.