Intelligent Mechatronics: intelligence in the design process, not only the machine

1 Introduction

A machine that couples mechanics, electronics, control, and software cannot be designed one part at a time. A structure is sized to a duty; hydraulic actuation is weighed against electro-mechanics; sensing, control, and software are specified alongside the hardware rather than after it, under the standards and certification that govern the environment the machine will work in. Change one, and the others move. The reasoning that resolves those couplings is held by the engineers who have made such choices before, and very little of it is written down. Section 3.2 reconstructs one such decision in full, the choice of actuation for an offshore crane built for autonomous load handling, and sets out what no current format holds of it.

That absence is the ordinary condition of physical-systems design, and it is a large part of why artificial intelligence has not yet reached it. AI is reshaping how software is made. By company accounts, it now writes as much as 30% of the code at Microsoft and more than a quarter at Google (MIT Technology Review, 2026), and Gartner (2025) expects that by 2030, large software engineering teams will give way to smaller, AI-augmented ones. The shift is beginning to reach software design itself, not only its implementation. However, the design of the physical machines that software runs on has barely moved.

Physical systems are, in one sense, genuinely harder: their design errors are costly and often irreversible, where software can be tested and revised cheaply. This forgiving test loop is one reason why software came first, and I return to it. However, software had a second advantage, which was less noticed and with no equivalent in physical design: its design reasoning was, to an unusual degree, already written down. Decades of public code came with much of the documentation, review, and discussion around it, forming a partial but substantial corpus than an AI could learn to design from. The knowledge that conceives and sizes a physical machine has far less of such record. It is largely tacit, held by practicing engineers, spread across mechanical, electronic, control, and software domains; and where it is recorded at all, it stays in private notes and files, not in any shared corpus. This difference in what was recorded, together with the missing test loop, and not the capability of any one model, is why AI is reaching the design of software first. It also points to where the constraint moves next (Kohl and Carro, 2026): to the design of physical systems, and at the moment, the engineers who hold that knowledge are leaving the field.

In this study, I approach that constraint from within mechatronics, the engineering of physical machines and systems that integrate mechanical, electronic, control, and software components (Habib, 2007). Mechatronics has always been a design discipline: the French standard NF E 01-010 defines it as an “approach aiming at the synergistic integration of mechanics, electronics, control theory, and computer science within product design and manufacturing” (AFNOR, 2008), and the VDI 2206 guideline gives it a development methodology, the V-model (VDI/VDE, 2021). Yet, when the field speaks of intelligent mechatronics, whether in textbooks (Merzouki et al., 2013), journals, or conference proceedings, the adjective almost universally modifies the product or its behavior: intelligent control, intelligent sensing, and intelligent runtime adaptation. Intelligence, in current practice, resides in the machine—not in the making of the machine. I argue that it must also reside in the design process itself.

The making of physical machines faces real constraints in capital, fabrication capacity, and certification, but each of these is visible and actively managed. The design knowledge needed to conceive and size a new physical system is different. Parts lists and CAD drawings survive, so an old design can still be copied, but it cannot be improved or adapted to new operating conditions: that requires knowing why the design is the way it is, and that reasoning was rarely recorded. It has not been systematically captured, and research on retaining it remains scarce (Burmeister and Deller, 2016; DeLong, 2004). Roughly 70% of a system’s lifecycle cost is committed during early design, rising to approximately 85% by the end of detail design (Blanchard and Fabrycky, 2011), yet AI support in design is still in its early phases (Yüksel et al., 2023). The tools to monitor and optimize existing machines are mature; the cross-domain, AI-assisted tools to design the next generation of machines are not. The constraint this article takes up is this combination: binding and unmanaged.

The pathway to the next generation, increasingly autonomous and intelligent, runs through intelligent engineering: the systematic application of AI to the design process itself. It combines human expertise with AI capability as “co-intelligence” (Mollick, 2024) or hybrid intelligence in the research literature (Dellermann et al., 2019). Habib (2007) earlier called mechatronics itself an “intelligent engineering science;” the sense here is different, which denotes AI applied to the design process and the capture of the design knowledge it depends on. It means developing the hardware and the software in parallel from the outset, as one intelligent mechatronic system, not retrofitting intelligence after the machine has been built. A three-layer model locates the constraint: Layer 1, engineering design knowledge in a form that AI can use is the missing foundation; Layers 2 and 3, general AI reasoning and agent infrastructure are advancing rapidly (Wang et al., 2024; Osmani, 2026; Steinberger, 2025), but without Layer 1, they remain software tools that are able to orchestrate code but not design machines. The longer this knowledge stays uncodified, the more of it is lost as its holders retire.

What follows states and defends a hypothesis; it is not a survey. The scope is the design process of physical machines and the knowledge that the process runs on. The intelligence built into the product, in control, sensing, and runtime adaptation, is the field’s established subject and enters here only as the contrast that Section 2 documents. Three conditions make this the moment for the argument: reasoning models and agent infrastructure have advanced far enough to be tested on design tasks (Wang et al., 2024; Osmani, 2026), as shown by the studies in Section 3.3; the software side of engineering is being automated first, which moves the constraint to the physical side (Kohl and Carro, 2026); the engineers who hold the design knowledge that the side depends on are leaving the field, so the period in which it can still be captured from them is closing (Edwards et al., 2026). The claim is that the knowledge that the third condition threatens is what the first two are waiting for.

This article makes three contributions. First, it recasts design rationale, long treated as documentation kept for human reuse, as a precondition for AI to take part in design: the software/physical asymmetry indicates that a field admits AI into its design process to the extent that its design reasoning has been recorded. This makes the capture of that reasoning, not the capability of any model, a binding constraint on AI-assisted physical design, and the most neglected as well. This is not the design-rationale or knowledge-based-engineering agenda revisited: it differs, as Section 3.1 develops, in targeting the cross-domain coupling that no single-discipline record has held and in turning on AI agents that change the capture economics that defeated earlier efforts. Second, it grounds this in mechatronics, documenting an intelligence bias: its defining sources reserve the intelligence they invoke for the product, or for the discipline that builds it, and never for the design process. It draws together three strands usually treated apart, the automation of software, the generational turnover of the engineering workforce, and the maturation of AI agents, into one account of why the design bottleneck is shifting to physical systems just as the expertise to meet it is least secure. Third, it proposes a framework co-developing the physical machine and its intelligent twin, a three-layer model that names engineering design knowledge in a form AI can use (Layer 1) as the foundation that the stack lacks, and a four-question research agenda derived from it. The model is demonstrated through mechatronics, but its final question poses it as a claim about the design of physical systems more broadly. The contribution is conceptual, a reframing and a research program rather than an empirical study. It can be stated as a hypothesis: the capture of cross-domain design rationale, in a form an AI agent can reason over, is a binding constraint on the AI-assisted design of physical systems, and the most neglected of the constraints that bind it. Section 4 sets out what would falsify that hypothesis and a weaker, nearer-term test that could put it in doubt sooner.

The article proceeds as follows. Section 2 documents the intelligence bias and the design-knowledge crisis. Section 3 develops the framework, the three-layer model, and the crane example and positions the argument against the recent reviews of the field. Section 4 sets out the research agenda and the conditions under which it would fail. Section 5 discusses safety and reliability, followed by the implications, and then concludes.

2 Intelligence in mechatronics: product vs process

2.1 The intelligence bias

Across the field’s defining sources, where “intelligent” appears at all, it attaches to the machine or to the discipline that builds it, never to the process that designs it. The founding editorial of the joint IEEE/ASME Transactions on Mechatronics defines the field as the “synergetic integration of mechanical engineering with electronic and intelligent computer control in the design and manufacturing of industrial products and processes” (Harashima et al., 1996). The definition places the discipline in design and manufacturing, yet the word intelligent attaches to the control: it is a property of one subsystem within the product, not of the design process. The French standard NF E 01-010, by contrast, emphasizes mechatronics as a design approach, yet the word intelligent does not appear in the definition itself (AFNOR, 2008). The VDI 2206 guideline provides a V-model for developing mechatronic products but makes no provision for intelligence in the development methodology (VDI/VDE, 2021).

To check whether this placement is representative rather than selective, I classified the field’s defining sources by where the intelligence that each invokes sits: in the product and its control, in the design process, or absent (Table 1). I fixed the selection rule in advance: the field’s founding editorial, definitional standard, and guideline documents; the monograph and overview literature that uses “intelligent” in its title; the canonical design-method text; the scope statements of the field’s journals; and the most recent methods that survey and AI-in-mechatronics review. I classified each source from its own definitional wording; the classification is mine alone, and each entry can be checked against the source. Reviews of particular AI methods in mechatronic design, such as Zeman et al. (2026) and Nüßgen et al. (2024), characterize applications rather than the field, and are discussed in Section 3.4 rather than coded here. Because the coding is a definitional reading of published wording rather than an interpretive content analysis, a single coder is appropriate, and the table is fully auditable. I report it as a structured illustration of a uniform pattern, not as a statistical finding. Of the 12 sources, four use the term in neither their product nor their process definition. Of the remaining eight, seven place the intelligence they invoke in the product or its control, and the eighth attaches it to the discipline itself, none in the design process.

TABLE 1. How “intelligent” is placed across the defining sources of mechatronics.

Classification: does the intelligence a source invokes modify the product and its control, the design process, or is it absent? None places it in the design process. Sources marked “Absent” do not use the term in their definitional or methodological content; they are listed for completeness and are not counted as evidence of the bias.

The rule bounds the table: the wider literature examined for this article, including further journals and conference series that carry “intelligent” in their names, shows the same placement. Design research more broadly has long brought computation into the design process itself, from the Intelligent CAD programs of the 1980s (Zou et al., 2024) through computational design synthesis (Chakrabarti et al., 2011). The audit here is deliberately narrower, of how mechatronics defines itself, and its own documents have not made that move.

The research literature does the same. The textbook Intelligent Mechatronic Systems (Merzouki et al., 2013), one of the few monographs to use “intelligent” in its title, focuses on model-based control, fault detection, and diagnosis. An overview of “state-of-the-art intelligent mechatronics” (Harashima and Suzuki, 2010) addresses human–machine interaction and advanced control. A survey of digital engineering methods used in mechatronic design (Gerschütz et al., 2023) finds data-driven methods applied as point solutions within the development phases, with their integration into practice not yet widespread and cross-domain links hardly researched. The field’s publication venues point the same way: the scope of the IEEE/ASME Transactions on Mechatronics asks for “significant new knowledge needed to implement intelligent mechatronics systems” (IEEE/ASME, 2026), with the intelligence again in the system being implemented. The International Journal of Artificial Intelligence and Mechatronics defines its scope as “the design of machines with advanced intelligent behavior” (IJAIM, 2026): even where design enters the scope, the intelligence sits in the machine. The field’s flagship journal Mechatronics asks for solutions that combine mechanical, electrical, and control engineering with “data engineering and AI for intelligent machines or robotic systems” (Elsevier, 2026); AI enters as a constituent of the machine. A recent comprehensive review of AI in mechatronic systems surveys machine learning across robotics, manufacturing, and digital twins and frames AI as enhancing perception, control, and adaptation in the product, without addressing the design process (Al Ghazo and Salah, 2026). The sample is not exhaustive, but it spans the field’s most-cited anchors, and the direction is uniform.

This gap has received little attention. Within mechatronics, AI enhances automation in mechanical, electrical, and control subsystems, but co-optimization across these domains remains largely manual (Gerschütz et al., 2023). The search for a suitable design still relies mostly on the intuition and the experience of the designer, often leading to overly conservative solutions with limited variety, unwarranted complexity, or unnecessarily high costs (Hagen, 2020). Meanwhile, AI-assisted software engineering is accelerating (Cico et al., 2023), and generative AI is spreading through industrial workflows (Valencia-Arias et al., 2025); yet AI’s integration with physical-systems design remains limited. The canonical engineering design methodology of Pahl and Beitz (1984), still widely taught and applied, does not incorporate AI-assisted methods; the original formulation predates such tools, and later editions have not systematically integrated them (Pahl et al., 2007). The term “intelligent” has, in effect, been claimed by the control and product community; the field’s definitional documents have not claimed it for the design process itself, even where its research frontier is beginning to move that way (Section 3.4). The process still runs almost entirely on human expertise. How secure is that expertise?

2.2 The design knowledge crisis

The answer is already visible in the numbers. Despite decades of better tools, new-product-development success rates are largely unchanged (Knudsen et al., 2023), while the Draghi report warns that an aging, shrinking workforce is undermining European growth (Draghi, 2024), and national AI strategies, Norway’s included, still emphasize software-centric digitalization over the expertise to design new physical systems (Norwegian Ministry of Local Government and Modernisation, 2020). In Norway, the engineering competence gap has come early: STEM fields are only 16% of bachelor’s graduates against an OECD average of 23% (OECD, 2025), and 72% of firms report unmet engineering and technical competence, the highest share of any field (Furholt and Børing, 2025). The industrial base in which such expertise is built is correspondingly thin: manufacturing is approximately 6% of GDP against an EU average near 14% (Eurostat, 2024).

In sectors such as offshore oil and gas, where I worked as a systems engineer before moving to research, much of the heavy-duty machinery, subsea systems, and drilling equipment in operation today originates from designs developed in the decades when these industries were scaling. Since then, the focus has shifted toward operations, condition monitoring, control system upgrades, and incremental modifications, while hiring has tilted toward software and digitalization roles. Industry demand shapes education: students train for the jobs that employers advertise, reinforcing the shift away from physical-systems design. The original design expertise was never systematically transferred, and it cannot easily be imported: designing machinery for harsh offshore environments requires knowledge of local conditions, regulations, and operational practices. Other mature heavy industries, from aerospace to nuclear power, face a similar transition from active design to life extension and operational management, with the knowledge-loss risk that entails (DeLong, 2004). The need has not gone away: DNV forecasts demand for ocean space to grow nine-fold by mid-century, 82% of it for offshore wind, including approximately 45,000 km² of floating wind farms (DNV, 2021). Energy-transition infrastructure and autonomous marine and offshore systems are new machines, not life-extended ones, and they need exactly the cross-domain design capability that is thinning.

The gap, therefore, widens from both sides: the demand for new machines meets a shrinking population of engineers able to design them. The pattern is not confined to Norway: an aging engineering workforce and a documented “knowledge exodus” are reported across the United States, Japan, and Germany (PwC, 2023; Seike, 2005; Mitani, 2008; VDI and IW, 2026). Training more engineers is necessary but does not by itself close this gap: the integrative design knowledge at issue takes decades to build, so those who hold it tend to leave faster than replacements can acquire it. Better tools alone have not helped either, as the flat product-development success rates noted above indicate. The leverage point is the knowledge itself, captured in a form that AI can use.

The knowledge at risk is not the kind that existing AI research addresses. A bibliometric review by Khalili and Jahanbakht (2026) identified 126 publications on AI-enabled tacit knowledge spanning 1985–2025. The term goes back to Polanyi (1966), 4): “we can know more than we can tell.” Judging by the applications they address, that body of work centers on operational knowledge, such as the best practices for running, maintaining, and troubleshooting existing systems. Falckenthal et al. (2025) examined intergenerational tacit knowledge transfer with a similar focus, and Fenoglio et al. (2022) proposed a tacit knowledge elicitation process for Industry 4.0 that targets operational best practices. Newer tools have not changed this: a recent review of large-language-model tacit-knowledge elicitation covers elicitation from operators on the shop floor and excludes product design from its scope altogether (Rank et al., 2025). DeLong (2004) provided the foundational analysis of knowledge loss in organizations. Little, if any, of this literature addresses the capture of tacit design knowledge for physical systems: the knowledge of how to conceive, size, and validate a new machine from requirements to a manufacturable design.

The labor-market figures establish scarcity and aging, not what specifically is being lost; recent industry evidence supplies that, supporting both the tacit character of this knowledge and the risk of losing it. In an interview study spanning large enterprises, small firms, and AI and CAD/CAE vendors, Edwards et al. (2026) found that critical design knowledge remains “in our employees’ heads” and that workforce retirement is accelerating the loss of this uncodified expertise; the study identifies that loss as a central barrier to adopting AI in engineering. The hardest part to pin down comes before any component is chosen: understanding what an application actually needs and turning that into specifications. Beyond it, the expertise needed to identify possible technologies, select topologies, set up simulation models, and evaluate control strategies for a mechatronic application exceeds what an individual design engineer typically holds (Hagen, 2020); it is cross-domain and rarely documented. The difficulty is not new: the field’s own accounts trace the absence of a shared cross-domain language and of a unified understanding of the whole system from 1989 to the present (Flening, 2025).

The opportunity to capture this knowledge is time-limited. The engineers who carry this integrative expertise, the ability to manage cross-domain integration and emergent behavior in complex systems (INCOSE, 2023), are leaving, through retirement, career changes, and industry restructuring. If their knowledge is not captured and formalized, it will not be available to the AI systems that could, in principle, reason over it.

3 The proposed framework

The core idea is that the physical twin, the hardware itself, and an intelligent twin, the software intelligence that will run it, are developed together from the start (Figure 1a). The intelligent mechatronic system is the outcome, the twins are co-developed components, and intelligent mechatronics is the methodological umbrella. Figure 1b shows what this requires: two layers of AI capability resting on a layer of knowledge. First, we take a look at why current practice falls short.

Today, making a machine “intelligent” usually means adding intelligence after the machine has already been designed and built. Sensors, condition monitoring, fault diagnosis, predictive maintenance, and health-aware control are added to machines already in operation, which is the province of asset integrity management (Ratnayake and Markeset, 2012); in many cases, these machines were never intended to support them. For the large installed base of existing machines, this is the only option, and the gains in operational efficiency are real. However, retrofitted intelligence is inherently limited. It adds system complexity, opens cybersecurity vulnerabilities, creates dependencies on external infrastructure, and cannot fix design decisions that were locked in before the machine was built. Retrofitting autonomy is the sharpest case: perception sensors and the computing they need can be added, but the structure, actuation, and control they must work through were never designed for autonomous operation.

Figure 2 contrasts this conventional approach with the proposed alternative. On the left, large teams organized in discipline-specific silos (mechanical, electrical, and hydraulic design on one side, control and software on the other) are coordinated through model-based systems engineering (MBSE), with separate workflows managed manually and intelligence added only through post-manufacturing retrofitting. MBSE coordinates the artefacts across those silos, but the reasoning that produced them is rarely recorded in the design documentation that carries them (Mirabito et al., 2024), so the handovers between departments remain sequential. On the right, intelligence is embedded from the outset: the intelligent twin, encompassing health-aware control, condition monitoring, adaptive behavior, and predictive capabilities, is generated in parallel with the hardware design. The intelligent mechatronics framework mediates between the engineer’s design inputs and both hardware and software design simultaneously, so that the intelligent twin can emerge from the same process. The exchange would run both ways: the engineer supplies inputs and judgment, and the framework returns design candidates and questions. The aim is to let smaller, cross-domain teams augmented by AI co-design hardware and software from the first specification, within the verification and certification structures that safety-critical design retains.

3.1 The three-layer model

Three things must be in place before AI can perfoem design work on physical systems; the three-layer model (Figure 1b) names them. The layering orders dependency: agents (Layer 3) invoke general reasoning (Layer 2), and both must be grounded in domain knowledge (Layer 1); nothing above functions for design without the layer below. Layer 1 is the foundation: engineering design knowledge in a form that AI can use. This includes design rules, physics-informed constraints, trade-off heuristics, domain-specific reasoning, and the ability to translate application needs into formal design specifications accounting for environmental conditions, regulatory standards, and cross-domain interactions. All of this must be captured and formalized before AI can assist with design.

Layer 1 is not monolithic. Some of it generalizes across firms, such as the physics-informed trade-offs, the topology-selection reasoning, and the heuristics a retired engineer can still pass on. Some is firm-specific, such as the proprietary criterion weights, the product histories, and the hard-won specifics a company captures and keeps in-house. The generalizable part is what a discipline-level foundation (Figure 1b) and the generalization beyond mechatronics posed in Section 4 rest on; how large it is relative to the firm-specific part is itself an open question that the program must answer. If it proves small, Layer 1 fragments into private, firm-level bases, and neither the discipline-level foundation nor the generalization would hold in the form proposed. The research program builds both, by different routes; the two share representations but differ in who owns and who shares them. This layer does not yet exist in a form complete enough to drive cross-domain AI agents.

The asymmetry from which this article is set out maps directly onto the three layers and explains why software had a complete stack first. Software’s design reasoning was never fully recorded either; computing reports its own recurring “tacit knowledge problem,” knowledge that is “real, decisive, and hard to write down” (Tschand et al., 2026). However, enough of it was written down, in commit histories, code reviews, and discussion threads, and over a substrate cheap to test and revise, for the reasoning and agent layers to gain a foothold: that partial record was software’s Layer 1. Physical-systems design has far less of such record, and its knowledge is tacit, proprietary, and spread across domains; thus, it has no comparably forgiving substrate.

That last point raises the obvious rival explanation: perhaps what held AI back in physical design is not missing rationale but missing verification. Software has a cheap, fast, and forgiving loop of compile and run that lets it be trained against its own execution; physical systems, with their slow and costly prototypes, do not. The two are not exclusive, and I do not claim capture is the only binding constraint. However, verification and capture are not equally neglected. Simulation, physics-informed models, and digital twins are advancing quickly, with funded programs assembling the datasets and benchmarks they need (de Payrebrune et al., 2025). Building those simulators is itself a form of knowledge capture, but only of the codified part: they encode the physics of Layer 1, the laws and models a candidate design can be tested against. The rationale itself, the criterion weights, their transfer to a new duty, and the propagation of one choice across domains, is not captured this way, and it is the precondition that the verification loop still needs. A simulation can test a candidate only once the design problem has been formulated, and formulating it well is itself the elicitation step this article is about. That is why I call captured design knowledge a binding constraint, and the most neglected, rather than the only one.

The need for this foundation is not new: I identified the same requirement for automated design tools in 2020, before large language models were widely available (Hagen, 2020), and return to it in the worked example below. Large language models and AI agent architectures now provide a plausible mechanism for meeting it.

Layer 1 should not be confused with existing forms of structured engineering data. Standards such as STEP AP242 encode geometry and tolerances. Simulation libraries capture component physics as reusable models. Design repositories store parametric CAD files. Engineering ontologies formalize domain vocabularies. Design-knowledge schemas go further: the design prototypes of Gero (1990) formalize function, behavior, and structure and the links between them. Each of these captures what a design is, how a component behaves, or what it is for, but none captures why a particular design was chosen. That is the trade-off reasoning, the failure-mode intuition drawn from field experience, and the judgment that makes one topology viable and another dangerous for a specific application. Layer 1 must encode this design rationale (Lee and Lai, 1991; Bracewell et al., 2009): the reasoning process itself, not just the artefacts it produces, in a form that AI agents can reason over rather than retrieve. Design research has recently made the same point: knowledge of how design work is done is a category of engineering knowledge in its own right, not reducible to knowledge of the artefact (Stacey et al., 2025).

This might appear to restate the aim of design-rationale research, which since the 1990s has sought to record why decisions were made, or of knowledge-based engineering and knowledge management, which encode design rules and organizational know-how for reuse. It shares their aim but differs in two ways. Those programs were used within single-discipline toolchains and organizations, so no captured record spanned a mechatronic choice, which couples the mechanical, electrical, control, and software decisions and must be recorded across them. In addition, their adoption stalled because a human had to formalize the knowledge exhaustively in advance, which was rarely economic (Verhagen et al., 2012); a re-evaluation a decade later found those challenges still unresolved, and roughly 90% of KBE case studies do not even report a development methodology (Kügler et al., 2023). The failure is visible in the artefacts too: an analysis of over a thousand pages of student and industry design reports found fragmented or absent rationale in nearly all of them (Mirabito et al., 2024).

An agent that can interrogate a partial, natural-language record and prompt the engineer to fill the gaps changes the economics, lowering the burden that defeated earlier capture. Evidence for this mechanism comes from interface design rather than engineering: an assistant that asks lightweight questions in situ and infers missing rationales raised the share of decisions with strong recorded explanations from 14% to 83%, without adding measured cognitive load (Son et al., 2026). Formalization cost was not the only barrier: engineers have weak incentives to record rationale whose benefit falls to others, recorded rationale can raise confidentiality and liability concerns, and rationale captured after the fact risks being incomplete, since designers may no longer recall what they deliberated upon (Horner and Atwood, 2006). The in-firm deployment required in Section 4 meets the confidentiality and liability concerns and places the benefit of capture with the firm that bears its cost; whether what is captured is complete and correct becomes a validation question for the blinded evaluation set out there. Agents change not only who reads the knowledge but what capturing it requires.

3.2 A worked example: the rationale behind one design decision

To make the argument concrete, I carry out the kind of capture it calls for. Using the question–options–criteria method (MacLean et al., 1991), a design-rationale formalism, I reconstruct the reasoning behind a real actuation decision for an offshore crane, a case I take from my own doctoral work and from developing such machines in industry because I can trace it end to end, having made the decision myself. The reconstruction earns its place twice over: it shows what Layer 1 must hold, and it incurs the capture cost that has kept such rationale undocumented at scale, which the research agenda sets out to lower. Even the easiest case carries it. Assembling the codified part, the criteria and their gradings, had taken a dedicated study (Hagen et al., 2020). Reconstructing the residue beneath one decision, 6 years on and with that study in front of me, recovered only the reasoning I could still reach. A machine embodies dozens of such decisions.

Consider designing a next-generation offshore crane for autonomous load handling, the kind of intelligent machine this reframing aims to enable: its actuation and control must deliver motion accurate enough for tasks such as active heave compensation, holding a suspended load steady against wave motion. The machine as a whole involves several coupled subsystem designs: the boom structure, its cross-section and the placement of the cylinder on it, the slew and winch systems, the boom’s actuation and control, and the autonomy stack (Hagen and Østerholt, 2026). In the terms of the method, the boom’s actuation topology is one question (Q1), and the autonomy stack four more: the perception sensors (Q2), the embedded control platform (Q3), condition monitoring (Q4), and the computing that runs the intelligent twin on board (Q5). Q1 is expanded here and stands for the rest; a working crane repeats it for each boom cylinder, the slew drive, and the winch. The single-boom laboratory crane, built to represent the main boom of a knuckle-boom crane (Hagen, 2020), isolates one instance; Figure 3 traces it there.

In my doctoral work, I set out what a computerized tool would need to design the actuation and control system for such a load-carrying application: choosing among actuator topologies (a valve-controlled cylinder, a self-contained electro-hydraulic cylinder, or an electro-mechanical cylinder) and sizing the motor, drive, screw or pump, valves, and sensors (Hagen, 2020; Hagen et al., 2020). The topology decision fixes the mechanics, the electrics, the control architecture, and the software at once. With them, it fixes the room left for the perception, health-aware control, condition monitoring, and path planning that make the crane autonomous and for the intelligent twin that ties them together. The electro-mechanical cylinder provides high drive stiffness, so a standard cascade controller on the motor’s own encoder suffices; the self-contained electro-hydraulic cylinder has low natural damping, so the design then needs an added position transducer, pressure sensors, and active-damping firmware to reach the motion performance that autonomous operation demands (Hagen et al., 2019; 2020). The hardware choice is a software choice. No single-domain format holds the reasoning that resolves it.

The criteria for this choice can be enumerated. In the 2020 study, I graded the two self-contained options against the valve-controlled baseline across 26 criteria in four categories (design, operation, safety, and application) and flagged which gradings rest on the technical literature and which on ongoing research (Hagen et al., 2020). For the autonomy stack, to my knowledge, no such inventory exists; those selections rest on the same kind of expertise, ungraded and unpublished. Some of the knowledge behind the gradings is codified: buckling sizing to a safety factor of four under DNV classification rules, cylinder dimensions to ISO, stroke and installation space against the boom geometry, and continuous power above roughly 2 kW, ruling out even the most capable heavy-duty electro-mechanical screw assembly available in 2020 (Hagen et al., 2020). Some is contextual: offshore machinery must be certified for the environment it operates in, and in my feasibility study for offshore drilling equipment, no off-the-shelf electro-mechanical actuator certified for potentially explosive atmospheres (ATEX) could be found, so a design that meets the performance requirements may still fail to comply (Hagen et al., 2017; Hagen, 2020). In addition, some is experiential: that reliability outweighs efficiency because offshore downtime is expensive. A firm may state that priority in a design-basis document, but no format holds it in machine-consumable form, linked to the choices it drives.

The gradings are a 2020 snapshot; limits move as technology develops, which is itself an argument for rationale a machine can keep current. My conclusion at the time was that such a tool must “generalize the expert knowledge held by various application designers and actuation system (component) manufacturers,” expertise that “is not typical for an individual design engineer” (Hagen, 2020). That knowledge is Layer 1. A STEP file holds the chosen cylinder’s geometry, and a simulation model holds its dynamics, but neither holds why a stiff electro-mechanical drive is wrong for a shock-loaded, certification-constrained offshore duty, nor how that one choice propagates into the sensor suite, the control software, and the intelligent twin.

In those terms, the published study supplies the design space for the actuation decision: the question, the options, and the graded criteria sit in the codified part. The autonomy stack lacks even that. Beneath both sits what I call the rationale residue: the weights that rank the criteria for a given duty, their transfer to a new application, and the propagation of one topology choice into sensing, control, and the intelligent twin (Figure 3). Even my own published inventory is, therefore, only Layer 1’s codified part; the residue beneath it is what is still missing.

The reconstruction was itself an act of rationale capture, reasoning backwards from the choice to the criteria behind it (MacLean et al., 1991). What it does not show is that an agent can yet produce such rationale unaided or reason over it reliably; captured in this form, it is what an agent would have to work from, and whether one can do either is what the research agenda takes up.

3.3 Building and using Layer 1

Layer 2 is now widely available through large language models; Layer 3 is emerging through platforms that let agents plan, execute, and iterate. Neither can design physical systems without Layer 1. The dependency is not strictly one-directional: Layer 2 also supports the construction of Layer 1, since large language models can help elicit, structure, and review captured design knowledge.

Structured knowledge can already guide autonomous agents: Anthropic’s SKILL.md format, which packages instructions as files an agent loads on demand (Anthropic, 2025), directs agent behavior, and has been adopted well beyond its origin, including by the open-source agent OpenClaw (Steinberger, 2025). NVIDIA’s NemoClaw stack extends the approach with security guardrails and models deployed privately on a firm’s own hardware (NVIDIA, 2026). Osmani (2026) described the emerging shift from “conductors” who direct a single AI tool to “orchestrators” who manage fleets of autonomous agents, arguing that this transition demands systems-level thinking. In engineering specifically, Pradas-Gómez et al. (2026) used an LLM agent to orchestrate structural-analysis tasks at an aerospace manufacturer, with the agent interpreting documented design practices while the engineer supervises; the tacit design rationale that is not documented stays beyond its reach. What is missing is the domain-specific knowledge that would allow these tools to assist with engineering design rather than software development alone.

There is early evidence that codifying expert knowledge for AI agents works. Ulan uulu et al. (2026) embedded a domain expert’s codified rules into an AI agent for generating simulation-data visualizations, reporting a 206% improvement in rated output quality over a non-codified baseline. The knowledge codified there is interpretive rather than design knowledge, but it shows that structuring expert rules for an agent measurably outperforms relying on the base model alone. That is co-intelligence in practice: human expertise and AI capability combined rather than substituted (Mollick, 2024). This is adjacent-domain support, not yet the direct test.

Wang et al. (2025c) have automated more of the design task, using a multi-agent LLM system to generate a functional prototype, a small autonomous vessel for water-quality monitoring built from off-the-shelf parts, with agents for structure, electronics, control, and software. However, their system relies on the general knowledge of the language model, not on formalized expert design knowledge, and this limits what it can do for complex industrial systems. The limit is now quantified. Massoudi and Fuge (2026) gave a nine-agent LLM system the conceptual design of a solar-powered water-filtration system, specified in a requirements document; the agents covered under a fifth of those requirements, and the physics code they generated averaged below 50% compatibility. That is Layers 2 and 3 operating without Layer 1. In a prototyping study pitting a general model against engineering students, Ege et al. (2025) found it competitive at generating concepts but prone to design fixation and unnecessary complexity, the kind of judgment failures that matter most in safety-critical, cross-domain design. Where the constraints are physical and safety is at stake, none of these approaches have yet been shown to hold up; whether they can is what the research agenda below puts to the test.

One objection is that this problem will dissolve on its own: a large enough model, trained on enough engineering data, might simply learn to design. However, the knowledge at issue is largely absent from the text that these models learn from: it is tacit and rarely in the public record. A scaling optimist might reply that models can acquire tacit skill without text, from simulation-generated data, demonstrations, or expert preference signals. That is correct, but it restates the problem. Simulation can indeed manufacture data without an engineer, but only within an already-formalized problem. Formulating that problem is itself an act of capture: it needs the criterion weights and grading rationale that no machine-consumable format holds (Figure 3). Demonstrations and preference signals are themselves forms of capture, not a way around it; and where they leave only a trained policy rather than inspectable rationale, the result cannot be audited or carried to a new duty.

Each of these routes, therefore, still requires the knowledge to be elicited from the engineer and turned into learnable data; that is what Layer 1 denotes. Section 3.4 takes up a fourth route. Whether the model then improves by scale or by fine-tuning, the binding step is capture; scale alone, over data that never contained the knowledge, does not supply it. In addition, in safety-critical physical design, a plausible-but-wrong answer cannot be patched after the fact, as it can be in software.

Two lines of defense stand behind this claim, and they should not be run together. The near-term one is empirical: given no captured knowledge, today’s agents fail the task outright, as the results above show. The deeper one is principled and sharpest where the design is certification-governed: there, the justification is part of the design task, so an artefact whose rationale cannot be inspected is an incomplete design rather than a successful one. What would otherwise be a limit on what is allowed becomes a limit on what can be done. The constraint is, therefore, most clearly binding for the safety-critical, cross-domain systems that this article takes as its case and the weakest where a design is simple, single-domain, and cheap to iterate.

What would a complete Layer 1 make possible? Consider the intelligent twin. A conventional digital twin mirrors a physical system; industrial practice already assembles it from the first design phase onwards, but as a curated record of the chosen design, one that, as its own methodology states, “does not store all design alternatives that engineers have developed, evaluated, and discarded” (Rosen and Boschert, 2025). Related work has proposed cognitive digital twins (Zheng et al., 2022; Liu et al., 2025), which extend the twin with cognitive capabilities and semantic integration across subsystems and lifecycle phases, and intelligent digital twins (Grieves, 2024), which become active, goal-seeking, and anticipatory at runtime.

The intelligent twin proposed here takes this further: it is developed in parallel with the physical twin from the earliest design stages, drawing on AI methods that already span those stages (Khanolkar et al., 2023), so that cognition, physics-informed models, and machine learning are integral to the system. The difference from these twins is the source as much as the phase: it would be generated from the same Layer 1 knowledge that drives the design, emerging with the design rather than from a separate modeling effort. At runtime, it becomes the embedded real-time system that drives the physical asset. A proof-of-concept for coordinated heave compensation demonstrated the runtime half of this, with the twin running on industrial control hardware against an experimentally validated real-time model of the crane (Hagen and Østerholt, 2026). Operational data feed it throughout the lifecycle, so the twin adapts as the machine and its operating conditions change. Because it exists during the design phase, it can predict the lifecycle consequences of a component choice before that choice is committed to production.

3.4 Positioning against related work

Several recent reviews cover parts of this ground, and none is organized around the question that this article asks. Reviews of AI in engineering design at large map methods onto design stages (Khanolkar et al., 2023), find AI support for design still in its early phases (Yüksel et al., 2023), or set out the state of the art of AI-enabled product design and a cognitive extension of it (Wang et al., 2025b). Within mechatronics, the reviews record digital-engineering methods used as point solutions, with cross-domain links hardly researched (Gerschütz et al., 2023), AI entering product development only selectively (Nüßgen et al., 2024), large language models concentrated on subsystem and detailed design (Zeman et al., 2026), design-process research treating AI as domain-wise generation and optimization tools (Bricogne et al., 2025), and AI placed in the product’s perception, control, and adaptation (Al Ghazo and Salah, 2026). Reviews of the knowledge side cover AI-enabled tacit knowledge, centered on operational knowledge (Khalili and Jahanbakht, 2026), language-model elicitation from operators with product design excluded (Rank et al., 2025), and knowledge-based engineering, whose capture economics stalled its adoption (Verhagen et al., 2012; Kügler et al., 2023). All of them map where AI or knowledge tooling is applied. None ask where the field’s own definitions place the intelligence they invoke, none treat the capture of cross-domain design rationale as the constraint that binds AI-assisted physical design rather than as one enabling technology or a dataset gap, and none connect that capture to the departure of the engineers who hold the knowledge. That is what this article adds: the placement (Table 1), the constraint and a worked instance of what it must hold (Section 3.2), a model that orders the dependency, and a hypothesis that can fail (Section 4). The article is not itself a review; these reviews are among its inputs, and Table 2 records where each of the closest ones stop.

TABLE 2. Positioning of this article against related work.

✓: addresses the element; Partial: addresses it in part or for a single domain; –: does not address it. ^r: literature review or survey. The elements are this article’s frame; a “–” entry reflects scope, not quality. The “Partial” entries are the incomplete Layer 1 attempts the article refers to in claiming no instance yet drives cross-domain AI agents.

Several recent research programs address parts of the same problem. The most established is the DFG Priority Program SPP 2353, “Daring More Intelligence–Design Assistants in Mechanics and Dynamics,” coordinated at the University of Stuttgart (Eberhard, 2022). de Payrebrune et al. (2025) provide an overview of its objectives: mapping AI onto the V-model for dynamical systems, developing design assistants for specific sub-problems in mechanics and dynamics, and assembling the datasets and benchmarks that AI-driven design requires. SPP 2353 is an important step, but it differs from the argument advanced here in three ways. First, although the overview situates the projects within the mechatronic V-model, each assistant addresses a sub-problem within its own domain; none take on the cross-domain coupling of mechanical, electrical, control, and software decisions that defines mechatronic design. Second, it frames AI as a design assistant, a tool to be used within existing workflows, rather than proposing a reframing of the design discipline itself. Third, that data work targets codified inputs rather than the tacit design knowledge whose capture this article treats as the prerequisite; that partial reach is what Table 2 records.

Two very recent works sit closest to this article. Zeman et al. (2026) reviewed large language models across the mechanical design of mechatronic systems; their survey maps where such models are applied and finds the field concentrated on subsystem and detailed design, but it does not treat the capture of tacit design knowledge or a layered dependency on it. Jiang S. et al. (2025) proposed an “Intelligent Design 4.0” evolution toward foundation-model, multi-agent design automation, which is the closest reframing to the one advanced here. They name robust design data foundations as “a fundamental prerequisite” for that evolution, but treat the gap as one of dataset scale, quality, and access, to be met by curating open datasets and unified schemas; the tacit expertise of practicing engineers, and its capture before it leaves the field, sit outside their frame.

The same lineage’s empirical work shows both the reach of recorded corpora and where they stop: grounding a language model in seventy thousand patents made its design concepts feasible where the general model’s were unmanufacturable (Jiang Z. et al., 2025). That is what a corpus buys, and physical engineering has corpora of its own: patents, handbooks, standards, datasheets, and my own published selection inventory. What none of them hold is the residue that is marked in red in Figure 3. Not what was designed, which patents record, nor the general rules, which handbooks provide, but why a particular cross-domain choice was resolved as it was for a particular duty: the criterion weights that ranked reliability over efficiency for this offshore application, and how that one choice propagated into sensing, control, and the intelligent twin. A patent for an actuator does not carry that; a handbook cannot, because the weighting is duty-specific; and no single-artefact record crosses the mechanical, electrical, control, and software boundaries that the decision couples. A corpus can supply feasibility, but it cannot provide the duty-specific, cross-domain rationale that resolves the choice, and that residue is what Layer 1 must add.

A determined optimist will answer that the residue is not absent but distributed, latent across failure reports, forum threads, supplier application notes, and certification precedents, so that scale might reconstruct it implicitly without any single document stating it. Grant even this. A model that learned from such text can also provide a justification, so the question is not whether it produces an account but whether the account holds: whether it can carry a safety case for the duty. I do not settle it here. That is what the null condition of Section 4 is built to decide, and it is why the test asks for an inspectable justification rather than a prototype that merely works.

In the broader product-design field, Wang et al. (2025b) went furthest toward the process itself, proposing that the design system be given cognitive capabilities. Their framework lists tacit-knowledge acquisition among many enabling technologies but treats it as a technical sub-task for existing elicitation methods, with neither the loss of expertise nor cross-domain mechatronic design in view. Other work has similar boundaries. Tools such as SyMSpace, the most promising of those that my 2020 survey identified (Hagen, 2020), are simulation-based optimization tools: they have advanced component-level design but still require an expert to formulate the design problem. Generative design, topology optimization, and the wider computational design synthesis tradition (Chakrabarti et al., 2011) share that boundary: they search within a problem that is already formulated, and formulating it is exactly the step that draws on Layer 1.

Nüßgen et al. (2024) reviewed AI integration across mechatronic product development and found that AI enters only selectively, with no holistic view across the process. Bi et al. (2026) proposed mechatronics as a design philosophy, named AI integration among the emerging needs but did not develop it, and did not address knowledge capture. Yüksel et al. (2023) characterized AI-powered engineering design as still in its early phases. In the most direct attempt to build something resembling Layer 1, Kumar and Karniadakis (2025) used knowledge graphs to guide AI design agents, motivated by the loss of expert knowledge when engineers depart; the graphs themselves are limited to a single domain and built from published literature rather than tacit expert knowledge. The field’s own current self-assessment stops at the same point. In the 2025 Mechatronic Futures volume, the design-process survey treats AI in design as domain-wise generation and optimization tools (Bricogne et al., 2025). The design-methodology chapter proposes generative-AI “designer companions” to close a quantified competence gap, leaving the source of that knowledge unexamined (Törngren et al., 2025). The chapter on engineering expertise names tacit knowledge as the foundation of mechatronic practice without proposing its capture (Flening, 2025).

Table 2 summarizes how existing work relates to the three elements this argument rests on: the intelligence bias, the design knowledge crisis, and captured design knowledge (Layer 1) as the missing foundation. The article adds no new design tool; it adds the connection between these elements, which existing work treats separately. Where recent work comes closest, it stops short: Jiang S. et al. (2025) treated the gap as a dataset problem rather than a capture problem, and Edwards et al. (2026), who document the loss, listed capture among several opportunities rather than as binding. This article identifies the capture of cross-domain tacit design knowledge as the prerequisite that these accounts take for granted and links the software-automation trend to the physical-systems bottleneck that follows from it.

4 A research agenda

Placing intelligence in the design process raises four open research questions that together define a program for intelligent engineering: how to capture tacit design knowledge, how to represent it for AI agents, how to validate human–AI co-design, and whether it generalizes.

RQ1: How can tacit design knowledge be captured? The publications on AI-enabled tacit knowledge identified by Khalili and Jahanbakht (2026) concentrate on operational knowledge (Section 2.2). Tacit design knowledge is different in kind. When a senior engineer chooses between electro-hydraulic and electro-mechanical actuation for an offshore crane (Section 3.2), the decision draws on field experience, failure modes seen in service, and trade-off intuition never written down. Capturing this knowledge is not the same as canonizing it. Intuition-led design often lands on overly conservative solutions (Section 2.1); that is an argument for capture, not against it, since such heuristics can only be examined, corrected, and extended once they are explicit. The blinded validation of RQ3 is the filter.

Extracting and formalizing this knowledge requires methods that generate design data in context rather than record retrospective accounts. The reconstruction in Section 3.2 shows why: 6 years after a decision, even its maker reaches only part of the reasoning. Structured capture during live design sessions and think-aloud protocols that record reasoning alongside decisions both avoid that loss. The route I judge most promising is AI-assisted co-design, where the agent observes the engineer’s choices and asks about them as they are made: it adds no separate documentation burden, and the in situ questioning that raised recorded explanation rates in interface design (Section 3.1) works the same way (Son et al., 2026). Language models can already assist here: they classify the question types in recorded design protocols against human coding with moderate-to-strong agreement (Sakib et al., 2026). The challenge is that design decisions are contextual, cross-domain, and often implicit; the engineer may not be able to articulate why one configuration is preferred over another without being prompted by a specific design situation.

Much of this knowledge also sits inside firms that treat it as proprietary and have no wish to expose it, so capture is an organizational challenge as much as a technical one: the methods must work on the firm’s own terms, rather than assuming design knowledge can be pooled openly (Edwards et al., 2026). They must, therefore, be deployable inside the firm, so that a company builds its own Layer 1 and keeps the knowledge base, and the intellectual property it encodes, in-house. On-premises and private model deployment make this feasible (Edwards et al., 2026; NVIDIA, 2026); it is a precondition for industrial uptake. Recently retired engineers offer a complementary route: their obligations to former employers narrow with time and distance from specific products, and many are willing to contribute to research. The two routes answer to the two parts of Layer 1 distinguished in Section 3.1, i.e., in-firm capture to the firm-specific part and retired engineers to the generalizable one. How much of what they hold is generalizable heuristic rather than firm-specific intellectual property is a form of the open question posed there, and settling it belongs to this task. Industry accounts now make the same diagnosis and draw the same urgency from retirements (Tung and Roussiere, 2026); what they lack is a research base for acting on it.

RQ2: How can design knowledge be represented for AI agents? Captured knowledge must be structured for computational reasoning, not just stored as text. Kumar and Karniadakis (2025) demonstrated one approach, using knowledge graphs extracted from decades of published airfoil research to guide AI design agents, and they noted that graph-based representations are particularly valuable in domains where “tacit knowledge and interdependencies” are prevalent. The question is whether similar representations can encode the broader scope of mechatronic engineering design knowledge.

In a 2020 survey, I identified seven challenges for automated actuation system design, none of which has been fully resolved since (Hagen, 2020; Sec. 3.5.4); Layers 2 and 3 now reopen them. Candidate representational formalisms for Layer 1 include constraint hierarchies that encode hard physical limits and soft preferences, causal graphs that trace how a requirement change propagates through the design, and case-based libraries that index past solutions by the context in which they worked or failed. These representations should also connect to simulation models that encode engineering knowledge in executable form, from finite-element and fluid-dynamics analyses to dynamical system models, allowing AI agents to evaluate candidate designs against physical laws. Simulation accompanies the design process at changing fidelity, from first-principles concept models through high-fidelity component analyses to surrogate and reduced-order models for optimization and control design. It ends as the real-time digital model inside the intelligent twin; this continuity lets the twin emerge with the design (Section 3.3). Layer 1 most likely needs a combination of these rather than any single formalism; which combination is required is the open question.

RQ3: How can human–AI co-design be validated? Dellermann et al. (2019) proposed a taxonomy for hybrid intelligence systems in which human and AI capabilities are designed to complement one another. The co-design intended here has a concrete division of labor; the agent automates parts of the design, proposing candidates and generating the intelligent twin, while the engineer specifies the task, constrains the search, and validates the result. Validation is harder for physical design than for software: errors are irreversible, prototyping is expensive and slow, and cross-domain faults may not appear until system-level testing. It must, therefore, operate at multiple levels.

At the component level, AI-suggested designs can be compared blind against expert baselines. The actuation selection of Section 3.2 is the obvious first case: capture the selection knowledge, and then let an agent propose the topology for a new duty and generate the intelligent twin from that same source. A blinded panel judges each proposal, with its rationale, on justified fitness for the duty, rather than on agreement with the original expert choice. Concordance with the expert would canonize the intuition rather than test it (RQ1). At the system level, design iteration count, the time to a validated, manufacturable design, and lifecycle prediction accuracy are the quantitative indicators. The virtual prototype, a dynamical simulation model with a visualization layer, is where the intelligent twin is developed and where AI-proposed designs undergo physics-based checks before being committed to hardware.

At the process level, the question is whether human–AI teams explore a broader design space than either humans or AI alone, and whether the resulting designs are robust to conditions not explicitly considered during the design phase. For creative ideation, Wang P. et al. (2025) measured such gains, finding that co-ideation with a structured LLM assistant improved the novelty and quality of design ideas over individual work. Chen et al. (2025) observe the division of labor intended here emerging unprompted: generative tools assist with problem definition and idea generation, while selection stays with the designer. The gains are not automatic: in a blinded design competition, the human–AI team finished behind both the unaided designer and the AI pipeline on rated novelty, a result attributed to the difficulty of directing generative tools effectively (Vo, 2025). Whether co-design outperforms its parts once physical constraints and cross-domain coupling enter is the open question here.

RQ4: Does the concept generalize beyond mechatronics? The three-layer model was motivated by the specific characteristics of mechatronic systems design: cross-domain integration, physical constraints, and reliance on experiential knowledge. However, the underlying problem may be broader. Civil engineering, structural engineering, renewable energy systems, and naval architecture all involve the design of complex physical systems by workforces whose tacit knowledge has not been formalized. If the three-layer model holds for mechatronics, does it hold wherever senior engineers carry irreplaceable design knowledge? Evidence would be successful application in at least one domain outside mechatronics where the design knowledge crisis can be independently documented and where Layer 1 representations prove transferable or adaptable. The answer decides whether intelligent engineering is a niche within mechatronics or a discipline for the design of physical systems more broadly.

What would falsify this hypothesis? If general-purpose AI agents, supplied with no captured design knowledge, were shown to take a safety-critical, cross-domain physical system from requirements to a validated, manufacturable design, the claim that captured design knowledge is a binding constraint at all would not hold. Captured design knowledge here means rationale elicited from practicing or former engineers and then formalized: the content Figure 3 marks as held by no machine-consumable format. The null condition is precise: public corpora, retrieval, and simulation are all permitted; what is excluded is any new elicitation of rationale from practicing or former engineers, in any modality, whether documentation, demonstration, or preference signal. Validated here requires an inspectable design justification and a safety case that holds for the operating environment and its governing standards, not merely a prototype that functions. A success no one can inspect would not meet the test, since the justification is part of the design task in certification-governed domains (Section 3.3). Retrieval of already-published material is allowed in both the general test and the blinded evaluation of RQ3.

The current frontier illustrates the distance: a pipeline that turns a text prompt into a walking quadruped within a day does so for toy-scale robots, within a fixed single-domain morphology, by evolutionary search over off-the-shelf components, with no safety case (Ringel et al., 2025). A weaker, nearer-term version is available: if base-model agents, given no captured design knowledge, matched expert baselines on rated fitness in the component-level blinded evaluation of RQ3, the claim would already be in doubt. That is separate from whether the program succeeds in practice: the reframing is useful if captured Layer 1 knowledge measurably improves human–AI co-design against the component-, system-, and process-level metrics of RQ3, and not otherwise.

5 Discussion

I began from an asymmetry: AI is reaching the design of software but not that of physical machines, because much of software’s design reasoning had been recorded, over a substrate that is cheap to revise, and the reasoning that designs machines had not. Closing that gap, I have argued, is the task now facing mechatronics, which must extend the meaning of intelligent from the product to the design process. When the field’s textbooks and journals use the phrase “intelligent mechatronics,” they mean intelligence in runtime behavior (adaptive control, condition monitoring, and learning-based perception), not in the process that creates those systems. This article has documented that bias, presented evidence for a design knowledge crisis that makes the reframing urgent, proposed a framework that co-develops the physical machine and its intelligent twin, identified the missing element through a three-layer model, and outlined a research agenda to address it.

These claims come with limits. The framework and its three-layer model are conceptual, not a validated methodology: they locate the constraint rather than prescribe a solution. The classification of Table 1 and the crane analysis are my own; the evidence that codifying design knowledge helps an AI agent is so far adjacent-domain and analogical, with the direct test still to run (RQ3); and the demographic argument leans on Norway as a leading indicator. Each bounds the argument without unseating it.

Engineering design knowledge (Layer 1) is the foundation: a constraint both binding and unmanaged. General AI reasoning (Layer 2) and agent infrastructure (Layer 3) keep advancing; without that foundation, they cannot design physical systems. The framing is falsifiable in principle: agents that reached a validated, manufacturable design for a safety-critical, cross-domain machine without captured design knowledge would refute it. Section 4 states the full conditions and the first empirical tests.

Safety, reliability, and failure modes: Placing AI in the design process raises a safety question distinct from the one the field already works on, and the difference is the one Table 1 draws. AI in the product’s control loop acts on the machine in real time; its failure modes are the established subject of the intelligent-control literature, and they are now regulated: the EU Machinery Regulation places safety components with self-evolving, machine-learning behavior under mandatory third-party conformity assessment from 2027 (European Parliament and Council, 2023). AI in the design process, this article’s subject, fails differently. Its errors are design errors, and they surface before the machine exists. A proposal from an agent passes the same gates as one from a junior engineer: the physics-based checks in the virtual prototype (RQ3); the classification rules, ISO dimensions, and ATEX certification of Section 3.2; and functional-safety analysis. The framework removes no gate. It adds one, since a twin that exists during design can predict lifecycle consequences before a choice is committed.

Four process-side failure modes remain, and the framework answers each. First, a proposal can satisfy every stated constraint and violate an unstated one, as with an electro-mechanical actuator of Section 3.2 that could meet the performance requirement but not the certification for the atmosphere it would work in. Such constraints are exactly the uncaptured rationale Layer 1 targets: the 2020 inventory already carried a safety category among its 26 criteria, and the residue beneath it is where the rest live. The blinded evaluation of RQ3, therefore, judges each proposal with its rationale, so that an agent’s reasoning is audited rather than trusted. Second, automation bias and de-skilling: an engineer who accepts fluent proposals stops exercising the judgment that would catch them, the irony Bainbridge (1983) identified in automated plants. The division of labor in RQ3, where the engineer specifies, constrains, and validates while the agent proposes, is the guard, and it holds only if engineers are taught to direct agents rather than defer to them, the education implication taken up below. Third, captured design knowledge is concentrated intellectual property and, therefore, a concentrated target. In-firm deployment (RQ1) keeps it inside the firm’s own perimeter, and provenance keeps it honest: the gradings of Section 3.2 are a 2020 snapshot, so a rationale base must record when each entry held and on what evidence. Fourth, operational reliability: intelligence retrofitted onto a machine adds complexity, external dependencies, and cyber-exposure (Figure 2); an intelligent twin designed in from the start is specified, tested, and certified with the machine rather than attached to it afterward. None of this makes AI-assisted design safe by construction. It makes its failure modes the ordinary failure modes of design, caught by the ordinary gates, and it names the gate that does not yet exist: the captured rationale that says why a compliant-looking proposal is wrong for this duty.

The vulnerability is structural: as industry focuses on retrofitting intelligence onto existing machines, the next-generation of engineers are trained in software and digitalization rather than in the design of physical systems. The experienced engineers who hold design knowledge have fewer colleagues interested in learning it and fewer incentives to transfer it. This makes the knowledge fragile even when setting demographics aside. Engineers who have left active industry, through retirement or career change, may paradoxically be its most accessible source.

What is at stake is capability, not efficiency: whether a field with fewer engineers can still design new machines rather than only maintain the ones it has. The implications are practical. For education, engineers must be prepared not only to design systems but to orchestrate the AI agents that assist in design; that has to be taught, and today, it is not being taught. For industry, the priority is to invest in knowledge capture now, while the engineers who hold irreplaceable design expertise are still available. For research, the program is the four open questions posed above; accountability and explainability in AI-assisted safety-critical design cut across all four and need dedicated work. The machines of the future will be intelligent. The question is whether the engineering that creates them will be intelligent too.

Generative AI statement

The author(s) declared that generative AI was used in the creation of this manuscript. Claude (Anthropic), accessed at https://claude.ai, using releases in the Claude Opus 4 and Claude 5 model families as hosted and updated by the provider across the period of use, March to September 2026. It assisted with drafting and editing prose, structuring the argument, checking references and internal consistency, and preparing the revised manuscript and the response to the reviewers. It was not used to generate or edit any figure, and it was not used to produce data, results, or analysis. Writefull, the grammar checker integrated in Overleaf, was also run over the final text in September 2026; its suggestions were reviewed individually and adopted only where they corrected grammar or punctuation. All ideas, technical content, and conclusions are the author’s own, and all AI-assisted text and citations were reviewed for accuracy and bias.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Chengxi Zhang, Jiangnan University, China

Reviewed by: Federico Del Giorgio Solfa, National University of La Plata, Argentina

Liang Zhao, Zhejiang University, China