AI for CAD Tools
What an outside AI agent can actually reach in CATIA and 3DEXPERIENCE, where permissions stop it, and which answers need a separate data layer.
·
⏱
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
An outside agent reaches CATIA through a session and 3DEXPERIENCE through scoped web services. The session shows geometry and parameters only for what is loaded. The web services expose the unified product structure, behind a multi-step passport login that inherits real permissions. Neither carries the reasoning, standards and history around a design. Match each question to the door that holds its answer, and add a knowledge layer for the rest.
An engineer asks an outside AI agent a plain question: which parts in the active program use this bracket, and who approved the last change? The agent has a connection to a CATIA session or a 3DEXPERIENCE tenant. Whether it can answer depends less on how clever the agent is and more on what the platform actually puts within its reach.
Dassault Systèmes offers several ways in. They are not interchangeable, and each one exposes a different slice of the data. This post lays out what an external agent can reach through the CATIA automation layer and through the 3DEXPERIENCE web services, where the access model stops it, and which questions need a separate data layer instead. It extends the four-system survey in MCP for CAD in 2026 to the Dassault side.
The short version: an agent can drive a design session or read structured product data, but it cannot read the meaning scattered across years of drawings, specs and change records through either door alone.
Two Doors Into One Platform
Most confusion starts with treating CATIA and 3DEXPERIENCE as one API. In practice an outside agent meets two different surfaces.
The first is the CATIA automation layer. It runs against an open application session, usually on a Windows workstation, and is scripted through VBA, EKL or a COM-capable language. The agent is effectively a very fast user sitting at the keyboard: it opens a document, reads parameters, edits features, and saves.
The second is the 3DEXPERIENCE platform web services. These are server-side REST endpoints that work against the platform's data, with no desktop session involved. Dassault describes the platform as open through RESTful APIs, an enterprise integration framework, and a message bus for event-driven exchange.
The two doors answer different questions. The session door is good for geometry and parameters inside one model. The server door is good for structured records such as items, lifecycle states and product structure. An agent that only has one of them will be blind to the other half of the question.
Before choosing a connection, write down the three or four questions you actually want answered and note which door each one needs. That short list usually settles the architecture faster than any vendor comparison.
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
What the CATIA Automation Layer Reaches
Through automation, an agent can see what a user with the session open can see. That includes the active document, the specification tree, named parameters and relations, sketches, and the properties of parts and products in the loaded assembly. It can also change them.
That is useful for repeatable work: renaming parameters to a convention, checking that every part in an assembly carries a required property, or generating variants from a parameter table. The best AI tools for CATIA roundup covers which tools already package this kind of work.
The limits are structural rather than accidental:
The agent only sees what is loaded. Parts that were never opened in the session are invisible to it.
It sees the model, not the reasoning behind the model. A feature tree shows what was built, not why a radius was chosen.
A write is a real edit on a real design. Without a review step, a mistaken instruction becomes a mistaken feature.
Session scripting depends on a workstation being available, licensed and running, which makes unattended use awkward.
There is also a cost in trust. Engineers will accept an agent that renames parameters correctly ten times in a row, and will stop using it after one silent mistake in a released model. Logging every action the agent takes, with the before and after values, is cheap insurance and makes reviews quick.
For read-heavy questions across many products, the session door is the slow way to ask. Opening hundreds of assemblies to find one property is exactly the job a server-side query should do.
What the 3DEXPERIENCE Web Services Reach
The server door is organised by service. As documented in public sessions on the platform's web services, the resource libraries cover 3DSpace for the engineering and CAD data held in the platform, 3DSwym for community content, 3DPassport for authentication, and a distributed file store for file handling. 3DSpace and the file store publish OpenAPI specifications, which makes them practical for an agent framework to consume.
The important detail is scope. The public REST API is described as covering the unified product structure data model, and it sits alongside other customization options such as EKL, the widget framework and the enterprise integration framework. An agent can list product structure, read item attributes, and follow relationships. It cannot assume that every custom attribute, every legacy object type, or every document's contents is exposed the same way.
Calls are JSON over standard HTTP methods. For an external application, authentication goes through 3DPassport: a login ticket, a redirect to the target service, a service-specific token for write calls, and an explicit logout. That is more steps than a typical API key, and an agent runtime has to manage the session cookies and token refresh itself.
The event side matters too. A message bus lets an outside system subscribe to platform events instead of polling, which suits an agent that should react when an item changes state rather than ask every five minutes.
Compare this with the Windchill API breakdown. The shapes differ, but the lesson is the same: the API describes the platform's data model, and the platform's data model is not the same thing as everything your company knows.
Where Authentication and Permissions Draw the Line
An agent does not get its own view of the data. It inherits whatever identity it logs in as, and the platform's access rules decide what comes back. That is the right behavior, and it has consequences worth planning for.
If the agent signs in as a service account with broad read access, it may return objects that the engineer asking would never be allowed to see. If it signs in as the individual user, it returns less, and the answer silently depends on who asked. Neither is wrong, but the choice must be deliberate. The post on what an agent returns in a PDM where not everyone can see everything works through this trade-off in detail.
Three practical rules follow:
Decide whether the agent acts as the requesting user or as a shared identity, and write the answer into the design.
Return the source object with every answer, so a person can open it and confirm access and accuracy.
Keep write access separate from read access, and keep the read path as the default.
It also helps to test with a deliberately restricted account before launch. Ask the same question as an administrator and as a contractor with narrow access, then compare the answers. Any difference should be explainable by the access rules, and any difference that is not explainable is a defect to fix before real users arrive.
None of this is specific to one vendor, but 3DEXPERIENCE makes it more visible because the passport and token handshake forces the question early. Teams that skip it tend to rediscover it during a security review.
Which Answers Need the Data Layer Instead
Go back to the opening question. Which parts use this bracket, and who approved the last change? The first half is product structure, which the web services can answer. The second half lives in change records, review notes, emails and drawings, much of it outside the platform's structured model.
This is the gap an intelligence layer on top of PDM and PLM is built to cover. Leo connects to an organization's knowledge base, including PDM, PLM, network directories and ERP, and answers with citations back to the source. It offers integrations with leading PDM and PLM platforms, and it does not replace them. The agent keeps driving the CAD session or reading structured records, while Leo supplies the context that neither door exposes: past design decisions, standards, and where a similar part was already solved.
The guide to AI tools for 3DEXPERIENCE cover the platform-native options, including what Dassault's own built-in AI does and where it stops. The pattern that holds up is a clear division of labor: automation for the model, web services for structured records, and a knowledge layer for everything written down in prose and drawings.
A quick test for any proposed agent project: for each question, name the object that holds the answer. If the object is a parameter or a feature, use the session. If it is an item or a lifecycle state, use the web services. If it is a decision, a standard or a past lesson, it needs the data layer.
FAQ
Give your CATIA agent real context
Leo connects your PDM, PLM and files into one cited answer layer.
Leo AI connects to your PDM, PLM and engineering files, then answers questions with citations back to the source. See how it fits alongside your CATIA and 3DEXPERIENCE setup.
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
