Engineering and CAD AI Agents

What Has to Be Running Before an Agent Can Act

The MCP server is a control layer, not a CAD kernel. On the SolidWorks side and on the live AutoCAD side the application itself performs every operation, which means the agent inherits that application's runtime requirements exactly. Both automation surfaces are COM based, and a COM automation server for a desktop application is registered by a running instance of that application inside a logged-in Windows session. A background service account with no interactive desktop does not get one.

Templates and support files are the second dependency, and they fail quietly rather than loudly. The agent runs under some account, and that account resolves .dwt drawing templates, .dws standards files, block libraries, SHX and TrueType fonts, plot style tables, and SolidWorks part and drawing templates through its own search paths, not through the paths a drafter has configured on a workstation. A missing font substitutes silently, a missing template either raises a dialog or falls back to a default, and a plot style table that is not on the search path changes what a PDF looks like without changing the drawing.

• SolidWorks: a licensed, installed seat on Windows and a running sldworks.exe inside an interactive session. There is no headless SolidWorks. The Document Manager API is the only piece that runs without the application, and it reads and writes document metadata, references, and configurations, not geometry.
• AutoCAD through COM and AutoLISP: the same shape, a licensed install and a running acad.exe. accoreconsole.exe executes scripts and AutoLISP without the full GUI, but it still requires the licensed install and has no graphics system, so anything depending on a view or a dialog is unavailable there.
• The headless DXF path needs neither a seat nor a GUI, because it writes the file format directly instead of driving an application.
• Network licensing adds a failure mode a local install does not have: a checkout that cannot reach the license server, or a borrowed license that expires mid run, stops automation the same way a crash does.
• PDM or vault state decides whether a file is writable at all. A file not checked out to the agent's user is read only, and the write fails after the geometry work is finished rather than before it starts.

Why a Successful API Call Is Not Proof of a Correct Edit

CAD automation APIs report the outcome of the call, not the outcome of the model. A feature creation call returns an object once the feature is in the tree, and that same feature can carry an error or a warning at the same moment. A mate can be applied successfully and still leave a component somewhere nobody wanted, because it was applied to the wrong face.

Unit handling is the most common source of edits that succeed and are wrong. The SolidWorks API works in system units, meters and radians, regardless of what the document displays, so a value passed as 5 for a 5 mm fillet asks for a 5 m fillet on a part that then fails to rebuild. AutoCAD stores unitless doubles and resolves scale at insertion through INSUNITS, so a block whose INSUNITS does not match the host drawing is rescaled on insert. That shows up as a symbol correct in shape and wrong by a factor of 25.4 or 1000.

Selection is the other one. Both applications expose identifiers that look stable and are not. Face and edge indices shift when an upstream feature changes, which is the topological naming problem, and SolidWorks exposes persistent reference IDs precisely because index based selection does not survive an edit. In AutoCAD the entity handle stored in the DWG is persistent while the ObjectId is valid only for the current session, so an agent caching ObjectIds between calls addresses the wrong object, or nothing, after a reopen. The durable pattern is selection by persistent identifier where one exists, and otherwise by geometric rule, for example the largest planar face whose normal is +Z, rather than by position in a list.

• Force a rebuild and read the error state after each modifying operation.
• Treat a null or empty return as a failure explicitly, since several calls signal failure that way rather than raising.
• Assert dimension values by querying them back from the model after setting them.
• Verify against a property the agent did not set: mass, bounding box, or a component transform after mating.
• On drawings, confirm view count and sheet size after generation, because a view that failed to place leaves a sheet that is valid and incomplete.

Failure Modes That Look Like a Hang

The most common non-crash failure is a modal dialog. Any dialog the application raises, whether a missing file prompt, a unit mismatch on insert, an unsaved changes prompt, or a license notice, blocks the automation call until something clicks it. With nobody at the console the call does not fail. It waits, and the MCP call sits there until its own timeout expires.

Some of those dialogs can be turned off before a run, and doing it explicitly beats assuming defaults. In AutoCAD, FILEDIA set to 0 makes file commands take a path on the command line instead of opening a browser, ATTDIA set to 0 prompts for block attributes at the command line rather than in a dialog, ATTREQ controls whether attribute prompting happens at all, and EXPERT suppresses several confirmation prompts by level. In SolidWorks, setting CommandInProgress tells the application that an API operation is running, and disabling the input dimension value prompt on create stops the dimension entry box appearing mid operation. None of this covers everything, since license and error dialogs are not suppressible by a system variable.

A second pattern is a busy COM server rather than a blocked one. While the application is mid command or showing a modal window, an incoming automation call is refused with RPC_E_CALL_REJECTED (0x80010001) or RPC_E_SERVERCALL_RETRYLATER (0x8001010A), which a naive client surfaces as a hard error on a call that would have succeeded a second later. The right handling is a message filter or a bounded retry with backoff, not a longer timeout. Telling a blocked run apart from a genuinely long solve, such as a large assembly rebuild, an FEA mesh, or a hatch over a complicated boundary, is what decides whether to wait or intervene.

• Blocked on a dialog: CPU near idle for the CAD process, no progress events, and a modal child window present on that process.
• Genuine solve: sustained CPU or disk activity on the CAD process, with progress events still arriving.
• Dead backend: the process is gone, or calls return "The RPC server is unavailable" (0x800706BA).
• Refused rather than dead: calls fail immediately and repeatedly with 0x8001010A while the process itself is healthy, which points at a missing message filter, not a hang.
• License blocked: the application runs, and every call fails at the same point regardless of input.

Structured Input Versus Judgment: What Decides the Fit

Fit is decided less by how repetitive a task is than by how well specified its input arrives. Any parameterized operation needs its inputs identified before it can run: which face, which layer, which value, in which units, against which template. When those arrive already structured, from a configurator, a spreadsheet, or an upstream system, the identification step is already done and the operation can be driven straight from that data.

The agent layer is aimed at the case where identification is itself the work. A specification written in prose, a marked up PDF, a legacy drawing whose layer names predate the current standard, or a request reading same as the last one but 300 mm longer all describe an operation without naming its parameters. Resolving that description into a specific set of calls, against the geometry actually present in the file, is the step with no fixed rule to encode, and it is what a natural language front end onto the same scoped tools exists to handle.

A useful test on your own workflow is whether the decision rule can be written down completely. If it can, for every case, the parameters are already known and what the agent layer contributes is sequencing, permission scoping, and a record of the run rather than interpretation. If the rule has exceptions an engineer currently settles by opening the drawing and looking, that judgment step is the part being targeted. The practical signs of input variance high enough to matter are these.

• Source files arrive from several firms, with layer names, block names, and text styles that vary by source.
• The specification arrives as prose, an email, or a marked up PDF rather than a parameter table.
• The same nominal part exists across legacy files with different feature ordering and different naming.
• Revision and titling conventions differ per customer or per project.
• The current rule has exceptions resolved by looking at the drawing rather than by lookup.

What a Standards Check Cannot Check

An AutoCAD .dws standards file defines standards for exactly four object types: layers, linetypes, text styles, and dimension styles. Everything else in a drawing falls outside its scope. Block naming, xref attachment paths, annotation scale, sheet set structure, plot configuration, and above all whether a given object sits on the right layer are not things the file can express, because a layer standard states which layers may exist and with what properties, not which geometry belongs on them.

It is also a conformance check rather than a correctness check. A drawing passes when its named styles match the standard, and that says nothing about whether the pump tag is the right tag, whether a process line runs to the right equipment, or whether a dimension measures the feature it appears to measure.

The rules that matter most in practice therefore have to be encoded outside the .dws file: object to layer mapping by entity type, block library naming, annotation scale policy, and whether xref paths are stored relative or absolute. For P&ID work the gap is wider, because the ISA 5.1 symbol set is a drawing convention and not a data model. It fixes what a symbol looks like, not what a tag means in your plant, so the P&ID data model has to be settled before an agent generates anything, and it comes down to two questions.

• The tag scheme: what the functional identifier and loop number are, whether tags are unique per drawing, per unit, or per plant area, and what allocates the next number so two drafters or two runs do not issue the same one.
• Where the attribute data lives: as block attributes inside the DWG, in an external register the drawing links to, or both, and which side wins when the two disagree.