Multi-Agent NX Assistant: The Short Version
A multi-agent NX assistant splits an AI chatbot for Siemens NX into roles: an orchestrator that builds through a fixed tool catalog, a research specialist that queries NX knowledge over MCP, a checker, and a coder of last resort. inteliScience builds it so each role sees only what it needs and every change stays one undo step.
| One big chatbot | Multi-agent NX assistant | |
|---|---|---|
| Context | docs, face lists, images and chat history in one window | each role keeps its own short context; the orchestrator sees answers, not raw data |
| Checking | the builder grades its own work | a separate checker with its own instructions |
| Missing capability | the model improvises code at runtime | a coder role writes a journal, proves it, replays it as one undo step |
| Changes in NX | whatever the generated code does | typed tools, one visible undo mark per step |
The Problem: One Chatbot, Too Many Jobs
Our first NX assistant was a single model with every tool attached. It worked, but on real parts its context filled up fast. The reason was mundane: a face list of a production part is long, a knowledge-base answer drags several documentation chunks along, and a screenshot of a drawing sheet costs more than both. All of it landed in the same context window as the user’s actual request.
Three things went wrong at once. The model deciding what to build next spent its attention on raw data it would never need again. Every lookup ran on the strongest model. And the model that built a feature was asked whether the feature was right, which is like asking a designer to sign off their own drawing.
Anthropic described the same pattern for research agents in June 2025: sub-agents with their own context windows explore in parallel and condense “the most important tokens for the lead research agent”, and their multi-agent setup beat a single Claude Opus 4 agent by 90.2 percent on an internal research evaluation (Anthropic engineering blog, retrieved 30 September 2026). The same article is honest about the cost: multi-agent systems used about 15 times the tokens of a chat. So we split roles to keep contexts clean, not to make more model calls. This split is the core of how we deliver agentic CAD for Siemens NX to engineering teams.
The Architecture of a Multi-Agent NX Assistant
The model does not write NXOpen at runtime. It picks a tool from a fixed catalog, fills in parameters and reads a structured result, and every change stays one undo step.
Four Roles, Four Contexts
Each role exists because it needs a different context or different permissions. If a role had neither, we merged it back.
The orchestrator builds
The orchestrator is the only role that changes the part. It talks to the user and decides the order of work.
The research specialist keeps documents out of the way
This role queries the knowledge base and returns a short answer with sources, so documentation chunks stay out of the orchestrator’s context. The knowledge base is our Vision4NX Connector.
The scout and the checker look, the orchestrator decides
The scout handles geometry lookups and answers in a sentence, so large face lists stay out of the orchestrator’s context.
The checker reviews what the orchestrator built against the house rules. It is a second opinion with its own instructions, not an afterthought of the builder. Scout and checker are built and currently in live testing on real parts.
The coder is the last resort
Only when no tool can do what the user asks does the orchestrator hand the task to a coding agent. The coder writes a journal, proves it and replays it as one undo step.
The coder is the newest role and in live testing. Until a CAD manager has seen it behave on real parts, we would not enable it outside a pilot. Our worked NXOpen prompt-to-journal example shows that step in isolation.
This runs as a POC. What’s missing for production: role-scoped tool permissions, SSO, an audit log your CAD manager owns, and on-premise operation of the knowledge layer. We close the gap from “runs on my machine” to “runs in the engineering department”: see how we take agentic CAD for Siemens NX into production.
Narrow and Verified Beats Broad and Hopeful
The largest risk in an NX assistant is not a weak model. It is a tool that claims to do something it has never done on a real NX.
The community NX_MCP server (98 GitHub stars, 20 forks, retrieved 30 September 2026) confines file arguments to one workspace and keeps only 16 certified tools on by default while 34 older tools stay hidden behind environment flags. Its README documents a 20-run batch workflow passed on NX 2506 in August 2026. When we switched the older tools on in a fork against a live NX 2506 session, several called builder methods that this release does not have: failures with confident descriptions.
We added two tools to the certified list in our fork, circle sketching and undercut detection, only after both had run in an interactive session. Our own bridge follows the same discipline.
An error never breaks the connection or NX; it returns to the model as a tool error with a hint. That loop of plan, execute, verify and correct is the one from our hybrid agentic AI case study for Siemens NX; splitting it across roles made it easier to inspect, not different in kind.
What to Look For in a Multi-Agent NX Assistant
If you evaluate a vendor, or plan to build one yourself, these five questions separate an architecture from a demo:
- Can the model run code it just wrote? Only through a gated coder path that proves it first and replays it as one undo step.
- Is each role’s context separate? Face lists, documentation chunks and images stay with the role that needed them.
- Is the checker independent? Own instructions, same house rules as the builder.
- Is every tool verified on your NX release? A certified short list beats a long hopeful one.
- Where does the knowledge base run? On-premise means the application must be the MCP client.
Point 1 is the one we would not compromise on. For a single-agent setup, see our Claude Code NX integration; for a server other agents call, what a production-grade Siemens NX MCP server needs.
Frequently Asked Questions
What is a multi-agent NX assistant?
A multi-agent NX assistant is an AI chatbot for Siemens NX whose work is split across roles with separate contexts: an orchestrator that changes the part through typed NXOpen tools, a research specialist that queries a knowledge base over MCP, a scout for geometry lookups, a checker that reviews results, and a coder that writes journals only when no tool fits.
Multi-agent vs single agent: which is better for Siemens NX?
For short sessions on simple parts, a single agent is simpler and fine. Once sessions run to dozens of tool calls on real parts, a split pays off: the orchestrator’s context stays small and a checker with its own brief reviews the builder’s work. The cost is more model calls, so we keep the number of roles small.
How much does it cost to run a multi-agent assistant compared with one chatbot?
It depends on how often the roles are called, not how many exist. Anthropic measured multi-agent research systems at about 15 times the tokens of a chat, but that setup explores in parallel on purpose. In an NX assistant the specialists run on demand. We log usage per role and request, so each role’s cost is measured, not estimated.
Why not let the AI write NXOpen code directly?
Because generated code is where models hallucinate API calls, and unreviewed code in a live session can leave a part half-built. A fixed tool catalog does the NXOpen work; the model only selects and parameterises. When a tool is missing, a coder role writes a journal, proves it and replays it as one undo step.
Can the assistant use our own knowledge base if it runs on-premise?
Yes, if the chat application is the MCP client. The hosted MCP connector of the Claude API only reaches publicly exposed HTTP servers, so an on-premise knowledge base has to be connected by the application itself. A research specialist then holds those tools and returns answers with sources to the orchestrator.
Next Step
If your team has an NX assistant that works in demos and struggles on real parts, the split into roles is usually the fix, and the verified tool catalog is the foundation.