The Quiet Shift in Manufacturing Intelligence
Manufacturing has always been a knowledge-intensive industry. This is obvious to anyone who works in it and frequently invisible to anyone who does not. The popular image of manufacturing centres on physical production: machines, materials, assembly lines. The operational reality is that a substantial proportion of the value created in a manufacturing business happens before anything is produced, in the evaluation, estimation, and decision-making that determines what gets made, at what cost, and whether the margin justifies the effort.
This is the work that sits between an inbound enquiry and a dispatched quote. It involves interpreting partial information, referencing past experience, making judgment calls about feasibility and cost, and assembling structured outputs that commit the organisation to a price, a timeline, and a set of specifications. In most manufacturing operations, this work is performed by experienced engineers and relies heavily on knowledge that has never been systematically documented.
The industry is beginning to recognise that this dependency represents both a vulnerability and an opportunity. The vulnerability is well understood: when experienced people leave, their knowledge leaves with them. The opportunity is less commonly articulated, and it is worth examining in some detail.
What evaluation and costing actually involve
For manufacturers who produce custom or semi-custom products, every inbound enquiry is a reasoning exercise. The request arrives with some combination of technical specifications, engineering drawings, component lists, customer requirements, and contextual information about volumes, timelines, and quality expectations. Rarely is any of this complete. The engineer receiving the enquiry must interpret what is provided, identify what is missing, determine what additional information to request, and begin assembling a picture of what the product will require to manufacture.
This interpretive work is where experience matters most. A senior engineer looks at a set of specifications and sees implications that a less experienced colleague would miss: which process routing makes sense for this material at this tolerance, where the cost drivers will concentrate, which assumptions are safe and which require validation, and what similar jobs have taught the organisation about this type of product. These judgments are rapid, contextual, and almost entirely undocumented. They produce an evaluation or a cost sheet. They do not produce a record of the reasoning that led to it.
The evaluation then feeds into costing, where material rates, process costs, tooling requirements, finishing treatments, packaging, and margin calculations combine into a quote. Again, much of this depends on knowledge held by individuals: which suppliers offer competitive rates for specific materials, what realistic yield rates look like for particular processes, where past estimates have proven accurate and where they have consistently undershot.
The complete journey from inbound enquiry to dispatched quote can take anywhere from one day to several weeks, depending on the complexity of the product and the availability of the people who hold the relevant knowledge. In most organisations we have studied, the cycle ranges from five to fifteen days for a typical evaluation-to-costing sequence. The time is consumed partly by the complexity of the work itself and partly by the sequential dependencies: one person's output becomes another person's input, and availability gaps create queues.
The documentation problem that is not a documentation problem
The standard response to knowledge dependency in manufacturing is documentation. Capture what the experienced engineers know. Write it down. Build a knowledge base. Train the junior staff.
This approach has been attempted for decades, and it consistently underperforms expectations. The reason is structural rather than motivational. Documentation is a separate activity from the work itself. An engineer who has just completed a complex evaluation is immediately faced with the next incoming enquiry. The choice between documenting the reasoning behind the evaluation they just finished and beginning the already-overdue evaluation is not a real choice. The next enquiry wins. Every time.
Knowledge management systems, internal wikis, and process manuals all assume that documentation can be separated from work and still get done. The evidence from manufacturing operations suggests otherwise. The documentation that does get created tends to describe general principles rather than specific decisions. It captures what should happen in theory rather than what happened in practice. And it quickly becomes out of date because the operation evolves faster than anyone can update the records.
This is worth understanding clearly because it reframes the problem. The challenge is not that manufacturing engineers are unwilling to share their knowledge. The challenge is that the mechanism for sharing has always required additional effort beyond the work itself. Any solution that also requires additional effort will face the same constraint. The only approach that can work at scale is one in which the knowledge is captured as a consequence of the work being done, without requiring a separate documentation step.
What changes when the work itself becomes the capture mechanism
This is where manufacturing intelligence, as a concept, becomes interesting. Imagine an evaluation workflow where the engineer works through their normal sequence of decisions, but through a system that structures the process: organising incoming documents, asking specific questions where information is missing, recording each decision as it is made, and assembling the output from the accumulated inputs and judgments. The engineer is doing the same intellectual work they always did. The difference is that the medium through which they do it retains what it processes.
Over time, the organisation builds something it never had before: a structured, searchable record of how it evaluates and costs its products. Which process routings are selected for specific material and tolerance combinations. Where cost estimates are usually accurate, and where they consistently need correction. Which types of enquiries are straightforward, and which reveal exceptions that require senior attention? How different engineers approach similar problems, and where their judgments align or diverge.
This record grows as a byproduct of daily work. Nobody fills in a form. Nobody writes a report. Nobody maintains a wiki. Knowledge accumulates because the tool the engineer uses to do their job is the same one that captures their reasoning.
The practical consequences are worth spelling out. A junior engineer working through the same system encounters structured guidance that would otherwise take years of mentorship to develop. They can see how similar products were evaluated previously. They receive specific prompts for the decisions they need to make. They are not guessing at the sequence because the system provides the scaffolding that experience normally builds. This does not replace the development of genuine expertise, but it dramatically accelerates the period during which a newer team member can contribute meaningful work.
For the organisation, the accumulated record means that knowledge no longer resides exclusively in individuals. When someone is on leave, changes roles, or leaves the company, the reasoning they applied to hundreds of evaluations remains accessible. This is a form of operational continuity that no amount of handover documentation can replicate, because it captures what people actually did rather than what they remember having done.
The compounding nature of operational memory
There is a further dimension to this that extends beyond individual benefit. An operational memory that grows with every enquiry processed becomes, over time, a genuinely strategic asset. After a thousand evaluations, the organisation can analyse its own patterns: which product categories carry the healthiest margins, where estimation accuracy is strongest and weakest, which types of customer requirements tend to generate the most exceptions, how cycle times vary by product complexity and who is involved.
These are questions that most manufacturers can answer anecdotally. The experienced sales director knows which products are most profitable. The senior engineer knows which specifications tend to cause problems. But the answers are impressionistic rather than systematic, and they are distributed across individuals who may not communicate their observations to one another.
When the same knowledge is structured and queryable, the organisation can make operational decisions with the clarity previously unavailable. Pricing strategy can be grounded in actual cost accuracy rather than assumed accuracy. Resource allocation can reflect where engineering attention is most needed rather than where it is most loudly requested. And onboarding can be built around the reality of how the organisation works rather than on an idealised version.
Beyond manufacturing
The pattern we have described here is not unique to manufacturing, though manufacturing is where we have developed it most deeply. Any operation where experienced people make judgment-based decisions that are never systematically captured faces the same structural challenge.
In eCommerce, the knowledge that matters is often about customer behaviour: which product combinations convert, how different customer segments respond to different communication approaches, where in the purchase journey people hesitate and why. This knowledge exists in the heads of experienced merchandisers and customer service teams. It influences decisions daily. It is rarely structured in a form that new team members can access or that the organisation can analyse systematically.
In financial services, relationship managers carry a deep understanding of their clients' needs, preferences, and communication styles. When a relationship manager moves on, the institutional understanding of those clients goes with them. The CRM contains transaction histories and contact records. It does not contain the reasoning that guided the management of those relationships.
In agriculture, field teams develop localised knowledge about soil conditions, seasonal patterns, and farmer behaviour that is essential to operations and almost never captured beyond individual memory.
The underlying problem is the same in each case. Knowledge that is critical to operations is generated continuously through daily work. It is held by individuals. It is transmitted informally, if at all. And it is lost when those individuals move on. The solution, in each case, follows the same principle: design the tools people use to do their work so that the work itself becomes the capture mechanism.
A matter of timing
There is a question of when, rather than whether, manufacturing organisations will adopt this approach. The operational pressures are real and increasing: shorter demand cycles, greater product complexity, tighter margin expectations, and a demographic reality in which experienced engineers are approaching retirement faster than new ones are being trained.
Organisations that begin building operational memory now will have an accumulating advantage over those that wait. After two years of structured evaluation data, a manufacturer operates with a depth of self-knowledge that a competitor starting from scratch cannot replicate quickly, and that gap widens with every enquiry processed.
The argument here is operational, not technological. The question for manufacturing leadership is whether the knowledge their best people possess will remain accessible to the organisation after those individuals are no longer present each day. If the answer is uncertain, the time to address it is before this uncertainty becomes reality.
—
Mitochondria is an agentic AI product company based in Amsterdam, with operations in Pune. ISO 27001 certified. GDPR- and DPDP Act-compliant by architecture.