AI for CAD Tools
Solid Edge's API reaches a lot through a licensed session. See what an AI agent can read, what it can change and what the seat keeps.
·
⏱
8 min read
Michelle Ben-David
Michelle Ben-David is a mechanical engineer and Technion graduate. She served in an IDF elite technology and intelligence unit, where she developed multidisciplinary systems integrating mechanics, electronics, and advanced algorithms. Her engineering background spans robotics, medical devices, and automotive systems.
BOTTOM LINE
Solid Edge's API gives a program real reach into parts, sheet metal, assemblies and drafts, but through a running licensed session. File property libraries give cheaper read access to saved metadata, including without Solid Edge running, and none of these routes understand shape or live unsaved state. The PDM or PLM layer decides which revision an agent sees and who may see it. Scope in that order: saved properties first, live-session questions second, managed data third, geometry as its own track. Test against answers you already know before promising anything wider.
Ask a Solid Edge team what an AI agent could do with its models and you tend to hear two answers. One says the agent can reach everything, because Solid Edge has a programming interface that covers parts, assemblies and drawings. The other says it can reach almost nothing, because the files sit behind a licensed desktop seat. Both are partly right.
This post separates three things that often get blurred together: what the Solid Edge API hands to a program, what can be read from the files without a running session, and what stays inside the seat however the connection is built. If you are scoping an agent project for a Solid Edge team, knowing where those lines fall decides what you promise and what you test first.
We covered the wider picture in our comparison of what four CAD systems expose over MCP, and a close relative of this question in what Autodesk Inventor exposes to an AI agent. Solid Edge has its own shape, so it deserves its own read.
What the Solid Edge API actually reaches
Siemens describes the Solid Edge API as a way to read and manipulate data in the Part, Sheet Metal, Assembly and Draft environments. It exposes the objects and features behind 3D models, 2D drawings and their associated text and data. Programs can be written in VB.Net, C#, C++ and Python, and Siemens positions the API as part of its Solid Edge OEM toolkit for companies that build their own applications on top of the product.
In practice that means a program can open a document, walk its features, read dimensions and variables, list the parts in an assembly and pull a bill of materials. A published Siemens example uses .NET languages to extract a BOM to Excel automatically. That is the kind of job an agent can be given too, as long as the agent calls a program that does the work and reports back.
The important phrase is that the program acts on Solid Edge. The API is an interface to the application, so the reach of an agent is the reach of the object model and no wider. If a question is about something the object model does not expose, no amount of clever prompting changes that. For a view of how this plays out in another system, our piece on what an MCP server can actually drive in SolidWorks draws the same line from the other side.
It also helps to separate reading from writing. Read calls, such as listing parts or collecting dimensions, are low risk and easy to verify. Write calls change a model that someone may be relying on, so most teams start an agent project with read-only access and add edits later, behind review, once the read answers have been checked against known results.
IN PRACTICE
Leo uses a Large Mechanical Model trained on 1M+ technical sources. It also provides citations, so we don't have to guess whether a material property or tolerance is correct. We see 96% accuracy on technical queries.
- Dorian G., AI Engineer
What an agent can read without opening the model
Not every question needs a live session. Siemens documents more than one route to file properties, and they differ in what they require. The framework library works when Solid Edge is running and the file is open. The Revision Manager, also known as Design Manager, library can be referenced on its own and still gives access to file properties. A third library, the file properties library, is meant for programs that only need to read or modify properties, and Siemens states that the document need not be open in Solid Edge, nor Solid Edge be running.
Properties are grouped into six sets: summary information, extended summary information, document summary information, project information, version history and custom. Part numbers, descriptions, authors, revision fields and custom properties usually live there. For a large share of everyday questions, such as which assemblies carry a given material property or which files have no part number, that is enough.
This matters for cost and for scale. Reading properties from files is far cheaper than launching a seat per document. An agent that indexes properties across a share can answer broad questions quickly, and it can do so without consuming interactive sessions. What it cannot do is tell you what the part looks like, whether the model rebuilds cleanly, or whether two parts with different numbers are the same shape. Those answers need either the object model in a live session or an index built from the geometry itself.
Treat the properties route as a snapshot of the saved state. If someone has unsaved edits in an open session, the file on disk does not know about them, and an agent reading the file will report the older state.
What the seat keeps
Several things stay inside the desktop session whatever you build around it, and a project plan should name them early.
The license. Driving the application through its API needs an installed, licensed Solid Edge and a running session. An agent connected that way inherits the seat's availability, its performance and its queue of one user.
Live state. An open session holds unsaved changes, active configurations and display state that no file on disk records. Two agents, one reading a live session and one reading the saved file, can give different and equally honest answers.
Geometry meaning. The object model gives you features, dimensions and faces. It does not tell you that a bracket resembles another bracket you already own, which is a similarity question and needs geometry-aware indexing.
Interactive work. Selecting, sketching and judging fit in context are things the user does at the screen. An agent can prepare data for those steps, but it should not be promised the steps themselves.
None of this is a flaw to be fixed. It is the boundary of the interface, and good scoping simply respects it. Our overview of what works and what does not when applying AI to Solid Edge covers the same boundary from the user's side.
Where the PDM and PLM layer sits
Many Solid Edge teams do not keep files on a shared drive. They keep them in a PDM or PLM system, and that layer changes the access picture more than the CAD API does. The managed system knows which revision is released, which is in work, who may see it and which assemblies use which parts. A file copied out of it is only a copy.
An agent that reads a local workspace sees whatever was cached there, including superseded revisions. An agent connected through the managed layer, or through something that respects its permissions, sees the released state and can cite it. Settle that choice in a security review before rollout, not after the first surprising answer.
This is also where an intelligence layer on top of existing systems earns its place. Leo offers integrations with leading PDM and PLM platforms (SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM, and others), so engineers can ask questions across released parts, drawings and past decisions and get answers with a source they can check, while the CAD seat stays where it is. The vault remains the system of record and the agent becomes a faster way to ask it questions.
How to scope a Solid Edge agent project
Before anyone writes a connector, answer a short list of questions in this order. Each one narrows what the project can promise.
Which questions are about saved properties and structure? Start there, because they need no session and can be tested against files where you already know the answers.
Which questions need a live session? List them separately and count how many seats that implies. Many teams find the list is shorter than expected.
Where do released files live? If a PDM or PLM system holds them, connect through it or through a permission-aware layer rather than a file share.
Which questions are about shape? Plan for geometry indexing as its own workstream, separate from the API.
What does a correct answer look like? Pick a few dozen assemblies, record the true answers and compare before widening the scope.
If you are still choosing tools, our look at AI tools for Solid Edge in 2026 sets the options side by side. The scoping questions above apply whichever one you pick.
FAQ
See what Leo finds in Solid Edge data
Search parts, drawings and past decisions with cited answers.
Leo connects to your PDM and PLM and answers engineering questions from your own released data, with a source you can check.
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
