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. Figure 1: The agentic loop: User enters prompt -> Agent selects approved function(s) -> Functions execute -> App displays results -> User reviews results. (Source: MathWorks) 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