AI for CAD Tools
What an AI agent can and cannot read from a STEP file: geometry survives, design intent and properties often do not. A guide for engineering teams.
·
⏱
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
A STEP file gives an AI agent the shape of a part and little of the intent behind it. Geometry questions such as size, hole patterns and similarity are answerable and often answered well. Questions about material, tolerance, revision or why a feature exists need the PDM or PLM record and the released drawing. Treat the file as one source, ask the agent to separate measured from inferred, and connect the surrounding records before relying on the answer.
A STEP file looks like the safest thing in engineering. It opens in every CAD system, it survives supplier handoffs, and it is the format people reach for when a native file will not travel. So when a team points an AI agent at a folder of STEP files, the natural assumption is that the agent now sees the part.
It sees the geometry. It does not see most of what the original designer knew. The translator that wrote the file made a series of decisions about what to carry across, and an agent can only read what was written. This post walks through what a STEP file holds, what usually gets dropped on export, what an agent can still recover, and where it needs the records around the file to answer honestly. For the same question about a different neutral format, see our piece on JT files and what an AI agent gets from them.
What a STEP file actually contains
STEP is the common name for ISO 10303, a family of standards for exchanging product data. A STEP file is plain text. It lists entities and the references between them: points, curves, surfaces, faces that bound a solid, and the solid itself. The standard calls this a boundary representation, usually shortened to B-rep.
Each standard flavor, called an application protocol, decides what else may ride along. The older protocols focus on geometry and basic product structure. Newer ones add room for product and manufacturing information, which means tolerances and annotations attached to the model in a form software can read. Whether any of that appears in a given file depends on two things: the protocol the exporter chose and the options the person ticked at export time.
That second point matters more than it sounds. Two engineers exporting the same part from the same CAD system can produce files with different contents. An agent reading both will give different answers, and neither answer is wrong. It is reporting what is in the file in front of it.
Beyond shape, a STEP file usually keeps a few practical things. Units are stated, so a part exported in millimeters is not misread as inches. Product names and the assembly hierarchy often come through, which lets a reader see that a gearbox contains a housing, two shafts and a cover. Colors and layers may appear. What these fields hold is whatever the source system happened to put in them, so a part named "Part1" in the original arrives as "Part1" in the file, and no agent can repair that.
File size is a clue too. A STEP file that is unusually small for a complex part may have been exported as a simplified shell, and one that is huge may contain thousands of tiny faces from a curved model. An agent that reports basic file statistics first gives the reader a way to judge how far to trust the rest.
IN PRACTICE
Leo uses a Large Mechanical Model trained on 1M+ technical sources. It also provides citations, so we don't have to guess whether a material property or tolerance is correct. We see 96% accuracy on technical queries.
- Dorian G., AI Engineer
What the translator drops
The biggest loss is design intent. A native part carries a feature tree: the sketch, the extrude, the fillet radius set to a named parameter, the hole pattern driven by a count. A STEP file normally carries the result of that tree, not the tree. The fillet becomes a set of faces. The parameter name is gone, and so is the reason the radius was chosen.
Several other things are commonly lost or weakened:
Custom properties such as material callouts, revision letters, supplier part numbers and cost fields, unless the export maps them explicitly.
Configurations and design tables, since the file holds one resolved state of the model.
Geometric dimensioning and tolerancing, which survives as semantic data only when the protocol and the export settings both support it. Otherwise it is a picture or nothing.
Assembly mates and constraints, leaving components placed in space without the relationships that explain why they sit there.
Surface quality, because curved faces may be approximated when the receiving system cannot represent the original surface type.
None of this is a defect in STEP. It is the price of a format meant to move shape between systems that model things differently. The problem starts when a downstream tool, human or AI, treats the file as if it were the original.
What an agent can still recover from the geometry
There is real information in the B-rep, and a capable agent can pull a lot from it. Overall envelope and volume are direct readings. Hole diameters and depths can be measured from cylindrical faces. Fillet radii can be read from toroidal or cylindrical blends. Planar faces and their orientation reveal likely machining setups. Counting components in an assembly gives a first-pass BOM structure when the product tree survived.
The agent is doing feature recognition here, not feature reading. It infers a hole from a cylinder and a fillet from a blend. That works well on clean prismatic parts and gets shaky on organic surfaces, where one designed feature may be split into many faces. A good answer from an agent should say which of its findings were measured and which were inferred.
Comparing parts is a strong use. Two STEP files of similar brackets can be checked for matching envelopes, hole patterns and volumes, which is how teams find a standard part they already own instead of designing a new one. We cover how agents reach geometry in native systems in our comparison of CAD MCP servers and the SolidWorks MCP access guide. A native connection can expose the feature tree that a STEP export cannot.
Assemblies add another layer. When the product structure survives, an agent can count instances, spot repeated components, and flag a part that appears in several places. That is useful for a quick sanity check on a supplier package. It cannot tell the agent whether two identical-looking parts are the same released item or two revisions, because the revision lives in the record and not in the faces.
Teams often ask whether the agent can estimate manufacturability from a STEP file alone. It can flag obvious concerns, such as a very deep narrow pocket, a thin wall, or an internal corner with no radius. It cannot judge whether the design meets a drawing note or a customer specification, because those live outside the file.
Where the agent needs the record around the file
Most of what the translator dropped still exists somewhere. The material and revision live in the PDM or PLM record. The tolerances live on the released drawing. The reason for a fillet lives in a change order or a design review note. An agent that reads only the STEP file cannot reach any of it, so it either says nothing or guesses.
The fix is to connect geometry to the record. Leo is an AI assistant for mechanical engineers that connects to an organization's knowledge base, including PDM, PLM, local and network directories and ERP. It offers integrations with leading PDM and PLM platforms, such as SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM, and others. It works as an intelligence layer on top of those systems, so a question about a STEP file can be answered with the revision, the drawing note and the cited standard, not only the shape. Leo is SOC-2 certified, GDPR compliant, and does not train on customer data.
This is the same pattern we describe for product memory in PLM and for AI agents working across PLM data: the model of the part is one input, and the record of decisions is the other.
Consider a common case. A buyer receives a STEP file from a supplier and asks which material the part is specified in, and whether the flatness callout was met on the last lot. The file answers neither. The material is in the PDM record, and the flatness callout sits on the released drawing and the inspection report. An agent connected to those sources can answer with citations, while an agent limited to the STEP file has to report that the information is not present.
A checklist before pointing an agent at translated files
A few habits make the difference between an agent that helps and one that sounds confident while reading an empty file.
Record which application protocol and export options produced each file, and store that note next to the file.
Decide up front which properties must survive, such as material, revision and part number, and confirm they appear in a sample export.
Ask the agent to label every finding as measured, inferred, or not available in the file.
Keep the released drawing and the PDM record linked to the STEP file so the agent can cite them.
Test with a part whose answer you already know, such as a known hole count or a known tolerance, before trusting results on the rest.
Teams that do this stop asking whether the agent understands STEP. They ask whether the file holds the answer, which is the right question.
FAQ
Ask your STEP files real questions
Leo reads CAD geometry and the records around it, with cited sources.
Leo is an AI assistant for mechanical engineers, connected to your PDM, PLM and file directories. Book a demo to see it work on your own translated models.
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
