Engineering AI Blueprint
The Reference Architecture for Autonomous Engineering Workflows
What happens to the V-model when engineering agents run for hours instead of answering prompts, the foundation your stack needs underneath it, and where the autonomy red line sits.
In collaboration with
The Engineering AI Blueprint sets out the layers an engineering organization needs so that agents can do real engineering work, from the earliest concept through to a validated design, and so that the value to your organization compounds with every run. The stack has to fit into the systems you already run, which is why it is open at both ends.
Work comes in at the top, from engineers or from other agents and automated triggers, through MCP and the API. At the bottom, the stack connects to the systems you already run.
Click a layer or ⓘ to see why it matters
HOW WORK ENTERS
Engineers in the browser
with the SimScale agent
Your agentic platform
over MCP and API
CAD add-ins
and chat
Orchestration
NVIDIA Agent Toolkit
Nemotron
Long-running agents that plan, act and verify, within limits the engineer sets
Surfaces
Agent core
Tool harness: checked actions only
Verifiers
Simulation & AI Engine
CUDA-X
PhysicsNeMo
Ground truth, and the fast path to it
Flow
Thermal
Structural
Electromagnetics
First-principle solvers · ground truth
Surrogate training
Fast prediction
Physics AI · trained on solver data
Your own solvers and models join as methods
Open Integration
Omniverse
One action space, any surface, any method
API and SDKs
MCP server
Sandboxed component registry
Workflow runner
Cloud Infrastructure and Governance
NeMo Guardrails
The part security and procurement read first
Identity and access
Audit
Per-job compute
Data management
Never used for training · no third-party retention · tenant-private
DEPLOYMENT CHOICE
Same stack, configured to your requirements
Multi-tenant
The default
Dedicated account
Customer-held keys
Your own
cloud / on-premise
Knowledge Layer
Beside the layers, growing with every run.
Agent skills
Standards
Validated cases
Setup methods
Corrections
Private to your organization
Your Existing Systems
Connected through the open integration layer, each feeding a different part of the stack
CAD
SolidWorks, CATIA, NX, Onshape
PLM and SPDM
Teamcenter, Windchill, 3DEXPERIENCE
ERP and ALM
SAP, Jama, Polarion
Solvers and test data
Your licenses, lab and rig data
Blue: SimScale Engineering AI, the four layers and the knowledge layer. Outlined blocks: the systems it connects to. Tags: where NVIDIA technology typically sits.
Read the stack from the top down. The orchestration layer plans the work, the engine does the physics, the open integration layer reaches the tools and data the work needs, and the cloud layer keeps every step inside the rules you set. The knowledge layer sits beside them all and learns from every run.
Chapter 1
AI Is Changing the Shape of the Design Process
Agentic engineering is the way of working: AI agents carry out engineering tasks such as setting up, running and interpreting studies, while engineers direct and review the work. Engineering AI is the technology that makes it possible: the agent, the solvers and physics models it calls, and the knowledge layer that keeps what it learns.
The V-Model Commits Early Because Testing Used to Be Slow and Expensive
Almost every large hardware organization develops products using some version of the V-model. Requirements run down the left side: customer targets, product specification, system specification, component specification. Integration and test climb back up the right: component test, system integration, product validation, customer sign-off.
The logic is sound, and people will keep working this way: define the requirements, design to them, build, then test and verify against them. Simulation and virtual testing are already widespread. Teams run much of their testing and validation virtually, a digital V inside the main one.
The process accepts rework as normal. When verification shows the design does not meet the requirements, the team goes back to the left side to rework the system or detailed design, and sometimes the requirements themselves. Every round of rework is slow and costly. Simulation has helped by catching some problems earlier, but it has been a patch on a process that still expects to iterate.
V&V Latency Is Where Cost and Design Quality Are Lost
The V has two important moments, and they sit far apart.
Commitment happens early, on the left. The concept is chosen and the targets are agreed in the first gates of the program.
Proof arrives late, on the right. Only physical integration and test show whether the design was right.
The distance between those two moments is V&V latency, the latency of verification and validation. Put plainly, it is the feedback delay: the wait between committing to a design and finding out whether it was right.
The V-Model Commits Design Early and Proves It Late
The V-model: design commitments on the left, verification on the right, and the latency gap between them.
The Cost of the Gap Is Measurable
A study of seven years of development data on two unmanned aircraft programs traced 58 missed system-level requirements back through engineering change requests, failure reports and gate reviews (Tan, Otto and Wood, Design Science, 2017).
It found that defects rooted in concept-phase decisions took about 13 times more rework to fix when they were detected late, after system-level testing or in service. Design decisions made before design freeze accounted for 86% of the programs’ total expected cost.
That rework is what V&V latency costs. The multiplier reflects where the defect came from, not only how late it was fixed. Early decisions are the most expensive to unpick, because the program cannot show them to be wrong until it builds and tests.
Engineering leaders recognize this. In conversations this year, we heard how a marine engine manufacturer finds vibration problems in engine pipework on the test bed, or even after installation and acceptance testing, once the engine is in production, because there is no ability to look earlier. An appliance manufacturer named one failure mode that had caused repeated test-and-rework cycles on production machines, at a direct economic cost.
86%
of total expected program cost was set by design decisions made before design freeze.
13×
more rework to fix concept-phase defects when they were detected late.
Why the Delay Exists
The delay exists because verification and validation are expensive. A high-fidelity simulation can take days to set up and hours or days to run, and in many cases needs a specialist to build the model and interpret the result. The most time-consuming steps are highly manual: searching for data and preparing the model can take up to 70% of an analyst’s time, by one industry estimate (Digital Engineering, 2013). A physical prototype takes even longer and costs even more.
So teams simulate what they can afford, commit to a design, and spend the remaining budget confirming that choice instead of exploring alternatives.
The alternative to simulating everything is to pick a design option on experience, similarity to earlier designs and established methods. While the judgment may be sound, the lack of visibility across the design space leads to more conservative, and less innovative, design decisions.
Why This Changes With Engineering AI
Toyota demonstrated the value of exploring the design space more fully 30 years ago, long before simulation-driven design was practiced at anything like today’s scale. Set-based concurrent engineering, carrying multiple design alternatives in parallel and converging late, produced better vehicles faster than point-based selection. It was documented in MIT Sloan Management Review in 1995 with the finding that delaying decisions can make better cars faster. It never became universal practice, for economic reasons. AI gives engineering teams another way at the same problem: evaluation gets cheap enough to make the approach economic.
When a physics-grounded answer returns in seconds rather than days, and an agent can set up, run, interpret and report the results of the study without a specialist in the loop, the time and cost of each answer will no longer be the main limit on how many designs a team can evaluate.
The early design stage is where the opportunity lies to transform this process. Today the number of analyses that fit in a program decides how much of the design space the team sees before concept freeze. Without that limit, the team iterates far more often, on far more candidates, and each candidate is tuned and re-tested instead of judged. Concept freeze stops being a decision made on a partial view. It happens when the design reaches optimal performance, and because an iteration is cheap, any decision can be reopened. The aim is a V that needs far less rework: the design reaches validation already optimized, so the right side confirms it instead of sending the team back to the left.
The Same V, Zoomed In on the Left Arm
Illustrative: the left arm of the V, today versus with agents.
Inside the concept phase, each design iteration runs in four steps
Explore
The agent generates, varies and optimizes design options.
Predict
Physics AI returns performance in seconds.
Validate
A physics-grounded check that escalates to a full solve where it matters.
Decide
The engineer approves, rejects or redirects.
Each iteration takes minutes, there are many more of them, and all of it happens before the concept is frozen.
More iterations only help if the answers can be trusted, because an optimizer finds a model’s errors as readily as its insights. Chapter 3 covers how that trust is earned.
Every iteration also adds to what the next one knows. The setup that worked, the standard it was checked against and the correction an engineer made along the way are all kept, so the next study starts further along. Results from validation flow back into concept too: what a design did under test shapes the starting point for the next generation, so the agent learns. Chapter 2 calls this the knowledge layer.
The Four Tenets of the New Process
01
Exploration replaces selection.
Teams stop choosing from the few concepts they can afford to analyze and start exploring the design space and optimizing what they find.
02
Proof moves earlier.
Concept freeze is no longer made on a partial view of the design space. Evidence that used to arrive after commitment now arrives before it, and every decision carries its evidence when it is made, instead of waiting for a gate to confirm it.
03
Physical test becomes confirmation.
The right side stops being where the organization learns things and becomes where it proves what it already knows. Fewer prototype rounds, cheaper ones, and far less rework, because problems surface before the design is committed.
04
Intelligence compounds with every run.
Each iteration, including every correction an engineer makes to an agent’s proposal, is kept in a knowledge layer your organization owns: standards, validated cases, setup methods and the reasons behind decisions. The organization gets better at the next program, not just this one, and what it learns is its own.
How Far Agents Should Go
Engineering AI targets V&V latency. It does not necessarily remove every other wait in a program.
Approvals between functions stay where the organization puts them: it decides which decisions an agent can take alone and which need sign-off. Deciding that, and how roles, methods and reviews change around agents, is an operating-model question as much as a technical one. For most organizations it will be the harder of the two. What the stack changes is the cost and speed of finding out whether a design decision was right, which is what those other processes are waiting on.
What This Way of Working Needs From Your Tech Stack
What has to be true of your engineering stack for this to work? Chapter 2 sets it out.
Chapter 2
Our Blueprint: The Anatomy of an Engineering AI Architecture
How Work Enters
There are three main routes in. In each, the agent can work alongside an engineer or run on its own.
Engineers in the browser
Engineers work with the SimScale agent in SimScale itself, the fastest way to start, with no integration work.
Your agentic platform
Your own agents call SimScale over MCP and the API, with your own keys and models. Your platform owns the plan, and SimScale does the engineering.
CAD add-ins and chat
The agent sits inside the tools engineers already use, so the answer arrives in their own workflow.
If Your Agents Already Orchestrate the Work
Many engineering organizations now run agentic platforms that plan and route work across their tools and teams. Engineering AI is built to sit underneath them. Over MCP, your platform calls the same tools SimScale’s own agent uses, and a PLM release or a nightly sweep can start a study with no person involved. The work runs under the same permissions and audit trail as if an engineer had started it, and it draws on what your platform cannot provide on its own: the harness, the verifiers and your knowledge layer.
Engineers on Desktop Tools
Desktop CAD and PLM tools do not have to move. The orchestration runs headlessly through MCP and the API, so it reaches a desktop tool through a connector or an on-premise agent, without migrating the data first.
Who Drives It
The layers stay the same in every deployment. What changes is how much of the work the engineer hands over.
Mode 1
Engineer-driven
The engineer runs every step.
Mode 2
Agent-assisted
The agent supports the engineer and takes discrete tasks off their hands, such as setting up a study, running variants or summarizing results. The engineer approves each one.
Mode 3
Agent-led
The agent runs a whole study or workflow end to end, and the engineer reviews the results.
Mode 4
Autonomous, within limits
The agent runs long workflows across a design space, including headlessly, inside limits the engineer has set. The engineer signs off the outcomes.
In every mode, the engineer sets the intent and owns the judgment. Autonomy can be delegated; accountability cannot. It stays with the engineers, program leads and engineering function who sign off the work. Chapter 3 sets out where the agent’s limits sit.
Orchestration: The Agent
The agent takes an engineer’s intent and carries it through to a checked result. It plans the multi-step work, sequences the tools, validates its own output and reports back. The layer holds the surfaces engineers reach it through, the agent core, a tool harness, and the verifiers that check each result. It draws on the knowledge layer described below. Chapter 3 covers the verifiers and the harness.
Two things set it apart from a chat assistant.
It runs long. A design study that touches CAD, meshing, 40 solver runs and a report is hours of work. The agent holds the plan across all of it without a human re-prompting at each step, which needs an execution environment built for long-running agents rather than a request-response API.
It carries memory at three levels: the run, the project and the organization. A correction an engineer makes once does not have to be made again. The organization level is the knowledge layer described below.
In SimScale’s deployment, the reasoning engine can run on several large language models, including NVIDIA Nemotron, and users can readily change that selection. The architecture does not depend on one model, so you can bring your own. For teams building their own agents, NVIDIA Agent Toolkit, an open-source library for connecting, evaluating and optimizing agent workflows, is built for this layer.
Knowledge Compounds
The four layers are open machinery, and any organization can build on the same blueprint. The long-term advantage is what only yours has: your organizational knowledge, a knowledge layer that sits beside the machinery and grows with every run. The agent in the orchestration layer draws on it, and the results of every run feed the physics AI in the engine.
It holds what an experienced team carries in its head and its folders: the agent skills that encode how your team works, your standards and templates, validated cases, setup methods that have worked, the reasons behind past decisions and the corrections engineers have made to the agent. This is also how engineering judgment stays with your team.
Three rules apply to it:
Rule 1
Yours by default
It is private to your tenant. Anything shared beyond it is opt-in, and Chapter 3 sets out what that means for security and IP.
Rule 2
Verified before it is kept
Only work that has passed the verification tiers in Chapter 3 becomes precedent. A plausible result nobody checked does not get promoted into method.
Rule 3
Measured
The improvement is the gap between the agent with your knowledge layer and the same agent without it, re-measured on a regular schedule.
This is why intelligence compounds with every run, as Chapter 1 describes. The first study on a new class of problem starts from the shared library and your standards. Later ones start from your own validated precedent, with every earlier correction already applied.
Intelligence Compounds With Every Run
Agent runs a study
Engineer reviews and corrects
Result is verified
against the tiers in Chapter 3
Kept in your knowledge layer
skills, standards, cases, methods
Next study starts further along
Every verified result and correction stays with your organization
Simulation and AI Engine
This layer provides the ground truth and the fast path to it: first-principle solvers, and Physics AI trained on what they produce.
First-principle solvers
CFD, FEA, thermal, electromagnetic and multiphysics simulations run on production-grade solvers, including OpenFOAM, Marc and Simerics, on elastic cloud compute that runs thousands of studies in parallel. Existing licenses, such as ANSYS Mechanical, ANSYS CFX, STAR-CCM+, ANSA and HyperWorks, integrate rather than get replaced.
Physics AI
Models trained on high-fidelity solver data return performance in near real time, which makes exploring at concept speed affordable. When confidence drops, the stack runs a full solve instead of returning a guess. SimScale’s physics prediction runs on NVIDIA PhysicsNeMo, including DoMINO.
Open Integration
Every surface and every method gets the same set of actions: a public API and SDKs, MCP, a sandboxed component registry and a workflow runner. Anything an engineer can run, an agent can run too, with the same permissions.
Workflows let teams bring their own methods, including in-house solvers and external AI models, and run them on the platform, hosted by the team, or connected to a CAE tool already running. Agents chain these steps together and pass results between them. Each method runs in its own sandboxed container.
Cloud Infrastructure and Governance
Security and procurement read this layer first: identity and access, an audit record of every agent action, compute provisioned per job, and data management. The default deployment is multi-tenant. Where your security, residency or regulatory requirements call for it, the same stack runs in a dedicated account, with customer-held keys, or in your own cloud or on-premise. Chapter 3 covers security, data and IP.
Pablo Hermoso Moreno
Sr. Solutions Architect, NVIDIA
“Agents are only as useful in engineering as the physics behind their answers. Engineering AI brings two things together: AI that can reason through long, multi-step work, and simulation that can check every step. Physics AI models built with NVIDIA PhysicsNeMo give agents near-instant predictions to explore with, and accelerated solvers provide the ground truth those models learn from. Built on an open architecture, it lets engineering teams choose their models and tools and keep the knowledge they build.”
Your Existing Systems
The stack reads from and writes back into the systems you already run. An agent that cannot reach your data and tools is of little use.
CAD
Native files from SolidWorks, CATIA, NX, Creo, Inventor, Solid Edge, Revit, Rhino and nTop, neutral formats such as STEP and Parasolid, and direct connectors for Onshape and Fusion 360.
PLM and SPDM
Teamcenter, Windchill, 3DEXPERIENCE and equivalents.
ERP, ALM and requirements
SAP, Jama, Polarion, and the test management that goes with them.
Solvers and test data
Your existing solver licenses, and the lab and rig data that correlation depends on.
As AI speeds up the engineering work itself, more of the lead time sits in the handovers between teams. An agent that cannot trace a requirement from your requirements tool into a design change and the test that verified it produces artifacts faster, and leaves the program no more connected than before. Bringing product data, PLM and legacy environments within the agent’s reach is often the largest piece of work in an engineering AI program, and it is what trust ultimately rests on.
From Capability to Trust
An architecture that can act still has to earn trust before it is allowed to. The next chapter covers how, and where the red line sits.
Chapter 3
Where Trust Comes From: Physics and the Harness
Trust in an engineering agent has two sources. One is physics. The other is the harness that decides what the agent is allowed to do.
An Agent That Cannot Validate Its Decisions With Physics Is Not Autonomous
A language model can propose a design change in a second. In hardware, what matters is whether that change actually works. Without a physics check, an agent can only judge whether a change looks plausible, and a plausible change can still be wrong.
Simulation has always been able to check a design, but it could not keep pace with an agent. Physics AI can: it returns performance in near real time, so the agent can check its own proposal before presenting it. When confidence drops, the stack runs the full solve instead. This is why a simulation platform has to sit inside an engineering AI stack, not beside it.
Trust determines whether the aim of less rework is realized. If early results cannot be relied on, the errors still travel to the right side of the V and the team redoes the work there, only later and at greater cost.
What Verified Actually Means
Verified can mean very different things, so one label is not enough. The bar should be tiered.
Tier 1
Published reference data
Where it exists. The strongest bar, and the rarest.
Tier 2
Expert sign-off
Where it does not. A named engineer took responsibility.
Tier 3
Physical plausibility checks
Always. Conservation, magnitudes, boundary behavior, sanity.
A result that has cleared tier 3 and nothing else is still useful. It is a different claim from tier 1, and the system should say which one it is making. That label is also what an auditor or certifier needs to see.
Physics Is Not Enough: The Agent Also Has to Behave Predictably
An unbounded agent with excellent solvers can still change a material property it was not asked to change, pick the wrong element type, or quietly drop a meshing practice the team spent years standardizing. The solver will faithfully compute the wrong problem.
The second source of trust is the harness: the part of the stack that constrains what the agent can do, how it does it, and when it has to stop and ask.
Domain-specific skills
The agent follows codified engineering methods, held as agent skills in your knowledge layer.
Defined actions only
The agent can only use the operations the platform exposes, such as creating a study, assigning a material or running a mesh, and each one is checked before it runs.
Scoped permissions
What it can read and write is bounded per project, per tenant, per user.
Trace checking
Every step is recorded and inspectable after the fact, which is what traceability from requirement to evidence depends on and what makes AI outputs auditable for compliance and certification.
Grading against a standing benchmark
The agent itself is tested, not just its solvers.
Defined escalation paths
The agent knows which decisions are not its to take.
The platform enforces these limits. The agent can only act through checked platform operations, so the limits hold whatever the model decides.
The Harness: The Agent Acts Only Through the Platform
HARNESS, ENFORCED BY THE PLATFORM
Domain-specific skills
Defined actions only
Scoped permissions
Agent
plans, acts and verifies
checked platform
operations only
Trace checking
Benchmark grading
Defined escalation paths
Tools and Data
solvers, CAD, PLM, compute
Every action passes through the platform, so the limits hold whatever the model decides.
Where the Red Line Sits
The four modes in Chapter 2 show how much work the stack can take on without supervision. The red line decides how much it is permitted to take on, and it is set per class of decision, whichever mode is deployed.
What matters is the cost of a wrong answer, so autonomy should be scoped by reversibility and consequence, and, in safety-critical or regulated programs, by which decisions a named engineer must sign. The line is not fixed. It moves as grounding in physics and data improves, as the organization owns more of its stack, and as each program proves the value.
The Red Line Is Set by Reversibility and Consequence
Set per class of decision, whichever mode is deployed, and enforced in the harness.
Reversible, low consequence
Irreversible, high consequence
Agent acts alone
Reversible, low consequence, checkable by the harness
Meshing
Boundary conditions
Convergence
DOE runs
Reporting
Agent proposes, engineer approves
Consequential but recoverable, a human owns the call
Variant shortlist
Surrogate validity
Rule and method changes
Humans only
Irreversible or externally accountable, never delegated
Safety-critical sign-off
Regulatory homologation
Requirement change
Enforced by the harness, not by supervision
- Domain-specific skills
- Typed tool calls
- Scoped permissions
- Trace checking
- Standing benchmark
- Defined escalation paths
The red line: three zones by reversibility and consequence.
Security, Data and IP
Security questions come early in any enterprise evaluation. The answers below follow the order of a typical review.
Is our data used to train AI models?
No. Neither SimScale nor its model providers use customer prompts, uploaded content, tool outputs, simulation data or model responses to train or improve AI models.
Where does inference run, and does the provider keep anything?
Inference runs in EU regions on AWS Bedrock and Google Vertex AI, under agreements that prohibit provider retention.
What can the agent see?
Only the data the requesting user is already permitted to see. It works inside that person’s permissions.
Who owns what the agent learns?
You do. Method, corrections and captured practice stay with your organization and never cross into another customer’s context or a shared base model. Your methods and standards are kept as custom agents (instructions plus documents the agent can search), versioned and permissioned like any other platform asset.
How is the platform itself secured?
SimScale GmbH has completed a SOC 2 Type II audit. All simulation and CAD data is AES-encrypted in storage and in transit. Under SimScale’s terms it does not sell, trade or give away your CAD or simulation data, and staff are background-screened and bound by confidentiality agreements.
Where should it run?
The default is multi-tenant cloud, where interoperability with your other systems is best. Where your security, residency or regulatory requirements call for it, the same stack can run in a dedicated account, with customer-held keys, or in your own cloud or on-premise.
Can we bring our own key or model?
Bring-your-own key and bring-your-own model are available for organizations whose policy requires inference to happen somewhere specific. Together with the deployment options and a tenant-private knowledge layer, this lets an organization decide how much of its AI it owns, from where inference runs to the engineering knowledge itself.
“Moving engineering AI from pilot to utility is a shift on the scale of paper to CAD/CAE: a new operating model, with shared AI capabilities embedded across engineering, smaller pods, shorter loops and a compounding knowledge layer. Yet, autonomy is not authority: agents execute and orchestrate, engineers stay accountable, and AI cost sits in the program budget. The red line is risk-based, set by data, security, IP and engineering criticality, and will advance as physics grounding, sovereign infrastructure and AI value tracking mature.”
Chapter 4
Blueprints in Practice
Two workflows that show the architecture at work, and three tests any agentic workflow should pass.
Workflow 1. CAD to Validated Design
Preparing the CAD is the first step of any 3D simulation workflow, and often the longest and most manual. As Chapter 1 noted, it can take up to 70% of an analyst’s time, and it is the main reason a simulation request waits a week before anything is computed. Automating it is worth more than automating the solve.
Typical preparation tasks an agent can take on:
01
Defeaturing the assembly: suppressing fasteners, small features and cosmetic geometry that does not influence overall performance.
02
Replacing fasteners with beams, springs and RBEs, and applying bolt preloads.
03
For CFD, extracting flow volumes, defining mesh refinement zones, replacing fans and pumps with simplified momentum sources, and applying the right turbulence model and boundary-layer treatment.
Reporting at the other end costs nearly as much time. Much of it is information transfer: moving results between formats, exporting plots and images, and assembling the report a customer or design review expects.
The engineering judgment behind this preparation and reporting can be written down as agent skills. That lets agents take on the steps that have kept simulation workflows from being automated end to end.
Autonomous Design Validation
Autonomous design validation, step by step.
AGENT
ENGINEER
1
AGENT
Intake
Reads the CAD assembly and the requirement it is being validated against, from PLM or the requirements tool.
2
AGENT
Preparation
Defeatures, applies simplifications (if instructed), builds the mesh against the codified method for this part class.
3
ENGINEER
Method check
Engineer approves the setup on the first run for a new part class: which features are removed and how physics models and mesh refinements are configured. The human engineer can request further checks, e.g. for mesh independence. Later runs reuse them.
4
AGENT
Exploration
Generates and varies the design options inside the allowed parameter bounds.
5
AGENT
Prediction
Physics AI returns performance across the set, escalating to a full solve where confidence drops, or if no suitable model exists.
6
ENGINEER
Shortlist
Engineer picks which variants carry forward. The agent explains why each made the list.
7
AGENT
Verification
Full high-fidelity solve on the shortlist, correlated against test data where it exists.
8
AGENT
Write-back
Result, evidence trail and method version written back to the PLM item and the requirement.
9
ENGINEER
Sign-off
Engineer signs. Safety-critical sign-off never leaves this step.
Steps 3 and 6 are where compounding knowledge is captured. Every correction an engineer makes there becomes a method the agent applies next time, so accuracy rises across a program instead of resetting with each one.
Workflow 2. RFQ Response
The second workflow turns engineering capacity into commercial throughput. It starts from the validated setup in Workflow 1, so the agent can run the whole workflow quickly and with a high degree of autonomy.
A customer sends part requirements and an operating point or duty cycle, and asks whether you can build it and what it will cost. Because the answer has to come back quickly, today it rests on what is on the shelf and on engineering experience, with no simulation behind it. With agents, the team can check the proposal properly before replying, quote with more confidence and offer better product performance.
RFQ Response
RFQ response, step by step.
AGENT
ENGINEER
1
AGENT
Intake
Parses the incoming request and the attached geometry or duty point.
2
AGENT
Feasibility
Checks the request against the existing product range and past similar jobs.
3
AGENT
Analysis
Prepares and runs the performance study using the standing method for this product family.
4
AGENT
Costing input
Returns the engineering parameters the quote depends on: material, pressure drop, efficiency, envelope.
5
ENGINEER
Review
Engineer reviews the technical answer. Commercial terms stay with the commercial team.
6
AGENT
Response
Drafts the technical section of the response, with the evidence attached.
Three Tests Any Agentic Workflow Should Pass
Both workflows pass three tests. Use them on any agentic workflow you are shown, including SimScale’s.
Test 1
Can you point at the steps where a person decides?
The approval points should be explicit and few. If you cannot find them, the workflow is either not autonomous or not safe.
Test 2
Can you see which version of the method produced a result?
The agent should follow a known, versioned set of setup and modeling choices rather than improvising them, so any result can be traced and repeated.
Test 3
Does the result end up in the systems your team already works in?
A result that stops at a PDF has not changed how the organization works.
Chapter 5
Where This Sits in Your Stack
The integration question: what do I have to rip out?
Nothing Gets Replaced
Your CAD, PLM and ALM systems stay the record. The agent reads from them, does the engineering work and writes the evidence back, as the architecture in Chapter 2 shows. Nothing has to change first, so a team can start straight away on one real piece of work and measure the impact. Scaling beyond it takes deliberate work on those data foundations.
Nothing Gets Replaced: Engineering AI Slots Into Your Stack
TODAY
Engineers
Work handed over by hand: copying data, exporting files
Your Existing Systems
CAD
Solvers and test data
ERP and ALM
PLM and SPDM
WITH ENGINEERING AI
Engineers and your own agents
Unchanged
MCP and the API
Engineering AI
SimScale agents, skills and knowledge
Physics engine, integration and governance
Reads, and writes evidence back
Your Existing Systems
Unchanged
CAD
Solvers and test data
ERP and ALM
PLM and SPDM
What sits above and below stays as it is. The only addition is the layer in between.
Questions to Ask Any Engineering AI Vendor
Take these to your next vendor meeting.
On the process
- Can an agent in your system trace a requirement into architecture, into design, and into the test that verified it?
- Can it reach the tools it needs without a human copying data between them?
- Can it spot a cross-domain inconsistency before integration rather than at it?
- Can it prepare a decision using trusted data from more than one function?
On autonomy
- Which tasks does your agent perform without approval, and who decides that list?
- Is the boundary enforced in the software, or does it depend on someone watching?
- What does the agent do when it is not confident?
On physics
- What happens when a surrogate model is outside its training range?
- How is the agent evaluated across applications, how often, and against what benchmark?
- What does verified mean in your product, precisely?
On integration
- Which connectors are bi-directional, and which are export only?
- What happens to our desktop tools?
- Can we bring our own model, our own key, or both?
- What deployment options exist, and what changes between them?
- Can we connect our own agent over MCP?
- Can our own solvers and in-house methods run on the platform alongside yours?
On the data
- Where does a method captured from our engineers live, and what stops it leaving our tenant?
- Is our data, or anything the agent produces, used to train models, by you or by your model providers?
- Who owns the training data generated by our simulations?
- What does the platform learn from our work, and how is the improvement measured against the same agent without it?
What to Measure Once You Have Started
Cost per engineering decision
Token-based calculators miss what dominates the cost: retries, re-runs, simulation compute, and the wait between a decision being prepared and being taken. Price the decision. Estimate it before the work starts, and charge it to the program that benefits rather than to a central R&D budget.
Rework
How much effort goes into redoing work found wrong late. If this approach works, rework falls as more of the testing happens early.
Machine-readability
Copilots deployed and proofs of concept completed measure activity. A better sign of lasting value is whether engineering work is becoming more machine-readable, more connected and easier to share across teams.
AI Yield
Cost is half the picture. Capgemini Engineering tracks AI Yield, the value AI produces divided by what it costs, with each program defining the value that matters to it, such as rework avoided or decisions made earlier.
Where to Start
Start with the handover that costs you the most, which for most organizations is design to verification. Instrument it before you change it, so you can tell whether it moved. Then pick one part class, codify the method, and let the agent work on that before it works on anything else.
Free PDF
Get the Full Engineering AI Blueprint
Take the full blueprint with you as a PDF, all five chapters, to share with your team and bring to your next vendor meeting.
Download the PDF
Fill in your details and we will send the full blueprint to your inbox.
By submitting this form, you agree that SimScale processes your data in line with its privacy policy.
