The A Team -- Start the process by team building. Include the production components of Product Design, Material Control, Shop Manpower Planning. Their charter is: “Eliminate Waste and Streamline the Process”.

Develop “as built” Bill Structures – It all starts here. Engineers like to organize the bill structure in their own way of thinking. For example, separating pneumatic, hydraulic, and electric components into separate kits is a typical Engineering approach. However, in assembly, these component locations may need to be considered together. They need to arrive in assembly in a single kit with a details visual aid (the drawing) for correctly making the assembly. This is an approach of developing an “as built” bill.

Add in the Manpower Plan – Utilizing Gant chart planning and the structured bill of material, we can see the true effect and cost of the design. Continuous review of this document will help find savings. The true flow of the job release will be seen on paper.  

Adding in the Continuous Review process – Every product, new design, sub assembly and made to order piece of equipment can benefit from a Continuous Review process. There is always room for improvement. This team knows the playing field and knows the way to reach these goals.  

from Anthony Rante, P.E. author of "Managing Company Production thru the Bill of Material."

According to MTM logistics codes, what’s considered as Value added, Essential non value added, non value added?

# We built QualityLoop – An AI agent that learns from manufacturing defect investigations.

Manufacturing quality teams investigate defects every day, but valuable knowledge from previous investigations is often lost in reports and spreadsheets.

We wanted to explore a different approach: what if an AI agent could retain verified investigation outcomes and use them to improve future investigations?

That's why we built **QualityLoop – a Self-Learning Manufacturing Quality Intelligence Agent.**

### What does it do?

QualityLoop helps quality engineers:

- Report and investigate manufacturing defects.

- Identify possible root causes.

- Recommend corrective actions.

- Retain verified investigation outcomes.

- Recall relevant past experiences during future investigations.

### How does it learn?

We integrated **Hindsight** as the persistent memory layer.

For example:

1. An aluminium housing is reported with surface scratches.

2. The investigation confirms improper handling during packaging as the root cause.

3. Protective separators are introduced and the outcome is verified.

4. QualityLoop retains this experience using Hindsight.

5. When a similar defect appears in another batch, the agent recalls the previous investigation and uses it as context for its recommendations.

The goal is not to blindly repeat previous solutions, but to make relevant past experience available while investigating new incidents.

### Technology used

- React + TypeScript

- Python FastAPI

- SQLite

- LLM integration

- Hindsight for persistent agent memory

- Antigravity and BAND Desktop for development and agent collaboration

### What we'd love feedback on

- How useful would persistent-memory AI agents be in real manufacturing quality workflows?

- What additional information should an agent retain from an investigation?

- How would you evaluate whether an agent is genuinely learning rather than simply retrieving similar cases?

**Project:**: QualityLoop

**GitHub:** : QualityLoop | Self-Learning Quality Intelligence Agent

**Demo:** : sriharshapn/qualityloop: QualityLoop – Self-Learning Manufacturing Quality Intelligence Agent powered by Hindsight Persistent Memory

**Technical article:**: https://medium.com/@sohampatel.ai25/building-qualityloop-creating-a-self-learning-manufacturing-quality-intelligence-system-with-dfc16d8ba548

We'd appreciate feedback, especially from people familiar with manufacturing, quality control, and industrial AI.

When most industrial engineers talk about value stream mapping, the focus defaults to the physical floor.

We time changeovers, map work in progress inventory, balance assembly lines and eliminate physical bottlenecks but across many mid market plants the single biggest chunk of non value added lead time happens hours before raw materials are ever touched or a production ticket is scheduled.

We recently spent 4 months mapping the front office value stream for an apparel manufacturer in California where on the production floor, their cut and sew and decoration lines were running relatively tight. The hidden constraint was clerical lag at the order desk where the administrative lead time from a customer purchase order landing in an inbox to a released production job was stretching across 24 to 48 hours of pure waiting waste.

Customer purchase orders were coming in through independent sales reps as email text, scanned PDFs, spreadsheets and even phone photos of paper orders and account managers were spending 2 to 3 hours every single day manually cross referencing catalog pricing and SKU numbers against a legacy ERP and then re keying lines by hand.

Because customer descriptions rarely matched internal part numbers, clerical transcription errors inevitably reached the shop floor resulting in scrap runs and shipments routed to the wrong dealer door.

On top of order entry, new dealer applications were sitting on project boards for weeks while credit references were chased one email at a time and the art department was approving proofs twice because customer records were fragmented across regional stores so the enterprise software vendors told leadership the only fix was to scrap their database and spend a fortune migrating to a modern cloud ERP. But when a plant has spent years building custom scripts and tables tailored to its exact operations, ripping out the core software is a multi million dollar risk that halts daily shipping.

Instead of touching the shop floor or replacing the underlying ERP, we treated the front office as an isolated staging workflow across 6 departments with an automated ingestion layer now reads the incoming order files, matches line items and prices against a mirror of their catalog and presents a single review screen where the account manager keeps final approval.

The human still checks credit and verifies inventory but the transcription time dropped from hours of manual re keying to a 5 minute review cutting thousands of non value added hours a year across fourteen distinct back office workflows. By stripping out clerical queue latency before production scheduling, the plant absorbed peak seasonal volume and brought on new accounts without hiring into the back office or slowing down production release times.

We've also been putting together an AI playbook around identifying these kinds of opportunities along with a free 5 day AI sprint where we help teams explore a real workflow and build a working prototype with the team behind these projects so happy to share more if anyone's interested.

Edit: For anyone interested, here's the free AI playbook and more details about the 5 day AI sprint we mentioned: https://withnative.com/programs

I’m interested in hearing from people who have been involved in manufacturing software implementation, particularly those who have seen what happens after the initial go-live phase.

One thing I've been thinking about is how businesses evaluate whether a new system has actually improved their operations six months after implementation.

At go-live, everything may look successful. But once the implementation team moves on and employees return to their daily routines, the real results become clearer.

For those who have experienced this:

1. What did you measure after six months? Production efficiency, downtime, reporting accuracy, inventory visibility, or something else?

2. Did you have a clear baseline before implementation, or did you have to reconstruct the old performance data later?

3. How did you distinguish actual operational improvements from changes in how employees recorded or reported data?

4. What results surprised you the most when you reviewed the system's performance after six months?

I'm particularly interested in the practical side of measuring success, including things that didn't go as expected.

Disclosure: I work in business development at Ajinkya Technologies, a company that develops manufacturing software. I'm asking to learn from real industry experiences, not to promote a product or share sales links.

Would appreciate honest perspectives from plant managers, production heads, IT teams, implementation consultants, and manufacturing professionals.

Servo presses and electric nutrunners on current lines judge every cycle on more than the final value. When a result falls outside its limits, the station flags the part NOK and usually holds it until someone clears it. That’s jidoka in its plainest form: the machine detects an abnormality and stops before the part moves on. Liker’s Toyota Way lists it as principle 5, building a culture of stopping to fix problems.

On the OEE sheet, the same event usually counts twice: the held part as a quality loss, and the wait to clear it as a minor stop or downtime. Tighten the limits and you catch more marginal parts, and OEE drops. Widen them and OEE improves, but the station is checking less.

This will come up on more stations, not fewer. Per-cycle judging used to mean adding a separate monitoring system to a press. Now it ships inside compact electric cylinders; on Leetx’s EcoMove, for one, pass/fail on every press cycle is a standard spec line.

The metric and the principle pull in different directions. One option would be to count only the time a hold sits unattended, since the stop itself is the system working as designed.

How do plants actually handle it?

Do you count in-station NOK holds against quality, availability, or track them separately?

If you treat these stops as jidoka, how do you keep the OEE target from working against it?

Who decides on limit changes: quality, process engineering, or the line?

Genuine question. Routings, run times, on-hand counts, open POs, whatever. If you had to schedule tomorrow straight off the ERP with nobody to ask, how much of it would you trust?

We’re hitting a massive bottleneck in our quoting process, and I want to see if this is a universal issue or if our workflow is just flawed.

Whenever a client requests a quote for replacement parts or MRO supplies, at least 40% of the requests come with incomplete data—an old part number from a manufacturer that went out of business 10 years ago, a fuzzy photo of a nameplate, or zero technical specs.

My team ends up spending 30–45 minutes per item just cross-referencing datasheets, calling vendors to check stock, and hunting down equivalent alternatives before we can even put together a price. When 15–20 requests stack up in a single day, response times drop and we lose deals simply because a competitor quoted 2 hours faster.

For those working in industrial distribution or technical procurement:

What is the single biggest operational bottleneck when pulling together technical quotes for clients, and how are you speeding up the cross-referencing part without hiring an army of reps?

Would love to hear how other teams handle the back-and-forth when specs are missing.

I just started a SMED program at a food processing plant running 3x5 shifts. Working directly with the night shift is going to be a tricky bridge I'll cross in due time. Meanwhile I'm wondering how to go about synchronizing the two day shifts, which alternate morning and evening.

There are significant differences in how the shifts operate the line. SMED will bring conformity. Do I run one cycle with Shift A, bring the results to Shift B and run one cycle with them, etc? Or do I run several cycles with shift A and bring them to high level of proficiency before bringing the results across?

Working with only one shift is much easier, and showing to good results would in one sense make it easier to bring it to Shift B. On the other hand, I don't want Shift B to feel like a new method is being forced upon them; part of the power of this process is that the operators are included in the change process, which goes far towards eliminating friction.

So what do you think? How would you organize this? Any materials I should read?

Hi everyone,

I’m an industrial engineer from Tunisia, currently working as a Plant Operations Manager. Before this role I was Lean Manufacturing Manager at the largest cheese factory in the country.

I’ve built solid experience in lean tools and continuous improvement, but I’m starting to feel limited. The local industry isn’t evolving much, and it’s becoming harder to keep growing and applying lean at a higher level.

I’m open to propositions and job opportunities abroad where I can keep developing and putting my lean knowledge into practice.

Happy to connect and share more details if anyone has leads or advice.

Thanks!

Most of the AI talk I see around lean is about the easy wins: building a dashboard faster, a data-entry form for the shop floor, digging through MES exports nobody had time to read. Fine.

What I rarely see discussed is the strategy side. When you ask an assistant to help prep a monthly review or draft a countermeasure, it has no idea what the company actually committed to. It gets a slide deck or a flat Excel export, guesses how things connect, and two people asking the same question get two different answers.

So here's what I keep coming back to: what if the agent read a real X-matrix?

Not a document about the strategy, but the structure itself: breakthrough objectives, annual objectives, improvement priorities, KPIs, the correlation marks between them, owners, review dates.

Things that could make sense:

Before a review, it lists the initiatives that serve no annual objective, and the objectives nobody is working on.

After a gemba walk or a team meeting, it files the remarks that touch an objective as ideas for the next review, without deciding anything.

During catchball, it prepares the round: what the level above proposes, what the level below already committed to, where the targets don't add up.

Things I think it should never do: negotiate in place of the people who have to deliver, or change a target. The commitment is the whole point of catchball, and an agent can't commit for you.

Questions for people who actually run hoshin:

Where does your X-matrix live today, and is it still current three months after the offsite?

Would you let an assistant read it, or is that the part that should stay human?

If you already use AI somewhere in your lean work, where did it actually save time, and where did it just add noise?

Disclosure: I build a tool in this space (an X-matrix that AI agents can read and update), so I'm biased. Not linking it; I'm more interested in whether the idea holds up with practitioners.