When Engineering Apps Need Agentic AI

Engineering teams often turn expert workflows into custom apps. That makes sense because a few engineers may own the analysis code, simulation model, or test workflow, while many more users need to run it, inspect results, compare cases, and make decisions from the outputs.

As these apps become broader team tools, the scale and breadth of the interaction start to matter. Users are working through more test and simulation data, and more of the value comes from the follow-up questions after the first result appears.

That raises an important question about agentic AI and engineering apps: when does it make sense to add an agentic front end to a grounded engineering workflow-one where the analysis, models, and functions already exist and are controlled by the workflow owner?

An agentic front end is an AI chat-style layer that sits in front of actions the app author has already approved. For example, the agent might call an approved function to display the high-temperature run or compare the baseline and high-temperature runs.

The agent is not deciding how the engineering analysis works; it is deciding which approved analysis action to take based on what the user asks. It cannot create a new analysis routine or change the underlying engineering. This is often referred to as an agentic loop: the user asks in ordinary language, the agent chooses from the available tools, the existing engineering code does the work, and the app shows the result for the user to review.

The practical promise is not to make the app open-ended. It is to keep the workflow governed while making the next approved step easier to ask for.

In conversations with our customers' engineering teams, MathWorks often sees a good approach already in place: a grounded workflow in which the engineering logic, models, and analysis functions are already defined and controlled by the workflow owner. A custom app can give users a guided process with inputs, plots, tables, and reports. The workflow owners keep control of the implementation, and the users, who may be on separate but related teams or across the organization, can run the analysis without editing the code or model behind it.

This works well when the path is known. Pick a file, choose the data, press the button, inspect the plot, export the report. But many workflows do not stay that neat. The challenge is that follow-up questions rarely follow a fixed path.

Users are looking at a result, deciding what to ask next, comparing cases, checking anomalies, and trying to understand what changed. The more exploratory the work becomes, the harder it is to cover every useful next step with another button, panel, or a large amount of branching UI complexity.

The underlying engineering workflow may already be well defined; what is difficult to define in advance is every question a user might ask about its results. That is where a grounded agentic front end can add value: it gives users a way to navigate the existing workflow without expanding the app into a map of every possible path.

Agentic workflows for battery test analysis

Suppose a test engineer is looking at battery lab data. There are several runs: a baseline case, a high-temperature case, and a degraded case. The test engineer may start with a simple prompt: show me the high-temperature run. After seeing the plot, the next prompt depends on what appeared in the data.

• Compare it with the baseline?
• Check it for anomalies?
• What stands out?

The test engineer can build all of that into a traditional app by giving the user a set of tools to work through the analysis.

• Add more buttons.
• Add a comparison panel.
• Add an anomaly tab.
• Add menus for follow-up questions.
• Add help text so users know where to find everything and what each button does.

MathWorks engineers have worked with our customers to build applications like this, and they can be the right solution. But at some point, the app starts to look less like a guide and more like a confusing map of every possible route. That slows users down, and it also puts more support and maintenance work back on the workflow owners. Buttons are great when the next step is obvious. They are less helpful when the user is staring at a plot and trying to decide what to ask next.

That agentic loop is the part that changes the interaction. The agent is not replacing the app, the underlying algorithms, or engineering judgment. It is changing how the engineer moves through approved steps. Instead of finding the right control, the user asks for what they want and the app carries out the next approved action. Then the user reviews the result and continues from there.

To make that concrete, consider a small battery lab assistant built in MATLAB to demonstrate the approach. The app has a chat panel on the left and analysis results on the right. The agent is allowed to list available runs, display a run, compare two runs, and run anomaly detection. Those are not arbitrary actions. Each one is an approved MATLAB function with defined inputs and outputs that the app author chose to expose. Those are the only actions the agent is capable of taking on behalf of the user.

Suppose the user wants to start by looking at the high-temperature run. They can prompt the app: show me the high-temp run.

This is the agentic loop in practice. The agent does not invent a way of displaying data. It calls the approved MATLAB function for displaying a run, using the high-temperature run as input. The app renders the outputs for the user's review. If the results lead toward a comparison with the baseline, the user can continue from there in natural language.

That is the user-facing part of the example. Underneath it, the app needs a way to run that agentic loop and connect each prompt to the approved MATLAB functions made available to the agent.

The MATLAB AI Agent SDK is the framework used for this example. The SDK helps build this kind of agentic loop inside MATLAB: connecting to a large language model, keeping message history, registering MATLAB functions as callable tools with defined inputs and outputs, and managing shared agent state. The exact code is less important than the shape of the design. The important step is deciding which MATLAB functions become tools available to the agent and what they return to the app.

In one sense, this is familiar. A traditional app already has approved actions behind its buttons and menus. The difference is that with an agentic front end, the author provides a written description of each tool to the agent, so the agent can pick between them based on the user's prompt. The user interface changes, but the approved engineering actions remain the boundary. The design choice is not only which actions to expose, but also what information the large language model receives: raw data, summarized results, metadata, or only the user's prompt and tool outputs. Those choices raise the right engineering questions.

• Which tools should be exposed?
• What data should be sent to the model?
• What should be logged?
• Where should human review stay in the loop?

Those are the questions engineering teams need to ask next because that is where the design work is.

An agentic front end should not be added to every app. If the workflow is linear and stable, ordinary controls are clearer. If the app has three actions and the design team knows when to use them, a chat panel probably adds more work than value.

The place to look for an agentic front end is different: the app author knows the set of actions but cannot predict every useful path through them. The next step depends on what result the user just saw. Battery test review is one example. Parameter studies, lab data checks, signal-processing reports, simulation result triage, and many other applications have similar shapes.

Extending grounded workflows with more flexible interfaces

Engineering apps already sit on top of grounded engineering workflows, and those workflows sometimes outgrow fixed controls. When that happens, the useful question is not "where can we add chat?" It is "which approved actions should users be able to do through chat?" Designing around approved steps changes the experience on both sides.

For the engineer who builds the app, there is less pressure to predict every possible next click. The author still controls the MATLAB functions, data, and outputs, but does not have to turn every follow-up path into another button, another panel, and more app complexity.

For the app user, there is less to learn before getting useful work done. They can ask for the high-temperature run, ask for a comparison, ask what changed, and stay focused on the engineering question instead of the mechanics of the UI.

The value shows up when the interface stays bounded but the path through it can change. Expert workflows can reach more users without turning every possible path into more UI to build, teach, and maintain.

Want to continue to explore where agentic AI fits in your engineering workflows? Contact Adam Filion, principal product marketing engineer at afilion@mathworks.com or check out this 14-minute video for an introduction to agentic AI in engineering: Can Agentic AI Develop Embedded Systems with Model-Based Design?

About the author

Adam Filion is a principal product marketing engineer at MathWorks focused on generative AI for MATLAB and Simulink. Over 16 years and seven roles at MathWorks, he has seen firsthand how engineers adopt new tools and workflows. Filion is a frequent presenter in MathWorks webinars and Tech Talks and holds BS and MS degrees in Aerospace Engineering from Virginia Tech.

The post When Engineering Apps Need Agentic AI appeared first on Embedded.