By Guy Rouleau, Consulting Advanced Support Engineer, and Jason Ghidella, Sr. Principal Technologist, MathWorks
AI coding agents are becoming part of engineering workflows, including the way teams build, test, and refine models. But their value is not simply faster model creation. An agent may generate models, scripts, and tests that execute successfully, while missing the structure, discipline, and constraints required for real engineering systems.
That is the hidden friction in AI-assisted Model-Based Design. More output does not automatically create more clarity. The hard part is keeping engineering intent aligned from specification through implementation and test, so models reflect physical assumptions, component boundaries, parameters, interfaces, and expected behavior in ways engineers can review, verify, and maintain.
A structured agentic workflow can help close that gap. The goal is not to remove the engineer from the workflow. The goal is to keep the engineer in the lead while giving the AI agent enough context, tool access, and workflow guidance to contribute usefully.
In this context, AI-assisted engineering is the broader shift, while agentic AI is the practical mechanism: AI agents that can use engineering tools, follow structured workflows, and help move work from intent to model and test. But for engineering teams, the agent also needs to be grounded. That means giving it access to the context that defines the workflow: models, parameters, interfaces, assumptions, tests, and Model-Based Design practices. Engineering quality still depends on more than producing something that executes.
In Model-Based Design workflows, the important questions go beyond whether the model runs. Does the model reflect the intended system behavior? Are the assumptions visible? Are the parameters defined in a way that can be reviewed and reused? Are the interfaces clear? Are the tests connected to expected behavior?
Those questions are where unstructured AI assistance can struggle. A generic software pattern may be useful in many coding contexts, but engineered systems require discipline around physical behavior, system decomposition, verification, and long-term maintainability. If those elements are not made explicit, an AI agent can move quickly while carrying ambiguity forward.
The challenge, then, is how to give AI agents enough engineering context to contribute in a structured and reviewable way. In Simulink workflows, that means connecting the agent not just to model generation tasks, but to the broader Model-Based Design process: system structure, parameters, interfaces, assumptions, verification workflows, and expected behavior. Approaches built around this idea aim to make engineering intent explicit. Whether that intent actually survives contact with a real system still needs to be shown.
To see what it takes to ground an AI agent in a real engineering context, it helps to start with a system where assumptions, structure, and tests must stay aligned. The disk‑brake thermal model provides a concrete test of this idea.
Disk-brake thermal modeling: from engineering intent to testable evidence
A disk-brake thermal model is simple enough to understand quickly but demanding enough to expose where AI-assisted workflows can lose engineering intent. Capturing heat transfer behavior requires explicit assumptions, clear component boundaries, well‑defined parameters, and tests tied to expected physical behavior. If any of those elements are implicit or disconnected, the model may execute successfully, but could be difficult to review, validate, or trust.
In this example, an AI agent was asked to create a plan for simulating the thermal behavior of typical disk brakes in an average sedan during common driving maneuvers. Figure 1 shows the physical behavior the model is intended to capture.
The point of the workflow was not just that the agent could generate a model. The value was that it created intermediate engineering artifacts that could be reviewed before implementation began.
In this workflow, that structure was enabled by the Simulink Agentic Toolkit, which provides AI agents with access to Simulink models, planning templates, and Model-Based Design context rather than relying on unstructured prompt-and-response interactions.
Planning before building
Before generating the model, the agent produced a structured plan for the disk-brake thermal system. That plan included the system architecture, implementation approach, test plan, assumptions, interfaces, equations, and parameters. Here is the output after a few iterations:
The plan is based on a template and contains standard sections such as:
- Executive summary
- Problem statement
- Goals and success metrics
- Assumptions
- Interface
- References
The plan then went into implementation details. Across several iterations, it evolved to include a simple longitudinal vehicle with the brake model, as shown in Figure 2.
The plan also described how the model would be componentized into subsystems and referenced models, including brake hydraulics, vehicle longitudinal dynamics, heat partition, rotor thermal behavior, pad thermal behavior, and related components, as shown in Figure 3.
This planning step is important because it gives engineers something concrete to review before the agent starts building. The model is not created from a single prompt and is not accepted as-is. The workflow creates a visible design intent that can be inspected, corrected, and refined.
The agent also described the equations to be implemented in each component, as shown in Figure 4.
The workflow identified parameters needed by the model, and also produced a parameter list, as shown in Figure 5.
That reviewable trail is what helps ground the AI-assisted workflow. It gives engineers a basis for understanding what was created, why it was created that way, and what needs to be checked before the result can be approved. That makes the workflow more aligned with how engineers typically work. Assumptions, interfaces, equations, and parameters are not hidden inside generated code or model structure. They are surfaced early, where they can be checked.
Implementing the model
Once the plan was reviewed and refined, the agent was instructed to generate the model. The result is shown in Figure 6.
In this case, the first generated model captured the intended structure of the disk-brake thermal example. The model included the vehicle-level inputs, brake hydraulics, heat partitioning, and thermal behavior of the rotor and pad.
The key is not that the agent created a model from a prompt. The model was created from a structured plan that described the system architecture, component responsibilities, equations, parameters, and test intent. That structure helped reduce the risk that the agent produces an artifact that runs but is difficult to understand, extend, or validate.
Parameters were also handled explicitly. The agent initially created a MATLAB script defining the required variables. In a production workflow, those parameters could also be moved into a data dictionary or another controlled data source, depending on team practices.
Testing the result
Testing is where the value of a structured agentic workflow becomes especially clear. The agent not only produces a model. It also produced a test plan that described how individual components and the full system should be validated. Each test was derived directly from the original assumptions and expected behaviors defined during planning, providing a traceable link between engineering intent and observed model behavior.
The test plan included tests for individual components, as shown in Figure 7.
It also proposed multiple scenarios for the full closed-loop simulation, shown in Figure 8.
This matters because AI-assisted engineering should not stop at artifact generation. For Model-Based Design, engineering review depends on connecting design intent to executable models, verification activities, and reviewable results. A workflow that helps generate tests alongside the model makes it easier for engineers to evaluate whether the model behavior matches expectations and whether there is enough evidence to approve the result.
The tests were then implemented in Simulink Test Manager, and the results are shown in Figure 9.
This is the difference between using AI to generate engineering content and using AI within an engineering workflow. The model, parameters, assumptions, and tests remain connected. Engineers still review the artifacts and remain responsible for the result, but the agent helps carry more of the repetitive work needed to move from intent to implementation and validation.
Why this matters
This example is not about generating a disk-brake thermal model. It illustrates a broader issue in AI-assisted engineering: without structure, engineering intent can be lost even when models or code execute correctly. AI agents can accelerate model creation, but speed alone does not ensure that the resulting model reflects the intended system behavior or can be reviewed, validated, and maintained over time.
What made this workflow effective was not the ability to generate artifacts, but the way engineering intent was made explicit early and carried forward through planning, model construction, parameter definition, and testing. That continuity created clear review points before assumptions became embedded in executable models, reducing the risk that ambiguity would propagate unnoticed.
That matters most in safety- and certification-driven environments, where teams need more than a working result. They need evidence they can inspect, test, and use to support engineering decisions and sign off. But the same principle applies well beyond regulated domains. Any team building complex engineered systems depends on traceability, reviewability, and shared understanding to support collaboration and long‑term reuse. This is supported by tools like Simulink Agentic Toolkit, which gives AI-coding agents Simulink-specific context and workflow guidance. That grounding helps agents operate within the engineering process rather than relying on their general language-model knowledge alone.
Workflows that give AI agents access to engineering context and structure help reduce the hidden friction between what an AI agent can produce and what engineers need to trust, approve, and stand behind the result.