Why AI-Powered CAD File Management Starts With the Boring PDM Problem Engineers Have Always Hated

When I left Autodesk, I had a strong gut feeling about where the industry was headed. CAD vendors, I believed, would eventually solve cloud PDM. It seemed almost inevitable. They owned the design tools and traditional PDMs. They understood files, assemblies, drawings, references, and revisions better than anyone. They had the installed base, the technical depth, and the customer relationships. The shift to cloud was accelerating. The infrastructure was catching up. It felt obvious that this convergence would produce something new – a simple, modern, cloud-native way to manage engineering data.

Guess what? It didn’t happen that way. As I look at what is happening today, I see customers still using SolidWorks PDM and Autodesk Vault, both highly successful PDM tools developed more than 25 years ago.

What happened instead was subtler and, in retrospect, more interesting. Improved internet gave a new lifetime to file-based workflows. Faster connections made it easier than ever to send CAD files over the wire, share through cloud storage, and access desktop environments remotely. The collaboration friction went down, but the data complexity did not. But the boring part, the actually difficult part, was never resolved. Files still got copied, renamed, duplicated, misplaced. References still broke. Revisions still got confused. Ownership still ended up as a social convention rather than a system fact. The internet made files easier to move. It did not make them easier to understand.

The boring PDM problem was still there.

I have been thinking about this for years. But a recent piece by Nate on “boring tools” gave me a new frame for it — and I want to use that frame to explain why OpenBOM starts its AI work from this specific and unglamorous place.

Why the “Boring” Engineering Tools Are Becoming AI Infrastructure

Nate’s article tells the story of issue trackers. He traces the genre from Bugzilla in 1998 through Jira to Linear, and makes an observation that surprised me with its clarity: the structural primitives that made issue trackers useful for human coordination — records that persist outside any individual’s memory, state machines with defined transitions, ownership as an explicit field, verbs with clear semantics, and audit history by default — turn out to be exactly what AI agents need to coordinate work reliably. He writes about how some OpenAI teams saw dramatic increases in landed pull requests by routing autonomous agents through Linear tickets, and how that only makes sense once you understand that issue trackers were always, underneath their human-facing surface, something very close to a coordination substrate.

His argument is that the boring tools won. The user interface changes. The substrate stays.

I read that and immediately thought about PDM.

Because PDM was built around the same five properties. CAD files organized into structured records, not just folders. State machines, draft, in review, released, obsolete, not just file names. Ownership as an explicit field: who is responsible for this component right now. Defined verbs with real semantics: check in, check out, revise, release, approve, supersede. And audit history by default, because in engineering, knowing what changed, when, and who authorized it is not optional.

Engineers hated the execution. The administration burden was real. The workflows were rigid. The systems were often slow, expensive to deploy, and poorly adapted to how engineers actually work. But underneath all of that friction, the underlying structure was right. PDM was encoding something that matters enormously: the product knowledge that engineering teams create every day, and that disappears without a system to hold it.

That structure is now exactly what AI needs to be useful in engineering environments. The boring primitives were not wrong. The burden placed on the human to maintain them was the problem.

What PDM Got Right About Engineering Data and Where It Failed Engineers

The case for PDM was always straightforward. Engineering teams need to know which file is up to date and how to get the history. They need to avoid overwriting each other’s work. They need to know which assembly revisions references which part or subassembly revisions, which drawing belongs to which model, how to send a specific version to manufacturing last quarter. They need to reconstruct history when something goes wrong. They need to control what leaves the engineering organization and in what state.

None of these needs are optional. They apply to teams of three and teams of three hundred. They apply whether a company uses a heavy enterprise PLM system or a shared folder on a cloud drive. Avoiding them does not eliminate the need. It just pushes the problem into uncontrolled places — into email threads, into naming conventions nobody enforces consistently, into the memory of the engineer who has been there longest.

The problem was never that PDM captured the wrong things. The problem was how it asked people to maintain them.

Traditional PDM put the coordination burden squarely on the engineer. Check-in workflows required discipline and time. Vault administration required dedicated resources. Every reference had to be explicitly managed. Every revision had to be manually created. Every release required a process. The system knew how to store information correctly, but getting information into the system was the user’s problem. When the overhead became too high, engineers routed around the system. Important decisions ended up in Slack instead of the tracker. File statuses became performative rather than accurate. Work was logged retroactively, after the fact, to satisfy a process nobody believed in.

This is the pattern Nate identifies in a different context. When people resent a tool, they route around it. The state gets dirtier. The ownership drifts. The audit trail becomes unreliable. The substrate that was supposed to hold organizational knowledge starts reflecting a fiction instead of reality.

Closed systems made this worse. Many PDM vendors built platforms that protected APIs, locked customers into proprietary environments, and made it difficult to connect engineering data with the rest of the business. Martin Eigner and others in the PLM research community have argued for years that openness is not a secondary feature of good PLM architecture — it is a foundational requirement. When systems close off, the digital thread breaks. Data accumulates inside vendor walls rather than flowing to where it is needed.

So the failure of traditional PDM was not structural. It was a burden problem and an openness problem. The right primitives were encoded in the wrong way, maintained by the wrong people, protected inside the wrong walls.

How AI Agents Can Eliminate the CAD Data Management Burden Engineers Have Always Resented

Here is what changes with AI.

Consider a moment that every SolidWorks engineer has experienced. You change the assembly or part someone else is working on and need to merge changes from multiple files located somewhere on Google Drive.  You rename an assembly. Immediately, references break. Downstream drawings point at nothing. Finding and repairing those relationships manually is tedious and it happens constantly not because engineers are careless, but because CAD data is deeply relational and the tools for managing those relationships were never designed to be effortless. Engineers can fix those issues, but it is crazy boring and annoying. 

A CAD File Agent that understands SolidWorks data structure can catch that break at the moment it happens. It can seamlessly use cloud storage, manage versions and allow you to control the lock from a conversational user interface. It knows that an assembly is not just a file. It knows that a part has references, that a drawing is connected to a model, that configurations and derived files carry their own dependencies. It can flag the affected context, identify what needs attention, and help the engineer address the problem before it propagates downstream.

This is not a futuristic scenario. It is a routine coordination problem that currently costs engineering time every day. It is boring in exactly the way Nate means — persistent, invisible, and completely unexciting to talk about. And it is a perfect candidate for assistance.

Think of it this way. Sorting files on your computer is boring. Checking whether all your drawings are current is boring. Finding which assembly depends on a part you are about to change is boring. Preparing clean data for a supplier or a manufacturing handoff is boring. None of this requires deep engineering judgment. All of it requires consistent attention and careful execution. It is exactly the kind of work that an agent can take off the engineer’s plate — not by replacing engineering decisions, but by removing the administrative friction around them.

This is the practical idea behind OpenBOM CAD File Agent. Not another heavy PDM implementation that engineers will tolerate and route around. Not a chatbot layered onto an existing interface. But a domain-aware assistant that understands the structure of SolidWorks engineering data and helps capture, organize, and maintain it as product context.

Why CAD File Management for SolidWorks Is the Right Starting Point for AI in Engineering

Some people will ask why OpenBOM AI starts from files. The answer is simple: because files are still where much of engineering work begins.

In many companies, the CAD file is the first persistent expression of product intent. It contains geometry, structure, metadata, references, drawings, and often the first version of a BOM. Even in organizations with PLM and ERP systems downstream, the engineering reality begins with CAD files and then expands outward. Ignoring files does not make engineering more digital. It pushes the problem into uncontrolled places.

This is especially true for the large number of companies – machine builders, robotics companies, industrial equipment teams, hightech, electronics, contract engineering organizations. They need practical and invisible tools that work with the reality they have. They need to capture product data from CAD without building a massive infrastructure PDM project first. The CAD File Agent starts exactly there, with the file-based reality that already exists, and turns it into structured product context that can be used and extended.

SolidWorks represents one of the largest and most practical engineering communities in the world. Many SolidWorks users work in file-based environments — some with traditional PDM, some with shared folders, some with cloud drives, many with a mixture of everything. The CAD File Agent meets them where they are and begins building product memory from the data they are already creating.

This is the first step in the OpenBOM Product Memory vision. Capture, then Review, then Flow. Capture means understanding product information where it originates — in assemblies, parts, drawings, metadata, references, revisions, and related files. Review means validating and improving that information: what is missing, what changed, what needs attention. Flow means moving clean product knowledge downstream to purchasing, manufacturing, suppliers, ERP, and service workflows.

CAD File Agent is part of the Capture layer. It starts with files because that is where a significant amount of product memory is still trapped today.

Open CAD Data Standards and AI Agents: Why PLM Cannot Be Built on Closed Systems

There is a larger question underneath all of this, and it connects back to the debate about enterprise software architecture that is happening across many industries right now.

The future of AI in engineering and manufacturing cannot be built on closed systems. When vendors protect APIs, build proprietary vaults, and force customers to move all data into a single platform before they can extract value, they are not protecting customers. They are limiting the ability to build intelligent workflows across real business environments. We are already seeing this tension in other domains — the move toward headless enterprise applications, where the interface is no longer the only entry point, and agents, automations, and APIs increasingly need to operate through data and services directly.

In PLM, this openness argument has been made clearly and consistently by researchers and practitioners including Martin Eigner, and it applies even more forcefully in the age of agents. An AI agent cannot be useful if it cannot see the state of the system. It cannot coordinate work if ownership is ambiguous. It cannot operate safely if permissions are not explicit. The infrastructure that agents need to function — structured records, defined verbs, durable state, audit history — has to be accessible, not locked away.

Our vision for CAD File Agent is built around this principle. We start with SolidWorks because it is where the need is largest and most concrete. But the agent is designed to develop skills across CAD environments, not to create another proprietary lock-in. Managing Creo data is not the same as managing SolidWorks data. Managing electronics design data introduces different structures and dependencies. Each CAD environment has its own file model, assembly logic, metadata conventions, and lifecycle patterns. The agent learns those skills specifically, and does so in a way that is transparent, extensible, and open.

The goal is not a new vault. The goal is a connected product knowledge layer — one that captures what was created, exposes the relationships within it, connects it to BOMs and downstream workflows, and makes product memory useful beyond the boundaries of any single CAD system or vendor platform.

Product Data Management Was Never Just an Overhead Problem – AI Is Finally Proving It

For decades, PDM was treated as a necessary evil. Something companies implemented when file chaos became too costly to ignore. Something engineers tolerated. Something administrators maintained. Something that was important in principle and difficult in practice.

AI does not eliminate the need for what PDM does. It changes who carries the burden of doing it.

The same records, references, ownership fields, state transitions, and audit logs that made traditional PDM feel like overhead are now the structure that makes AI assistance in engineering possible. The question is no longer whether engineering teams want more PDM screens and check-in workflows. They do not, and they should not have to. The question is whether the value PDM was trying to provide — organized product knowledge, controlled revisions, clear ownership, reliable downstream data — can be delivered without putting the full administrative weight on the engineer.

That is what we are building toward.

Every engineering team creates product memory every day, in files, assemblies, drawings, revisions, and decisions. Most of it is never captured cleanly. The CAD File Agent starts by capturing what is already there, in the environment engineers already work in, without forcing a new process on top of their existing work. That is the beginning of product intelligence, not the end.

The boring PDM problem was never really boring. It was just waiting for a better way to be solved.

Contact us if you’re interested to be on a waiting list to try CAD File Agent for SolidWorks? 

Best, Oleg 

OpenBOM CAD File Agent is available for SolidWorks users. Learn more at cadfileagent.com.