AI for CAD Tools
NX Open reaches a lot through a licensed session. See what an AI agent can read, what the seat keeps and where Teamcenter answers instead.
·
⏱
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
The NX Open API gives a program real reach into parts, features, expressions, assemblies and drawings, but through a licensed NX session. Journals and Knowledge Fusion rules add design-intent context where they exist. None of these routes understand shape or live unsaved state, and none can say which revision is released. Teamcenter owns release status, where-used, change history and access. Scope in that order: saved properties first, live-session questions second, managed PLM data third, geometry as its own track. Test against answers you already know before promising anything wider.
Ask an NX 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 NX has a programming interface that covers modeling, assemblies and drawings. The other says it can reach almost nothing, because the models sit behind a licensed desktop seat and a Teamcenter vault. Both answers are partly right.
This post separates three things that often get blurred together: what the NX Open API hands to a program, what a running seat holds that no file records, and which questions only Teamcenter can answer. If you are scoping an agent project for an NX team, knowing where those lines fall decides what you can promise. For the PLM side in more detail, our analysis of what the Teamcenter API gives engineering teams is a useful companion.
What the NX Open API actually reaches
NX Open is Siemens' name for the programming interfaces that sit on top of NX. Siemens describes a Common API as the shared foundation, with .NET languages such as Visual Basic .NET and C#, Java and Open C++ built on it, plus a separate Open C API for C and C++. Siemens states that the Java and Open C++ APIs support the full range of Common API capabilities.
In practice that means a program can work with the same kinds of objects an engineer works with by hand: parts, features, expressions, assemblies and components, drawings and their annotations. Siemens also documents journal recording in several languages, including Python among the choices in the reference material. A journal is a recorded, replayable script of what someone did in an interactive session, which makes it a handy way to learn what the API calls look like for a given command.
The important detail for agent work is licensing and execution. Siemens' own fact sheet says that applications built with these toolkits require individual NX feature licenses at runtime for the capabilities they use. An agent that drives NX through the API is therefore a program using a seat, with the performance, availability and license cost that implies.
It helps to think of three typical jobs. The first is reading: pull the expressions on a part, list the components in an assembly, collect attributes and report them. The second is checking: compare a dimension or an attribute against a rule and flag the exceptions. The third is changing: edit an expression, add a feature, regenerate a drawing. Reading and checking are comparatively safe to pilot. Changing is where a wrong answer becomes a wrong model, so it deserves its own review and should come last, if at all.
Siemens also notes that its Java API supports interactive, batch and remote execution. That matters for planning, because a batch or remote job does not need an engineer sitting at the seat, but it still needs a license and a place to run. Ask your NX administrator how many licenses are free overnight before you assume a nightly job is cheap.
IN PRACTICE
It integrates directly with PLM and existing workflows, making past designs, standards, and calculations instantly available. The result is fewer errors, faster decision-making, and a more consistent process across teams.
- Sergey G., Board Member
Journals, Knowledge Fusion and design intent
Two other Siemens tools matter when you ask what an agent can learn from an NX model. Journaling records interactive steps into a script that can be edited and replayed. Knowledge Fusion is described by Siemens as a fully integrated knowledge-based engineering tool that lets users extend NX with engineering rules that capture design intent.
Both are useful as evidence. A journal shows how a feature was created, and Knowledge Fusion rules show why a dimension follows from another. Neither is guaranteed to exist for any given model, and neither tells an agent whether the design is the released one. Treat them as context that sometimes helps, not as a record you can count on.
A fair test is to take ten parts your team knows well and ask what an agent can say about why each is built the way it is. Where a part carries a clean journal history or documented rules, the answers get richer. Where the model was built by someone who has since left, the agent has the geometry and the numbers but not the reasoning, and it should say so plainly instead of inventing a rationale.
Expressions deserve a mention too. Named expressions carry a lot of intent in many NX parts, and a program can read them without any guesswork about shape. If your team names expressions carefully, an agent can answer questions about driving dimensions reliably. If they are named p1, p2 and p3, the answer comes back accurate and unhelpful.
For a view from the file side, see what an agent can read out of a JT file in our JT format analysis, which covers what survives in the neutral format and what stays in the NX original.
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 NX and a running session, or a batch process that holds a license while it works. The agent inherits the seat's availability and its queue.
Live state. An open session holds unsaved changes, suppressed features, active reference sets and display state that no file on disk records. An agent reading a live session and one reading the saved part can give different and equally honest answers.
Shape understanding. Reading feature names and dimensions does not tell you that two parts are similar. Questions such as finding an existing bracket that fits a new envelope need geometry-aware indexing built from the files, which is a separate piece of work from calling the API.
Judgment. The API tells a program what a feature is. It does not tell it whether the feature was a good decision. That context lives in review notes, change history and the heads of the people who built the model.
None of this is a flaw in NX. It is the normal boundary of a desktop CAD application, and it is the same boundary you meet with other CAD seats. The practical point is to decide, question by question, whether a live session is truly needed.
One more cost is easy to miss: trust. If an agent answers from a live session and the engineer later opens the saved file to check, a mismatch teaches the engineer to distrust the agent. Making each answer state its source, whether live session, saved part or released revision, removes most of that friction before it starts.
Where Teamcenter takes over
Many NX teams do not keep files on a shared drive. They keep them in Teamcenter, and Siemens documents a managed way of running NX in which the part is opened from, and saved back to, the Teamcenter database rather than the file system. In that setup the managed layer 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.
This is where the question changes from what the NX API can read to what Teamcenter can answer. Release status, where-used queries, change history, access rules and the bill of materials all live in the PLM layer, and none of them is reliably recoverable from a single part file. 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.
Teamcenter also holds the relationships that make a part meaningful. A bracket on its own is a shape. A bracket that is used in four released assemblies, was changed under a recent change order and is restricted to one program is a decision with consequences. Those facts are what a design engineer needs before reusing or modifying it, and they are the facts a CAD API alone cannot supply.
Settle that choice in a security review before rollout. The access question is covered for the PDM case in our piece on what an agent returns when not everyone can see everything, and the same reasoning applies to a Teamcenter deployment.
How to scope an NX 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, expressions and structure? Start there, because they can be tested against parts where you already know the answers.
Which questions need a live session? List them separately and count how many seats that implies. The list is often shorter than expected.
Where do released models live? If Teamcenter holds them, connect through it, so the agent answers from released revisions and honors access rules.
Which questions are about shape? Treat geometry search as its own track with its own test set.
How will every answer be checked? Require a source the engineer can open, so a wrong answer is caught at the desk and not in the field.
If you want a view of what Siemens itself ships for NX users, our look at NX's built-in AI covers it, and AI for Siemens NX: what engineers should expect sets out the wider picture.
FAQ
See what Leo finds in NX and Teamcenter
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
