· MeshWorks Team

Why MeshWorks Is Moving Closer to CAD

We began with CSV and Excel to stay open to every design tool. Now the platform is ready for direct CAD connections.

A practical starting point

MeshWorks did not begin with a native CAD connection. That was a deliberate choice.

Manufacturing teams rarely share a single design stack. One company may use SOLIDWORKS, another may use Inventor, and another may receive design data from several customers using different systems. Building the platform around one CAD vendor would have narrowed its value before the core product was ready.

CSV and Excel gave us a common entry point. They are widely understood, easy to inspect, and available from almost every CAD and PLM system. More importantly, they allowed MeshWorks to accept engineering data without asking a company to change the tools it already trusted.

Neutral files kept the platform open

The first MeshWorks workflow treated the BOM as the contract. If a design system could produce a structured table with part numbers, descriptions, quantities and useful metadata, MeshWorks could work with it.

That approach made the platform broadly useful from the start. It also kept the engineering effort focused. Instead of maintaining several CAD extensions too early, the team could work on the parts of the product that every customer needs regardless of design software.

Those parts include revision history, project permissions, procurement status, supplier records, production planning, audit trails and the links between a BOM and the work that follows it. None of that value depends on a particular CAD brand.

The core came first

A native connection can move data quickly, but speed alone does not create a reliable manufacturing process. The receiving platform still needs to understand identity, hierarchy, revisions, ownership and intent.

MeshWorks now has much more of that foundation in place. A project can carry multiple BOM iterations. Parts can be traced through procurement and production. Teams can control who may view, change or release information. Actions can be recorded, reviewed and connected to the user or system that proposed them.

This work is less visible than a button inside a CAD ribbon, but it is what makes that button useful.

A deeper model for manufacturing software

Our view of manufacturing agents has also become clearer. An agent should not be a separate source of truth and it should not act without context. It should read the same project state as the team, prepare a specific action, explain what it found and respect the approval rules around that action.

That model needs dependable data close to the engineering source. A spreadsheet remains a valid route, but a native CAD connection can provide richer context. It can identify the active assembly, preserve parent and child relationships, read configurations and properties, collect cut list information and send a controlled project update without a manual export step.

The point is not to replace engineering judgement. The point is to reduce the distance between a design decision and the people, records and workflows affected by it.

Native CAD connections now make sense

The background work is far enough along for MeshWorks to move closer to CAD without giving up the open approach that shaped the platform.

The first connection is being developed for SOLIDWORKS. It builds on proven work around assemblies, configurable part numbering, BOM structures, weldments and cut lists. The goal is a direct and accountable route into MeshWorks, with project permissions, safe retries and a clear receipt for every accepted update.

Autodesk Inventor is planned next. It will use its own adapter because the Inventor API and host environment are different, but it will connect through the same MeshWorks contract. Authentication, project rules and server authority should not be rewritten for every CAD product.

The open route remains

CSV and Excel are not being removed or treated as a temporary compromise. They remain useful for legacy systems, customer supplied data, occasional imports and teams that do not want a native extension.

MeshWorks will support both paths. Neutral files keep the platform accessible. Native connections add depth where a team needs it. The common layer is the manufacturing record inside MeshWorks and the controlled work that can be prepared from it.

That balance matters. The platform can move closer to engineering tools while remaining open to the wider manufacturing environment around them.