Who Will Control AI-Native Engineering?

The decisive contest may not be over the geometry kernel. It may be over the system that interprets engineering intent, plans the work, commands CAD and simulation tools, and explains the result.

For most of the history of computer-aided engineering, the center of gravity was obvious. The engineer worked inside a CAD, CAM, CAE, or PLM application. The application owned the user interface, the model state, the commands, and usually the commercial relationship. Other systems orbited it.

Foundation models are beginning to disturb that arrangement. An engineer can increasingly describe an objective rather than select a command: reduce the mass of a bracket without changing its mounting interfaces; create a family of connector variants; investigate why a housing fails its thermal requirement; update the drawing, bill of materials, and change record after the design is approved. The model can interpret the request, inspect multiple systems, formulate a plan, invoke tools, evaluate results, and return a recommendation.

The strategically important question is therefore not simply whether artificial intelligence can generate geometry. It is which system receives the engineer’s intent first. That system can decide what context to retrieve, which tools to invoke, which alternatives to consider, how to validate the work, and how the result is presented. It becomes the control plane for engineering.

For established vendors such as Siemens, Autodesk, PTC, and Dassault Systèmes, this shift creates opportunity and risk in roughly equal measure. Their applications contain decades of geometric capability, product semantics, workflow knowledge, and customer trust. Yet a foundation-model interface could sit above those applications, turning them into powerful but less visible execution engines. The kernel would still matter. The question is whether the kernel—or the agent directing it—owns the user relationship.

The primary interface is beginning to move

Traditional CAD automation starts with a command. A user or script asks the system to create a sketch, extrude a profile, place a component, generate a toolpath, or run an analysis. The application knows exactly what the command means, but relatively little about the larger purpose behind it.

An engineering agent reverses that relationship. It begins with an objective and works downward. It may need to translate a natural-language requirement into dimensions, identify affected parts, select modeling operations, consult company standards, run simulation, compare alternatives, and prepare a controlled change. The value shifts from executing one operation correctly to coordinating an entire chain of operations coherently.

This is not merely a conversational user interface on top of existing menus. The meaningful change is the emergence of a system that can maintain context and make decisions across applications. A chat window that answers help questions is a feature. A system that reads a live assembly, modifies native features, launches a solver, interprets the results, updates PLM, and asks for approval before release is a new operating layer.

The strategic prize is not “text to CAD.” It is control of the path from engineering intent to verified product decision.

What an AI-CAD control plane actually controls

The term control plane is useful because it separates decision-making from execution. In computing infrastructure, the control plane determines what should happen; lower-level systems perform the work. Applied to engineering, the control plane would interpret goals, assemble context, create plans, dispatch operations, monitor results, and manage approvals. CAD kernels, solvers, CAM engines, PLM repositories, and enterprise systems would remain indispensable execution and record-keeping systems.

A simplified AI-native engineering stack

This layer would have substantial commercial power. It could influence which solver is selected, which CAD service executes a task, which design alternative is shown, and which data becomes part of the model’s working context. It could also accumulate a rich history of engineering intentions and decisions—information potentially more valuable than the final geometry by itself.

The control plane does not eliminate the need for exact geometry. A plausible-looking mesh cannot replace a constrained, regenerable model carrying material, tolerance, manufacturing, and configuration information. Microsoft Research makes this distinction explicit in its overview of AI for parametric CAD: engineering needs exact dimensions, editable construction logic, and outputs that can participate in downstream processes. But the system that owns those representations does not necessarily have to own the engineer’s top-level interface.

Four competing strategies are now visible

The major AI companies are not entering engineering through the same door. Their different approaches reveal the layers at which the emerging market can be controlled.

Microsoft: the model learns the construction sequence

Microsoft has assembled the clearest public program in mechanical CAD-native foundation models. FlexCAD supports controllable generation over structured CAD operations. CADFusion translates text into CAD construction sequences while using visual feedback during training. CAD-Editor localizes the part of a construction sequence affected by a text instruction and infills an edited sequence. Subsequent work such as CADMorph adds a plan-generate-verify loop.

The significance is architectural. These projects treat the feature history as something like a program: sketches and operations are instructions, parameters are variables, dependencies define execution order, and regeneration tests whether the program remains valid. If this approach matures, an AI system may reason directly about construction intent rather than merely manipulate a CAD user interface.

Microsoft’s commercial route is less direct because it does not own a major mechanical CAD authoring system. Its production influence instead runs through partners such as Siemens. Microsoft and Siemens have connected their AI work to NX X, Teamcenter, industrial copilots, and customer workflows. Microsoft can therefore supply models and cloud infrastructure while a CAD vendor supplies trusted execution and engineering context.

Anthropic: the model learns to operate the system

Anthropic is pursuing a different abstraction. Its Model Context Protocol gives models standardized connections to tools and data. At launch, MCP was generic; CAD was not a central official example. That changed when Anthropic and Autodesk introduced an official Fusion connector for Claude.

Autodesk describes the integration in explicitly engineering terms: Fusion exposes model context, geometry, constraints, and actions to Claude. The agent can inspect designs, run scripts, modify geometry, query parameters, and export engineering formats. Autodesk’s own assessment is appropriately measured. Its June 2026 guidance says the connector is useful for model interrogation, automation, reporting, bulk edits, and simple parametric creation, while complex text-driven geometry is not yet dependable enough for routine production.

That limitation does not weaken the strategic signal. Anthropic does not need to reproduce Fusion’s geometry engine if Claude can understand a goal and invoke Fusion deterministically. In this model, the CAD application remains the execution authority, but the model becomes the planning and interaction layer.

NVIDIA: connect design, simulation, and operation

NVIDIA’s strategy is broader than CAD authoring. It is building an industrial substrate spanning design exchange, visualization, physics, robotics, factories, and semiconductor design. OpenUSD provides a composable scene representation; CAD-to-USD workflows ingest assemblies and metadata; Omniverse supports collaboration and digital twins; and PhysicsNeMo supplies models and infrastructure for physics-informed engineering.

USD itself was created by Pixar, not NVIDIA. NVIDIA’s contribution is making OpenUSD central to its industrial platform and helping institutionalize the standard through the Alliance for OpenUSD. The distinction matters because OpenUSD is presently strongest as a composition, visualization, collaboration, and simulation representation. It does not automatically preserve the editable B-rep, constraints, and native feature history that define a production CAD master.

NVIDIA nevertheless has unmatched breadth. Its public partnerships connect Omniverse and AI infrastructure with Siemens, Dassault Systèmes, and PTC. In semiconductor engineering, its Design Automation Research Group, ChipNeMo, CircuitOps, MARCO, and cuLitho demonstrate a sustained program in AI-assisted EDA. NVIDIA’s route to the control plane is to make itself the computational and representational fabric through which engineering systems collaborate.

Meta: the customer may build the control plane

Meta provides perhaps the most revealing case because it is neither a traditional CAD vendor nor a commercial engineering-AI platform provider. Meta’s mechanical-CAD team has built an autonomous assistant directly into Siemens NX for Meta’s own engineers. A Siemens Realize LIVE session describes an agent that preserves live geometry context while executing CAD operations. Meta engineering lead Sudhir Rao’s public account of the system says it operates across modeling, drafting, assemblies, PCB exchange, Teamcenter queries, structural analysis, mesh generation, and bulk data tasks.

The lesson is larger than the individual feature demonstrations. A sophisticated product company may not wait for one vendor to deliver an end-to-end agent. It can assemble internal models, company knowledge, workflow recipes, and commercial engineering systems into its own control plane. If that pattern spreads, the competitive field will include not only AI labs and CAD vendors, but also large manufacturers building proprietary engineering intelligence above both.

The incumbent advantages remain formidable

It would be easy—but wrong—to conclude that a general-purpose model will simply replace the CAD application. Engineering software is difficult to displace precisely because its value extends far beyond the visible interface.

First, incumbents own exact and trusted execution. Siemens’ Designcenter portfolio, for example, connects NX and Solid Edge through Parasolid, a mature geometric modeling kernel also licensed across a wide software ecosystem. The difference between suggesting a geometric operation and executing it robustly across pathological production models is enormous. Similar depth exists throughout the major vendors’ modeling, drawing, assembly, manufacturing, and simulation systems.

Second, incumbents hold the semantic product record. A native model contains more than shape: feature dependencies, parameters, assembly relationships, product configurations, model-based definition, tolerances, materials, manufacturing setups, and links into change and release processes. PTC’s portfolio illustrates this advantage: Creo supplies structured design intent while Windchill maintains that information across the product lifecycle, and Onshape combines cloud CAD with built-in product data management. An agent without access to these semantics can produce attractive output while misunderstanding the product.

Third, vendors have workflow distribution. Engineers already work inside NX, CATIA, Creo, Fusion, Inventor, SolidWorks, Onshape, and their associated PLM environments. Vendors can insert AI at the point of work, ground it in live selection and model state, and place permissions around every action. Autodesk’s now generally available Fusion Automation API also shows how an incumbent can expose native design and manufacturing operations headlessly, at cloud scale, rather than ceding automation to an external interface.

Finally, incumbents possess trust and accountability. Engineering organizations need reproducibility, audit trails, access control, validation, long-term support, and clear responsibility when a tool changes a released product. Foundation models can supply breadth and flexible reasoning, but production engineering demands a more exact operational contract than ordinary office assistance.

The risk is disintermediation, not immediate replacement

The strongest CAD vendors are unlikely to lose their kernels, solvers, or installed bases overnight. The nearer-term risk is that they become less visible to the user. If an engineer starts every task in a foundation-model workspace, the agent may choose when and how to call the CAD system. Over time, the application could retain technical importance while surrendering control of intent, interaction, and purchasing influence.

These risks should not be overstated. Customers will resist black-box automation that compromises design integrity, intellectual property, certification, or lifecycle traceability. A foundation-model lab that lacks native design semantics may discover that controlling a CAD interface is easier than producing an engineering result that survives regeneration, review, manufacturing, and field operation.

Still, history offers a warning. A technically essential layer does not always retain the highest-value customer relationship. Databases remained indispensable when enterprise applications moved above them; operating systems remained indispensable when the browser became the primary interface. CAD systems may remain indispensable even if the engineer increasingly begins with an AI workspace.

The most likely architecture is hybrid

The choice between “CAD-native model” and “tool-operating agent” is probably temporary. A production engineering system will need both.

The model must understand engineering concepts and native representations well enough to plan sensible changes. It must know that a hole may belong to a patterned feature, that a dimension may be driven by a requirement, that changing a wall can invalidate a mold strategy, and that a mesh approximation is not interchangeable with an analytic surface. But it should not be expected to reproduce every capability of a mature geometry kernel or solver probabilistically. It should call deterministic tools for construction, regeneration, checking, simulation, and manufacturing.

The winning control plane will therefore combine three kinds of intelligence:

Under this architecture, CAD does not disappear, but its interface changes. Engineers will still need direct visual interaction for exploration, diagnosis, judgment, and approval. Yet a growing share of repetitive construction and cross-system coordination can occur headlessly. The graphical application becomes both an expert workbench and a review surface for work initiated elsewhere.

Who controls the combined system remains open. Microsoft could pair CAD-native models with vendor execution. Anthropic could make MCP the common agent interface to engineering applications. NVIDIA could make OpenUSD and Omniverse the shared environment in which design and simulation agents operate. A CAD incumbent could unite its own semantic data, automation APIs, and trusted execution into a superior vertical agent. Large engineering companies may assemble all four approaches into proprietary systems, as Meta appears to be doing.

How the industry should respond

For CAD vendors, the wrong response would be to protect the existing user interface by exposing as little as possible. If customers want agentic workflows, closed applications will invite screen automation, unofficial connectors, or replacement at the orchestration layer. The stronger response is to make the engineering system safely agent-native while retaining authority over semantics, execution, and validation.

For product-development organizations, the immediate decision is not which chatbot to buy. It is how to prepare engineering systems for controlled machine action. That means improving data quality, identifying authoritative sources, exposing stable automation interfaces, defining validation gates, and capturing the rationale behind engineering decisions. An agent cannot recover context that the organization never recorded.

Companies should also avoid binding their entire engineering-intelligence layer to one model provider. Models will change rapidly; geometry kernels, product records, and released designs live for decades. A modular architecture should allow the reasoning model to change while the company retains its engineering memory, validation procedures, and governed connections to execution systems.

For foundation-model labs, the challenge is the inverse. General reasoning and tool use are not enough. Engineering requires persistent world state, exact units, constrained representations, failure-aware planning, and verifiable actions. The lab that earns trust will be the one that treats CAD and CAE systems as authorities to be queried and checked—not merely applications to be driven.

The application will remain—but it may no longer be the front door

The geometry kernel will continue to matter. So will native design history, simulation fidelity, manufacturing knowledge, PLM governance, and the accumulated expertise inside the major engineering platforms. Nothing in today’s foundation models makes those assets obsolete.

What is becoming contestable is the layer above them. Microsoft is teaching models the language of parametric construction. Anthropic is standardizing how models connect to expert tools. NVIDIA is assembling an industrial substrate for shared design, simulation, and operation. Meta is demonstrating that a large engineering organization can build an autonomous layer across NX and its surrounding workflow.

The likely future is not one in which AI generates a shape and declares the engineering complete. It is one in which an agent interprets a goal, assembles the relevant product context, proposes and executes native operations, calls trusted solvers, evaluates alternatives, and presents evidence to an accountable engineer.

In that future, the decisive strategic asset may not be the system that can create the most geometry. It may be the system that can reliably turn intent into a verified engineering decision. The CAD vendors already own many of the ingredients. The foundation-model labs are competing to own the orchestration. The battle for AI-native engineering will be decided by which side—or which partnership—can combine both without sacrificing precision, trust, or control.