Ask why a bracket has that extra fillet, or why every thermal model gets a 10% margin, and the answer is often a person’s name. When that person retires, the reason leaves with them. The next engineer either repeats an old mistake or spends weeks rediscovering something the company already knew.
Dolphin has built heat transfer products for 40 years. At SimScale’s Agentic Unlocks event, Executive Director Mohammed N.J. described where that experience used to sit: “it all lies in a few people’s heads and if one of them left so did our knowledge.”
That’s tribal knowledge. Below: what it is, where it hides in an engineering team, and a five-step method for turning it into validated, traceable context that engineers and AI agents can both use.
What is tribal knowledge?
Tribal knowledge is information a team depends on but has never written down. It lives in the heads of experienced people and spreads by word of mouth, shadowing and habit. In engineering, it’s usually the reasoning behind a design: why a choice was made, what was tried first, and what failed.
Some of it is hard-won and correct. Some of it is a rule of thumb from a product line that ended 15 years ago. So capturing tribal knowledge is half the job. Checking it is the other half.
Some teams prefer “undocumented knowledge” or “expert knowledge”. The meaning is the same.
Tribal knowledge vs institutional knowledge vs tacit knowledge
These terms overlap, and the differences matter when you decide what to capture first.
| Type | What it is | Engineering example |
|---|---|---|
| Tribal knowledge | Known by a group, never written down, passed on informally | “We stopped using that seal supplier after the 2019 field failures” |
| Institutional knowledge | Everything an organization knows, documented or not | Design standards, PLM records and what senior staff remember |
| Tacit knowledge | Know-how that’s hard to put into words | Spotting a bad mesh from the shape of a contour plot |
| Explicit knowledge | Written down and shareable | A design guideline in SharePoint or a validated simulation report |
Tribal knowledge is the undocumented part of institutional knowledge. Much of it is tacit, but a surprising amount could be written down in an afternoon. Nobody had the afternoon.
Where tribal knowledge hides in engineering teams
Dolphin’s Padmanabh Nimbhorkar summed up what’s at stake: “Our intellectual property is not what we design but why we designed it that way.”
The “why” rarely sits in one place. In most engineering teams it’s spread across five kinds of record, each with a gap.
Design rationale
A drawing shows the final geometry. It doesn’t show the 3 concepts that were rejected, the test that ruled them out or the cost target that forced the compromise. That rationale is usually in an email thread, a meeting someone remembers or nowhere.
Simulation setups and results
Mesh refinement around a nozzle, the turbulence model that matched the physical test, the safety margin added because an early model under-predicted: these choices decide whether a result can be trusted. They’re rarely recorded next to the result.
The spread is bigger than most teams assume. On the Siemens and NVIDIA panel at Agentic Unlocks, Siemens described an internal study in which 5 engineers received the same CAD file and the same load case, and came back with 5 different results. The differences came from how each engineer applied loads, meshed and worked through the process.
Drawings and design guidelines
Guidelines capture the rule. Applying it well takes judgment. CoLab co-founder Jeremy Andrews put the split like this: “some fraction of that is actually kind of in the heads of your more experienced design engineers and then some fraction of that has actually been documented over time in the form of design guidelines, best practices, etc.”
RFQ and quote history
A request for quote (RFQ) draws on everything the company has built before. At Dolphin, each RFQ passes through 7 stages, and the team runs that cycle “almost 500 times in a month”. Engineers lose time asking where the file is, which tool to open and what was calculated last time. Read how Dolphin is automating RFQ responses with that record.
Manufacturing and supplier constraints
Which tolerances a supplier really holds, which draft angle the toolmaker insists on, which parts caused quality problems on the line. This knowledge sits with manufacturing engineers and long-serving suppliers, often outside the design team entirely.
Thornton Tomasetti, a structural engineering firm that’s been operating for about 70 years, described the same pattern. Jeroen Janssen, who leads its Core Studio in the UK, said the firm has “lots of knowledge within the firm … within the heads of the directors almost. So we got to get that out.”
Why tribal knowledge loss is urgent now
The people holding the most undocumented context are the ones closest to leaving:
- Tenure is concentrated in older workers. US workers aged 55 to 64 have a median tenure of 9.6 years with their employer, against 3.0 years for workers aged 25 to 34 (US Bureau of Labor Statistics, January 2026).
- About a quarter of US manufacturing workers are 55 or older (BLS, 2025 annual averages).
- Replacements are hard to find. US manufacturing could need 3.8 million new employees between 2024 and 2033, and 1.9 million of those jobs could go unfilled (Deloitte and The Manufacturing Institute).
- Few companies capture it before people go. 92% of organizations don’t consistently capture knowledge from employees about to retire (APQC, 2025).
AI adds a second deadline. An agent is only as useful as the context it can reach. Jack Sandiford, product leader at Ai Build, made the link on the closing panel: “If the worst happens and your bottleneck engineer leaves, we need to start capturing it, because that’s the context that will then help your agents to do the job correctly.”
Why wikis, exit interviews and PDM don’t keep it
The usual fixes each miss part of the problem:
- Exit interviews happen too late. An hour before someone leaves captures what they remember in an hour.
- Wikis go stale. People document the what because the why takes longer to write.
- PDM and PLM systems store revisions and released files. They rarely store the reasoning behind a revision.
There’s a deeper issue: most engineering records were never meant to be read by software. Mohammed N.J. described Dolphin’s 40-year record of drawings, spreadsheets, simulation runs and ERP data as “written by engineers for engineers. Never for a machine.” Dolphin design head Ahmed Ali said the team found its legacy records couldn’t be interpreted by a machine as written, so they restructured them line by line to train agents.
Tool sprawl makes it worse. “We digitized the work and scattered it,” Mohammed said. “That is what buying tools one at a time does.”
How to capture tribal knowledge: capture, connect, reason, govern
Dolphin’s roadmap follows 4 steps in a fixed order. “Capture, connect, reason, govern. The order is most important,” said Padmanabh Nimbhorkar. “You cannot place AI on top of scattered information and expect magic.”
The five steps below apply that order to an engineering team, with one addition specific to simulation: check a rule of thumb before you codify it.
1. Start with a record you already own
Don’t start by buying a knowledge management tool. “Do not start at the tool. Start with a record that you already own,” said Mohammed N.J. “Prove one pathway with it and build a capability to own the rest.”
Pick one workflow that runs weekly or daily, so examples build up quickly. Design reviews, drawing checks and recurring simulation types work well. Then ask where that workflow depends on one person. If a product line stops when a single engineer is on holiday, start there.
2. Capture decisions in the flow of work
Ask for the why at the moment a decision is made, while the reasoning is fresh. Design reviews, simulation reports and RFQ responses are natural capture points because the reasoning is already being discussed.
CoLab built its design review platform around this idea. “We talk with our customers a lot about the aging kind of workforce problem,” said Jeremy Andrews. “We have subject matter experts who are leaving the company and taking knowledge with them. How do we solve that problem? Well, we think a digitized design review process is actually a really good way to do that.”
Simulation can capture its own reasoning too. When Engineering AI sets up a study, it logs every action with the reasoning behind it. When a reviewer later asks why a boundary condition was chosen, the answer is on the record.
3. Validate rules of thumb before you codify them
A rule that’s wrong does more damage once it’s written down, because now it looks official. Before a rule of thumb goes into a guideline or an agent’s instructions, test it.
Simulation is the cheapest way to do that. If the team “knows” that a fin pitch is optimal or that a fillet prevents cracking, run the comparison. On a cloud-native platform you can run the variants in parallel, or set up a design of experiments to see how far the rule holds.
Validation also fixes the five-engineers-five-answers problem. Agree on one setup, prove it against test data, then encode it. Warehouse robotics company Dexory uses the SimScale agent so that simulations of its robot’s tower sections are set up the same way every time.
4. Connect rationale to the files it explains
A captured reason is only useful if someone finds it at the moment they need it. Link each decision to the artifacts it explains: the CAD revision, the simulation run, the test report, the drawing note and the quote.
Padmanabh Nimbhorkar described Dolphin’s version: “Connect means bringing CAD simulation ERP costing all other documents and historical designs into one retrievable knowledge environment.” CoLab is building integrations that pull design guidelines from PLM and SharePoint automatically, so the checks update when the guidelines do.
5. Govern: engineers approve, every output stays traceable
Captured knowledge becomes a liability if nobody owns it. Decide who can approve changes to a rule, and keep the source of every recommendation visible.
“AI can recommend, reason and accelerate but human approves. Every output remains traceable,” said Padmanabh Nimbhorkar. CoLab applies the same principle: when an engineer accepts an AI review finding, it’s logged under that engineer’s name.
From captured knowledge to AI agent context
Captured, validated and connected knowledge becomes context for AI agents. Here’s what that looks like in practice.
Custom agents carry the method. In SimScale, you build a custom agent by writing plain-language instructions, the way you’d brief a new team member, and uploading documentation such as SOPs, standards and past simulation results as its knowledge base. Every engineer in the organization can then run it. Engineering AI explained covers how these agents work.
The record produces results before any new model. In Dolphin’s first milestone, the agent reached a credible level of suggestions from the company’s records alone, before any Physics AI was added.
Simulation history becomes a shared model. Physics AI trains on your own CFD and FEA results and predicts new designs in seconds. Armin Narimanzadeh of Convion described the knowledge-sharing effect: “once any of the team members build a model, a Physics AI model, this is sharable between the team members. So when I build something, my other team members can use it.”
Firm knowledge reaches new starters. Thornton Tomasetti trains machine learning models on hundreds of thousands of analyses of simple structural members, then serves them through Cortex, its internal platform, to scripts, Rhino and Grasshopper. The goal, said Jeroen Janssen, is to put “all of the 70 or so years that the firm’s been operating into the hands of basically any colleague, anyone that comes through the door”.
The loop has to keep running. Laurence Cook, co-founder and CPO of Generative Engineering, warned on the closing panel that if an agent “isn’t actually learning from them and like improving steadily”, it “sort of stays in this like demo feeling even though you are using it in real cases.”
Done well, the payoff shows up on a new engineer’s first week. Instead of waiting for the one person who remembers, they can ask to see the last 15 versions of a part, the simulations behind them and what went wrong.
Want to see how agents use your simulation history? Explore Engineering AI or watch all sessions from the Agentic Unlocks recap.
Put your engineering record to work
Build agents that follow your instructions, standards and past simulation results, and run CFD, FEA and thermal studies in the browser.
Frequently asked questions
Tribal knowledge in engineering is the undocumented reasoning behind designs: why a material, tolerance, margin or simulation setup was chosen, and what was tried before. It lives with experienced engineers rather than in CAD, PLM or simulation records, so it’s lost when they leave.
Institutional knowledge is everything an organization knows, written down or not. Tribal knowledge is the part that was never documented and is shared informally. Much tribal knowledge is also tacit, meaning it’s hard to put into words, while explicit knowledge is already written down.
Some people find the term uncomfortable, and some organizations use alternatives such as undocumented knowledge, expert knowledge or institutional knowledge. “Tribal knowledge” is still the most widely used term in engineering and manufacturing. The concept is the same whichever term you use.
Engineers who hold it tend to have the longest tenure. In the US, workers aged 55 to 64 have a median tenure of 9.6 years, against 3.0 years for those aged 25 to 34. When they retire, teams repeat old mistakes, re-run work that already exists and onboard new engineers more slowly.
Start with one workflow that depends on that person. Capture the reasoning at the point of decision, in design reviews, simulation reports and RFQ responses. Validate rules of thumb with simulation or test data, link each decision to the files it explains, and assign an owner who approves changes.
Yes, once it’s captured in a form they can read. Agents work from instructions, standards, procedures and past results. SimScale custom agents take plain-language instructions and uploaded documentation such as SOPs and past simulation results, and Physics AI models train on a team’s own simulation data. Engineers still review and approve the output.
