Agentic CAD for Siemens NX

Agentic CAD for Siemens NX: Assistants That Look Up, Build, Check and Code

One model holding every NX tool reads too much, judges its own work and costs too much. A team of agents with clear roles works better: one plans and builds, one looks things up, one inspects geometry, one checks the result, and one writes code only when no tool fits.

This page is about the agent layer. The protocol and server layer underneath it is our Siemens NX MCP server page; a single Claude Code agent working in the NX session is our Claude NX integration; the knowledge side comes through the Vision4NX Connector. All of them belong to our family of NX AI assistants and chatbots.

Agentic CAD in Siemens NX: the short version

• What it is: an orchestrating agent that builds and changes the model, plus specialist agents that research, inspect geometry and review results. They act in the live NX session through a fixed catalogue of NXOpen tools.
• Where the knowledge comes from: a research agent that queries a knowledge base of NX, NXOpen and Teamcenter documentation and your approved internal material through an MCP connector, and returns a short answer with its sources.
• When no tool fits: a coder agent writes an NXOpen journal for the one task, tests it on a copy of the part and only then plays it back in the session as a single undo step.
• What keeps it controllable: typed tools instead of free code for normal work, one undo step per change, a readable record of what each tool touched, and confirmation where you want it.
• What it is not: text-to-CAD, a batch factory or a replacement for your designers. It executes known operations and checks them; your engineers own the design intent and sign the result.

Why one model with every NX tool is not enough

The first NX assistant most teams build is one language model with one long list of tools. It works on a demo block. On a real part it runs into three problems at once.

The first is volume. A face or edge list of a real part easily runs to tens of kilobytes, and a sheet image is larger still. The model reads it once, and from then on it travels along with every following request. The IDs in it go stale after the next edit anyway. The second is judgement: a model that has just built a drawing is a poor reviewer of that same drawing, because it checks against what it meant to do rather than against what is on the sheet. The third is cost. Every request carries the full history, the instructions and the tool catalogue, and a working session in our logs needs roughly 15 to 30 tool calls.

Splitting the work solves all three. The agent that builds is not flooded with lists and images, the agent that checks did not build the result, and the expensive model is used only where the assistant has to judge.

The roles in a multi-agent NX assistant

Five roles: an orchestrator that plans and builds, a research agent that looks things up, a geometry scout that inspects the part, a reviewer that checks the result, and a coder that writes code only when no tool fits.

The split is not fixed dogma. A project that never touches drawings needs no drawing reviewer; a project with a large standards library may need a second research agent. We explain in more detail how we split research, build, check and code across agents, and what each split costs and saves.

How an agentic CAD request runs in NX

Take a drawing request on an open 3D part: a sheet with a top view, a front view and the main dimensions. The engineer asks once; the agents do the rest in a fixed pattern.

1. Context. The assistant checks which part is open and which of your rules apply to it.
2. Plan. The orchestrator decides the sequence and the sheet format. If it is unsure how an NX command behaves, it asks the research agent instead of guessing.
3. Find the geometry. The scout finds the holes, faces and edges the next step needs.
4. Build. The orchestrator calls the build tools.
5. Check. The reviewer compares the result with your rules and reports defects and gaps.
6. Correct or hand over. The orchestrator moves, deletes or adds what the reviewer flagged, or stops and asks the engineer when the rule is unclear. The engineer sees every tool call with its arguments, result and runtime.

The same pattern works for modelling. On an existing part the scout finds the faces, the orchestrator builds the keyway, the hole or the blend, and editing an existing feature reopens it in its own builder, so the feature keeps its place in the Part Navigator. For single operations from a chat panel without the agent layer, our NX Action Assistant is the simpler fit; for drawings requested one part at a time, see the drawing and documentation assistant.

The coder fallback: an NXOpen journal when no tool fits

No tool catalogue covers everything. When the orchestrator finds that none of its tools can do what the engineer asked, it can hand the task to a coder agent instead of improvising. The coder queries the knowledge base for the right NXOpen calls and writes a journal for exactly this task.

The journal does not go straight into your session. It runs first in a headless NX against a saved copy of the part, and only if it passes is it played back in the live session, where the whole run is one undo step. Output and error messages go back to the coder, so a failed test becomes a correction, not a ticket. A walk through the prompt-to-journal part of this is in our worked prompt-to-journal example, and why unguided models invent API members is covered in AI code generation for NX Open.

Two honest notes. The coder is the newest role in our stack: it is built, and we are still validating it in live sessions, so we treat it as a fallback, not as the main path. And a journal that solves a recurring task should not stay a one-off. It becomes a reviewed, typed tool in the catalogue, which is how the catalogue grows.

NX stays responsive while the agents work

NX is busy only while a tool call executes; the assistant window stays usable while the agents think, and the designer can keep working in NX between calls. Stopping a request stops the conversation. A tool call that NX has already started runs to its end and can then be undone in NX.

Where we have built agentic CAD so far

Two current projects, both anonymised. For a DACH machine builder we are building drawing automation on this pattern: the assistant is opened on a 3D part, creates the sheet from the customer’s own title-block templates, places views and centre marks and dimensions them by rules derived from the customer’s existing drawings, and a reviewer agent checks the sheet against those rules. Sheets, views and the first dimension types work; some dimension types still fail inside the NX API and fall back to simpler ones, and tolerances and surface symbols are the hard part, which we say before the project starts.

For an Asian manufacturer, the open NX MCP server line ran a mould analysis in a live NX session on a production part: eject direction, then undercut detection through NX’s own mould tools, with the undercuts and ribs it reported matching the interactive result. The plain NX side of that task is described in our piece on NX undercut detection. An earlier, broader project of the same kind, an assistant that selects NX tools, fills in their parameters, executes and validates, is documented in our case study on hybrid agentic AI for Siemens NX.

Agentic CAD and its neighbours on this site

Several of our pages touch AI that acts in NX. They describe different layers of the same stack, and most projects use more than one of them.

What agentic CAD does not do

Agents make an assistant more capable on multi-step work. They do not make it a designer, and they do not remove the limits of NX or of the API. These are the limits we state in the first meeting.

For checks that run while a designer models, rather than on request, the event-driven live model check assistant is the better pattern.

Human confirmation and control

More agents must not mean less control. Which tools run freely and which wait for the engineer is a configuration decision per tool, made with you before the pilot, not a default we hope is right.

• Read and look-up tools run freely. Listing geometry, querying the knowledge base and taking images change nothing in the part.
• Every change is one undo step. Each changing tool sets its own visible undo mark; a whole sketch counts as one step, and a played-back journal as one step.
• Confirmation where you want it. Changing tools can require the engineer’s OK, and the coder starts only after the engineer agrees, because it may take minutes and writes new code.
• Nothing hidden. Every tool call is visible with its arguments, its result, the geometry it touched and its runtime, and every model request is logged.
• Your permissions underneath. The tools run in the engineer’s own NX session, under the engineer’s licence and data permissions.

Deployment, data and hosting options

Your part files do not leave your network for the agents to work on them. What reaches a model is what a tool returns: feature names, IDs, measurements, check results and, where you allow it, an image of a sheet or a view. The tool catalogue, the logs and the knowledge base connection run on your infrastructure; the knowledge connector is a small container that runs in your network or next to the knowledge base.

Where the models run is decided per project. Claude models are available directly from Anthropic and through cloud providers with EU regions; the assistant can also run models in Germany or on premise. Because the NX tools and the knowledge base speak MCP, the same tool layer can serve a local model when nothing may leave the building. Which roles a smaller local model carries well is something we test on your tasks before we promise it. The background on sovereign setups is in our guide to sovereign agentic AI in European manufacturing.

How we build an agentic CAD assistant with your team

Most of the effort is not in the agents. It is in the tools and the rules: which NXOpen functions already exist, where your standards live and how current they are, and which part states must never be touched. That comes first.

1. Workshop. Candidate tasks, your data and standards, hosting constraints; the result is one task to start with and a project plan.
2. Tool catalogue. Your existing NXOpen code, journals and checkers become typed tools. Read tools go live first, so the team sees the assistant understand their parts before it changes one.
3. Knowledge connection. The research agent is connected to the knowledge base with NX documentation and your approved internal material.
4. Roles and models. Which agents the task needs, which model and effort each gets, and the limits per request.
5. Rules for the reviewer. Your standards, written down or derived from reference drawings, become the reviewer’s checklist.
6. Pilot. A small group of engineers on real parts, measured on tasks completed, reviewer findings, corrections and undos.
7. Rollout. More tools, more users, and recurring coder journals turned into reviewed catalogue tools.

Start with one task in your NX

We do not start with five agents and forty tools. We start with one multi-step task your team repeats, the NXOpen code you already have for it and a part that looks like your real ones, and we add a role only when the task shows it is needed.