Where is Digital Engineering Going in 2027?

Beyond Text-to-CAD: Building the AI Engineering Workbench

I recently watched someone prompt a CAD system to produce a surprisingly good design (not the one above). One response was: “Look at the size of that prompt!”

For an experienced CAD user, directly modeling that particular design may have been faster than typing the prompt. However, prompt length is not yet the most important metric. The question is whether the same specification can eventually drive geometry, analysis, manufacturing, documentation, and revisions across the product-development process.

Most engineers I encounter still use AI primarily through chat. The readers of this essay are likely further along, but even among this group, the likely future architecture remains unclear. Will the dominant pattern be copilots embedded separately in CAD, PLM, CAM, and simulation? Or will agents coordinate work across those systems?

Software development provides the best available preview. Codex and Claude Cowork are expanding from conversation and code generation into tool use, multi-step execution, documents, browsers, applications, and persistent workflows. It is clear that AI use will not stop at “just chat.”

I have heard similar arguments against new abstraction layers before. Some C programmers resisted C++ because tools such as Cfront placed another system between them and the generated C (Stroustrup’s explanation). My grandfather disliked calculators because he believed they would “cause you to stop thinking.” Those concerns were understandable, but neither technology remained limited by them. The question for engineering is not whether AI will move beyond chat, but what form it will take when it does.

Engineering Agent Evolution

It is mid-2026, and many engineers are only beginning to see more capable AI embedded in their existing tools. LinkedIn is filled with demonstrations of text-to-CAD, image-to-CAD, mesh-to-CAD, and 2D-drawing-to-CAD systems. AI capabilities are also emerging for G-code generation, physics-informed FEA and CFD models, and every PLM system is offering some RAG AI Solution.

A recent survey identified more than 70 engineering AI tools at varying stages of maturity. For readers interested in learning more about the tools available in their disciplines, the accompanying Google Sheet provides a useful starting point.

We are starting to see tools for managing engineering processes. This exists with software development already, automating the process of software specifications, planning, breaking down the work into tasks, and implementation. Design OS, “establishes the foundational design context through interactive dialogue with the designer. The command walks through three areas:

1. The design mission

2. A roadmap defining the project

3. the tech stack
   

The AI prompt remains valuable, but for serious product design, process-oriented tools are likely to become an important direction in 2027.

The Tools Are Not the Story

The table above is not intended as a market map or a comparison of engineering AI products. Its message is simpler: specialized capabilities are appearing everywhere. Some generate geometry, some predict physics, some optimize machining, some classify test data, and others search or modify PLM records. They differ substantially in maturity and technical approach, but they are already too numerous for any engineer or engineering software vendor to treat them as features of a single application.

That creates the more interesting problem. A product-development process does not remain inside CAD, CFD, CAM, or PLM. It moves through requirements, models, calculations, simulations, reviews, supplier information, manufacturing data, email, and documents. Adding an independent AI interface to every application may improve each local task, but it also creates another fragmented layer of software.

The alternative is an AI environment that remains with the engineer and uses those applications as tools.

Models, Tools, and Agents Are Different Things

Discussions of engineering AI often combine three separate components.

A model interprets language, images, geometry, or structured data. A tool performs a defined operation: creating a CAD feature, executing a solver, querying a BOM, calculating a stability lobe, or generating a report. An agent framework supplies the control loop around them. It maintains context, selects models and tools, executes operations, examines results, handles failures, asks for missing information, and continues until it reaches a stopping condition.

The model may provide much of the reasoning, but the agent framework determines how that reasoning becomes work.

These systems are not engineering platforms, but they demonstrate the architecture likely to be applied to engineering. It is also likely that one or more of these general purpose applications will be extended to particular disipline, like engineering.

The Agent Framework Becomes the Workbench

An engineering agent framework needs to do considerably more than place a chat window beside a CAD model. It must maintain the state of a project over time, understand which artifacts are authoritative, discover available capabilities, select an appropriate model or deterministic tool, manage local and remote execution, preserve results, and record why each operation occurred.

It must also coordinate the ordinary work surrounding engineering: locating specifications, reading email, searching for supplier information, creating analysis scripts, comparing results, updating presentations, and preparing change documentation. These tasks are not peripheral. They are often the connective tissue that turns an isolated calculation into a product decision.

This is why Codex and Claude are more relevant examples than individual copilots. They are evolving toward persistent work surfaces capable of operating across files, code, web services, documents and external tools. OpenAI now shares MCP configuration across its desktop, CLI and IDE Codex clients, while Anthropic makes remote connectors available across Claude, Cowork, Desktop and Claude Code and uses desktop extensions for local files, applications and processes.

The user begins with the agent and brings tools into it. That is a materially different architecture from starting a new AI relationship inside every application.

Connectivity Is Becoming a Separate Layer

This architecture works only if engineering applications expose controlled interfaces. That is why MCP and related tool protocols matter. MCP does not provide engineering intelligence or process orchestration. It standardizes how an agent discovers a capability, supplies arguments, and receives results.

There are already signs that engineering vendors recognize this separation. Autodesk’s Fusion MCP servers support external clients and divide local CAD execution from cloud product-data access. The MATLAB Agentic Toolkit exposes the same MATLAB installation and curated skills to Codex, Claude Code, Copilot, Gemini and other compatible agents. The significance is not the individual integrations. It is that engineering applications are beginning to make their capabilities available to an agent they do not necessarily own.

Once this becomes common, the engineering-software market has a new layer:

engineer → agent framework → engineering tools

The agent framework becomes the control plane. CAD, CAE, CAM, PLM and enterprise applications remain responsible for their domain behavior and authoritative data.

What happens to the CAD, CAM, and FEA “seats” that can be driven 24 hours a day, 7 days a week? This is harder to predict. Customers, I’m sure would like to run the company on only 10% of the licenses they have to pay for today. For vendors, some interesting business decisions are in front of them.

Why users will prefer a persistent agent

The value of an agent compounds with context. It learns how a team structures projects, which solver settings require review, where specifications live, which models are authoritative, how reports are formatted and which actions require approval. Recreating that context inside every application is inefficient, and keeping several independent assistants synchronized is worse.

This creates pressure toward one primary agent, or at least one agent environment, that accompanies the user across applications. Specialist agents will still exist, just as specialist software exists. But they are more likely to operate behind the primary agent than compete to become the engineer’s independent AI identity.

The important asset becomes not merely the underlying model, but the accumulated combination of project context, organizational instructions, permissions, tool connections, workflows and history. That also makes agent-host lock-in a serious issue. Tool portability through MCP does not automatically provide model portability, memory portability or process portability. A user may be able to connect the same CAD server to two agent hosts while still being unable to move the working context accumulated in the first.

Engineering Imposes Additional Constraints

A general-purpose agent framework is not sufficient by itself. Engineering requires deterministic execution, traceability, and controlled authority.

A language model may decide that a structural analysis is required, but a solver must calculate the result. It may propose a geometry change, but the CAD kernel must create valid geometry. It may recommend a component substitution, but PLM must apply configuration, effectivity, and change-control rules. The agent coordinates these systems; it does not replace their numerical or transactional authority.

Human approval also remains part of the architecture. Siemens’ Teamcenter AI BOM Agent can perform impact analysis and execute approved BOM operations, but it does so inside existing governance with human confirmation. SimScale’s engineering agents emphasize repeatable and auditable simulation execution. These are early examples of the likely pattern: increasing agent autonomy inside explicit technical and organizational boundaries.

Engineering deployment will also remain hybrid. CAD and licensed solvers may run on local workstations; proprietary models may run on internal infrastructure; simulation may use remote HPC; and PLM or supplier data may live in cloud services. The workbench must coordinate these environments without assuming that all engineering data and computation can be moved into one provider’s cloud.

Workspaces, Workbenches, and Agent Orchestration

I use Codex today and expect to develop engineering tools for the agent systems offered by OpenAI and Anthropic. If your company is committed to one of these vendors, their platforms may become strong options for managing agents within their respective ecosystems.

If your company is trying to remain flexible, OpenClaw and Hermes may be preferable options. They provide broad functionality and can be used with both proprietary and open-weight models. They integrate well with standards-based AI tools, such as MCP servers, and connect with many communication systems, including iPhone messaging, Discord, email, and approximately 40 others.

What these agent orchestrators currently lack is a specific design and manufacturing orientation. Engineering teams need AI-assisted workflows without placing every design in a single hosted system. Wright coordinates agents and deterministic tools while leaving LLM and provider selection, credentials, licenses, and host software under the operator’s control.

An Open Source Solution

Although I use Codex, I have also started extending OpenClaw and Hermes through a new plugin called Wright. Its purpose is to address the specialized needs of product design and manufacturing. It allows me to test different AI models and, as the industry releases more AI-compatible tools, provides a way to evaluate and operate them. If you are building MCP servers, Wright is open source and available here: https://github.com/burhop/wright

^{Wright Workspaces collect files, tools, and related agents}

Wright is not another specialist engineering model. It is an orchestration layer between the engineer, the agent runtime and the growing collection of engineering tools. Its current public alpha provides bring-your-own-AI configuration, agent-runtime adapters, local workspace state, an MCP tool registry and controlled actuation of deterministic CAD, CAE, CAM and calculation tools. If your company has an AI subscription, you can use it. If you want to use local models or even build you own ML models (I have one for CNC chatter and another for “text/image to sheet metal”), you can do that here.

^{Wright provides a growing list of industry MCP Servers}

The separation is deliberate. Model and provider selection belong above the engineering tools. Tool connectivity should not depend on one model vendor. Project files, artifacts and logs should remain in a workspace the operator controls. Licensed applications and local hardware should remain where they are installed. New engineering capabilities should be addable without redesigning the complete system.

Hermes currently supplies one agent runtime for Wright, including model management, memory, skills and automation. Wright supplies the engineering-specific workspace, tool connectivity and control layer around it. The adapter boundary is important because Hermes is not assumed to be the final or only possible agent runtime. OpenClaw and Codex integration are coming.

Wright is still alpha software, and it does not yet implement the complete 2027 workbench shown above. But its direction follows from the structure of the problem. If specialized engineering tools continue multiplying, the missing product is not another tool. It is a vendor system capable of selecting, combining and governing all of them.

Will Siemens, Autodesk, Dassault, PTC, and other engineering software vendors develop their own agent workbenches? I expect these workbenches to begin emerging in 2027. Major engineering software vendors are unlikely to cede the primary user interface to OpenAI or Anthropic.