MoldGuard AI: Preventing Plastic Waste Before Production with Agentic AI on AWS
MoldGuard AI is an agentic injection molding decision support system that forecasts production risk prior to the start of a batch, suggests fewer waste and lower energy settings, explains its choices, and maintains human oversight. This post describes how we developed the project from a basic machine learning prototype to a multi-agent system powered by AWS.
MoldGuard AI: Preventing Plastic Waste Before Production with Agentic AI on AWS
In manufacturing, waste is often discovered only after production.
In injection molding, a poor combination of temperature, pressure, holding time, and other process parameters can be repeated across thousands of production cycles. By the time the problem is noticed, the factory may already have produced a large number of defective plastic parts while also consuming unnecessary energy.
This is the problem we aimed to solve using MoldGuard AI.
What is MoldGuard AI?
MoldGuard AI is a decision support system designed for injection-molding operators, process engineers, and production teams.
Before a production batch starts, the operator enters the planned machine settings and production details. MoldGuard analyzes these settings and estimates whether the batch is likely to produce good parts or whether it needs review.
However, we did not want to stop at prediction.
The system also explains which parameters contribute to the risk, searches for better machine settings, estimates the possible energy and material impact, retrieves relevant process guidance, and presents the final recommendation for human approval.
The goal is simple:
Waste should be prevented before production begins.
Phase 1: Starting with a simple ML prototype
Our first version was intentionally simple and straightforward.
We used synthetic injection molding data to test whether machine parameters, such as injection temperature, injection pressure, holding pressure, back pressure, injection time, and holding time, could be used to predict production quality.
The machine learning model classified a planned batch into quality risk categories, such as good, warning, or reject.
This phase helped us quickly validate the idea; however, we knew that synthetic data could not be the final solution.
Phase 2: Moving to real manufacturing data
The next step was to work with real injection molding datasets.
We expanded the system to include multiple machine learning components.
We used an XGBoost model for production quality risk and a different model for energy estimation.
We also added SHAP-based explanations so that an operator can understand which process parameters influence the model's decision.
Another important addition was the out-of-distribution detection using an isolation forest.
A machine learning model should not confidently make recommendations for operating conditions that are very different from the data it learned from. MoldGuard checks whether the current batch looks familiar to the training distribution.
If the batch is unfamiliar, the system requests a human review instead of pretending to know the answer.
From prediction to optimization
Although predicting that a batch is risky is useful, the operator still needs to know what to change.
Therefore, we added a constrained optimization engine.
For a planned production batch, the optimizer evaluates approximately 1,800 nearby parameter combinations.
It considers multiple objectives, including predicted product quality, reject probability, estimated energy consumption, and the extent to which the new settings differ from the operator's original settings.
Candidates that fall outside the learned operating distribution are rejected by the algorithm.
The results are not simply warnings. MoldGuard can show the operator the current parameters, recommended parameters, and estimates before and after impact.
Phase 3: Adding process knowledge with RAG
One of the questions we asked ourselves was:
Why should an operator trust a recommendation simply because an ML model produces it?
This led us to add retrieval-augmented generation.
MoldGuard retrieves relevant information from process documentation, material guidance, and operating procedures.
For example, if the optimization system recommends modifying the injection pressure, the knowledge layer can retrieve guidance related to the injection pressure and the selected material.
The ML models remain responsible for prediction and optimization, whereas the retrieval system provides supporting evidence.
This distinction was important to us because we did not want a language model to invent manufacturing parameters.
Phase 4: Turning MoldGuard into an agentic system
The final phase was to ensure that the different capabilities worked together intelligently.
For this, we used the Strands Agents SDK.
MoldGuard has a supervisor agent that coordinates specialist agents.
The Quality Agent works with the risk model, confidence checks, explainability, and out-of-distribution detection.
The optimization agent works with the energy model and constrained optimization engine.
The knowledge agent retrieves relevant process and material information.
The supervisor coordinates these capabilities and presents the results to the operator.
However, there is one important limitation.
The final safety check is deterministic.
The language model cannot override process parameter bounds, out-of-distribution checks, confidence rules, or the requirement for human approval.
We wanted the AI to assist the operator rather than replace them.
How we used AWS
AWS became the platform that connected the different parts of MoldGuard.
For the open-source AI layer, we used the Strands Agents SDK to build our multiagent workflow.
For cloud deployment and machine learning, our architecture uses AWS services throughout the full pipeline.
Amazon S3 stores datasets, trained model artifacts, and other related files.
Amazon SageMaker AI is used for the machine learning training and model management workflow.
Amazon Bedrock AgentCore runs the agentic workflow built using Strands.
Amazon DynamoDB stores analysis and prediction history so that previous runs can be traced.
Amazon CloudWatch provides logs and runtime observability.
The backend is built with FastAPI and is designed to run using AWS App Runner.
The React and TypeScript frontend is hosted using AWS Amplify Hosting.
Together, these services allow us to connect model training, agent orchestration, storage, monitoring, and the final user interface into one system.
What fought back?
The hardest part of building MoldGuard was not adding more AI.
It was deciding what the AI should and should not be allowed to do.
Our first version could predict production risk, but a prediction alone was not very actionable.
Adding optimization introduced another problem. A mathematically better parameter combination may still be unrealistic if it is far outside the conditions represented in the training data.
That is why we introduced out of distribution detection and parameter constraints.
RAG created a similar challenge. We did not want retrieved text or a language model to become the source of numerical machine recommendations.
We eventually separated the responsibilities clearly.
The ML models make predictions.
The optimizer searches for better settings.
RAG retrieves supporting evidence.
The agents coordinate the investigation.
Deterministic rules perform the final safety checks.
A human makes the final decision.
That separation became one of the most important design decisions in the project.
What MoldGuard produces
For every planned batch, the final interface can present:
Production quality risk
Model confidence
Whether the batch is inside the learned operating distribution
The most important parameters affecting the prediction
Current and recommended process settings
Estimated quality improvement
Estimated energy impact
Material at risk estimates
Supporting process documentation
A clear human review decision
This makes MoldGuard more than a prediction dashboard.
It becomes a decision support system for what the operator should examine before starting production.
What we learned
MoldGuard started as a simple machine learning experiment.
It gradually evolved into a system combining real manufacturing data, machine learning, explainability, anomaly detection, optimisation, retrieval-augmented generation, AI agents, human review, and AWS infrastructure.
The biggest lesson for us was that using more AI is not always the answer.
For a manufacturing application, knowing when the system should stop and ask a human is just as important as making a prediction.
What's next?
Our next steps are to validate the system on more manufacturing data, evaluate it across different machines and materials, and work with domain experts to improve the process constraints and environmental impact calculations.
In the future, the same approach could also be extended to other manufacturing processes where small parameter changes can create large amounts of repeated waste.
MoldGuard AI is built around one simple idea:
Instead of analysing waste after it is produced, can we help prevent it from being produced in the first place?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article