AI for Engineering Knowledge Management
Meta used 50+ AI agents to capture tribal knowledge. Manufacturing faces a harder version of this problem. Here's what actually works for engineering teams.
·
⏱
9 min read
Dr. Maor Farid
Maor Farid is the Co-Founder and CEO of Leo AI, the first AI platform purpose-built for mechanical engineers. He holds a PhD in Mechanical Engineering and completed postdoctoral research at MIT as a Fulbright fellow. A Forbes 30 Under 30 honoree and former AI researcher and Mechanical Engineer in an elite military intelligence, Maor leads Leo AI's mission to transform how engineering teams design better products faster.
BOTTOM LINE
Meta proved that AI can systematically capture tribal knowledge at scale. That's a real milestone. But for hardware and manufacturing engineering, the challenge is deeper and the stakes are higher. The knowledge isn't in code. It's in decades of physical design decisions spread across disconnected systems.
The organizations that solve this problem will have a massive competitive advantage. The ones that don't will keep losing institutional knowledge every time a senior engineer retires, and they'll keep paying for it in longer ramp times, repeated mistakes, and reinvented wheels.
The good news: the technology to index, connect, and make engineering knowledge searchable already exists. Leo AI connects to your PDM, PLM, and file systems to create a searchable intelligence layer across all your institutional knowledge - no migration, no new platforms, no documentation burden on your engineers.
When Meta's Engineers Decided to Fix Their Knowledge Problem
In April 2026, Meta's engineering team published something that got the entire tech world talking. They had deployed over 50 AI agents to systematically document their internal codebase, going from 5% documentation coverage to 100%. Fifty-plus agents, crawling through code modules, interviewing engineers, and producing structured documentation that actually made sense.
It was impressive. And honestly, it was overdue. Meta had the same problem every large organization has: the people who built the systems were the only ones who understood them, and those people were slowly moving on.
But here's what caught my attention as a mechanical engineer. While the software world was celebrating Meta's breakthrough, hardware and manufacturing teams were reading that blog post and thinking: "Cool. Now try doing that with 30 years of tolerance stack-up decisions stored in one guy's head." Because that's the version of this problem we're dealing with. And it's significantly harder.
The $1.4 Trillion Problem Nobody's Solving Fast Enough
Let's put some numbers on this. Research from Valere estimates that roughly 80% of organizational knowledge is undocumented. Not filed in the wrong place. Not mislabeled. Simply never written down. It lives in the heads of experienced engineers who learned through decades of trial, error, and hard-won intuition.
Dovient's widely shared analysis pegged the economic cost of this knowledge gap at $1.4 trillion globally. That number includes wasted engineering hours, repeated design mistakes, extended ramp-up times for new hires, and the slow erosion of competitive advantage as senior people retire.
The AI knowledge management market reflects the urgency. It's projected to grow from $5.23 billion to $7.71 billion, a 47.2% compound annual growth rate. Organizations are spending because they're starting to understand that wikis, SharePoint folders, and "ask Dave in Building 3" are not knowledge management strategies. They're liabilities.
And manufacturing feels this pain more acutely than almost any other sector. When a senior software engineer at Meta leaves, the code is still there. You can read it. You can run it. You can trace the logic. When a senior mechanical engineer at a defense contractor retires, they take with them the reason behind a specific fillet radius on a bracket that prevents stress cracking under thermal cycling. That rationale doesn't live in the CAD file. It doesn't live in the PDM system. It lived in their experience, and now it's gone.
IN PRACTICE
Engineers can get to the right information much faster and spend more of their time actually designing and solving problems. It helps improve efficiency, reduces unnecessary repetition, and makes it easier to build on existing knowledge instead of starting from scratch each time.
Elad H., CEO
What Meta Actually Did (And Why It Matters)
Credit where it's due. Meta's approach was smart. Rather than asking engineers to write documentation (which decades of experience tells us they won't do), Meta built AI agents that could read the code, infer purpose, identify dependencies, and generate documentation automatically. Engineers then reviewed and corrected the output instead of writing from scratch.
This is the right pattern. Don't ask humans to create documentation. Let AI create it, and ask humans to verify it. The cognitive load is completely different. Reviewing is easier than writing. Always has been.
Meta's agents also cross-referenced different modules, identified undocumented dependencies, and flagged areas where tribal knowledge was most concentrated (meaning only one or two people understood a particular system). That last part is key. Knowing where your knowledge gaps are is almost as valuable as filling them.
But here's where the software-to-hardware translation breaks down. Software tribal knowledge is ultimately about code. The artifacts are text files. The relationships are function calls and data flows. An AI agent can parse all of that. Hardware tribal knowledge is about physical reality. It's about why a particular aluminum alloy was chosen for a heat sink in 2014 after three failed prototypes with copper. It's about the supplier who can hold 0.002" tolerance on that bore but only if you order before Q3. It's about the interaction between a housing design and the injection molding tool that already exists on the shop floor.
That kind of knowledge spans CAD files, PDM metadata, email threads, procurement records, test reports, and a thousand informal conversations that never made it into any system. Capturing it requires something fundamentally different from what Meta built.
Why Hardware Engineering's Tribal Knowledge Problem Is Harder
Software documentation, at its core, explains what code does. Hardware documentation has to explain why physical decisions were made, across multiple interconnected domains. Consider what a typical undocumented design decision actually involves:
Material selection isn't just picking from a database. It's knowing that a specific grade of stainless steel was chosen because the casting vendor in Shenzhen had quality issues with 316L batches in 2019, so the team switched to 304 for that product line. That context matters, and it's almost never recorded.
Tolerance decisions come from experience with specific manufacturing processes at specific suppliers. An engineer who's been working with a particular CNC shop for 15 years knows exactly what tolerances are realistic for that shop's equipment. That knowledge dies with the relationship.
Design-for-manufacturing trade-offs are especially vulnerable. The reason a part has a specific draft angle, the reason a weld joint was moved 3mm from the original position, the reason a particular assembly sequence was chosen over a simpler-looking alternative - these decisions often reflect hard lessons from production failures that nobody documented because they were too busy fixing the problem.
Industry data suggests that effective knowledge capture can reduce new technician ramp time from 5 years to 1.5 years. That's not a marginal improvement. That's the difference between a new hire being productive in their first year versus spending half a decade asking questions and making avoidable mistakes.
The retirement wave makes this urgent. The average age of skilled manufacturing workers continues to climb. Every month, more institutional knowledge walks out the door. And unlike software, where the next generation can at least read the source code, hardware engineers inheriting legacy designs often have nothing to work with except the geometry itself.
What Actually Works for Engineering Knowledge Capture
So if wikis don't work and Meta's code-crawling agents don't translate to hardware, what does?
The answer is building an AI layer that sits on top of the systems where engineering knowledge already lives. Not asking engineers to document what they know in some new system. Instead, making the knowledge that's already scattered across PDM systems, PLM platforms, local directories, network drives, and ERP systems searchable, connected, and accessible through natural language.
This is the approach that's actually gaining traction in manufacturing. Instead of creating documentation from scratch, you index the decisions that are already embedded in your existing data. Every CAD file revision tells a story. Every BOM change reflects a trade-off. Every ECO captures a lesson learned. The problem was never that the knowledge didn't exist in any form. The problem was that it was fragmented across systems that don't talk to each other, buried in formats that aren't searchable, and disconnected from context.
When an engineer can ask a plain-language question like "What material did we use for the thermal interface on the Gen 2 power module, and why did we change it from Gen 1?" and get an answer pulled from the actual design history, with references to the test reports and ECOs that drove the change - that's tribal knowledge capture that actually works. No wiki required.
As one enterprise defense engineering team put it: "Leo surfaces previous design decisions and calculations without needing to track down a senior engineer." That single capability - eliminating the dependency on tracking down the one person who remembers - is what separates real knowledge capture from documentation theater.
From Knowledge Hoarding to Knowledge Sharing (Without the Pain)
The biggest obstacle to knowledge management has never been technology. It's been the ask. "Please document everything you know" is an unreasonable request. Engineers became engineers because they like solving problems, not writing about how they solved them last time.
Meta understood this when they used AI to generate documentation and asked engineers to review it. The same principle applies to hardware, but the implementation has to account for the messier, more distributed nature of engineering data.
The organizations getting this right share a few characteristics. First, they're not asking engineers to change their workflow. The knowledge capture happens passively, by indexing the data engineers already produce in the systems they already use. Second, they're making the captured knowledge immediately useful. When a new engineer can find answers in minutes instead of days, the entire team sees the value and buys in. Third, they're protecting intellectual property in the process - SOC-2 certification, GDPR compliance, no training on customer data. For defense and aerospace companies, this isn't optional.
"For a team our size with years of legacy NX data, that's a significant time saver. We've started reusing parts we didn't even know we had, and that has real downstream impact on procurement and BOM costs." That's a verified user at an enterprise defense and space company. The knowledge was already in their system. They just couldn't find it before.
FAQ
Capture Your Team's Knowledge Now
Stop losing decades of engineering expertise when senior team members leave.
Leo AI indexes your PDM, PLM, and file systems to make your entire organization's engineering knowledge searchable. No migration. No documentation burden. Just answers.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
Capture Your Team's Knowledge Now
Stop losing decades of engineering expertise when senior team members leave.
Leo AI indexes your PDM, PLM, and file systems to make your entire organization's engineering knowledge searchable. No migration. No documentation burden. Just answers.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams