Overcoming Automation Bottlenecks with Agentic AI

TL;DR

Engineering workflows are generally expensive. They consume far more than compute time or CPU cores. Significant effort goes into preparing inputs, making decisions, validating intermediate results, handling failures, and waiting for the few engineers who know how to deal with exceptions.

The result is engineering time spent on work that does not directly advance the analysis, inefficient use of people and infrastructure, and unoptimized cost per run.

Traditional automation can reduce this cost, but only for the cases its authors anticipated; anything outside that envelope still falls back to manual work, consuming engineering time and infrastructure inefficiently.

In this blog, we look at how agents can improve these workflows by reducing manual intervention, making better use of engineering resources and compute infrastructure, and extending automation to cases that would otherwise require expert intervention. We also examine the trade-offs this introduces, particularly around cost, reproducibility, and verifying the decisions an agent makes.

What is a workflow?

Consider a team running external aerodynamic studies across multiple vehicle design iterations. A typical design change request might involve a revised mirror housing, a change in ride height, or a new underbody panel. While the CFD solve may run overnight on a cluster, most engineering effort happens in the stages preceding the solve. Such as, importing and repairing CAD, deciding what geometry matters, generating and validating the mesh, defining boundaries, and setting up operating conditions. A study that takes one night to solve can require one to two weeks of engineering preparation.

This creates the following problems:

Cost. The compute run may take hours, but each design iteration also requires engineering time for geometry preparation, meshing, setup, and review. That effort is repeated across variants and can become a significant part of the cost of running a study.

Time. For iterative aerodynamic development, the bottleneck is often getting a design variant ready to run. If preparation takes days, only a limited number of variants can be evaluated within a program milestone, regardless of available compute capacity.

Throughput. In a multi-team workflow, the number of studies that can progress in parallel is constrained by the capacity of the slowest stage. If several design variants are waiting for geometry preparation, meshing, or review, additional compute capacity does not increase overall throughput.

Training. The preparation work often relies on experienced analysts who know how to simplify geometry, judge mesh quality, and diagnose setup issues. When those engineers spend their time on repetitive case preparation, less time is available for mentoring and transferring that knowledge.

Standardization. Each analyst may make slightly different choices when preparing a variant, including what geometry to simplify, how to mesh it, how to configure the case, or how to organize results. Over many iterations, this variation makes comparisons and reuse of historical simulation data more difficult.

These problems arise from inefficiencies in the workflow.

A workflow is simply a sequence of dependent stages, where each stage produces something the next one needs. Some are easy to automate because their inputs, steps, and outcomes are predictable. Others are harder because decisions at one stage depend on what was discovered earlier.

Three properties largely determine how difficult a workflow is to automate.

• Acceptance conditions are often implicit. An experienced analyst may reject a mesh within seconds based on patterns learned from years of failure modes, yet take much longer to explain exactly why. That judgement is rarely captured as a formal rule, creating a knowledge-transfer bottleneck.
• Faults rarely originate where they become visible. An early decision can produce a symptom several stages downstream. Debugging therefore requires tracing the failure back to the stage that introduced it, rather than simply fixing where it appeared.
• The said stage is rarely the most time consuming one. Most effort accumulates in preparation, format conversion, validation, and handoffs. For example, geometry built for manufacturing may contain details irrelevant to the analysis, leaving the analyst to decide what can be simplified before the actual analysis can even begin.

Automating a workflow

Automation of engineering work is not new. Teams have used journal files, macros, batch jobs, build pipelines, and ETL processes for decades to automate work that follows a known pattern. The idea is simple: define the steps once and run them again for new inputs. When the work is repetitive and the inputs are well understood, this is still the best approach. A deterministic script is faster, cheaper, easier to validate, and easier to reproduce than something that introduces decision making into the workflow.

Our recommendation for teams that have not yet automated the repeatable parts of their workflow is to start there before evaluating agents. Scripting forces the workflow to be made explicit and provides a useful baseline: how long a case takes, which steps are repeatable, and where engineering judgement is required. Without that baseline, introducing an agent means automating the existing variability as well, making its impact harder to measure and its decisions harder to evaluate. The parts of the workflow that cannot be reliably scripted are where an agent can add value.

The limitation becomes most apparent at the edges of the input space. A script encodes the assumptions its author made when it was written and follows the same path for every input. If an edge case violates one of those assumptions, the script may not recognize it as unusual. It can process the case successfully and produce an output that looks valid, even though an earlier decision was no longer appropriate. These are the cases that can go unseen, because nothing in the execution itself necessarily signals that the workflow has left the range for which it was designed.

When a case falls outside that envelope, the script may either stop or complete successfully with a plausible but incorrect result. The latter is more dangerous because the problem may only become visible downstream, often during review.

This is why scripted automation is typically trusted within a defined operating envelope, with human review reintroduced when a case falls outside it. As the workflow evolves, new inputs, tool versions, and requirements add more branches to the script, making the boundary of what it can reliably handle harder to maintain. The reasoning behind those branches also often remains with the engineers who introduced them.

The goal is not to replace scripts. Deterministic stages should remain scripted. The opportunity is at the boundary, where edge cases and unexpected intermediate results require a decision based on the state of the current case.

What is an Agent?

The term agent is used in several contexts, including reinforcement learning, so it is worth clarifying what we mean here. In reinforcement learning, an agent learns a policy through repeated interaction with an environment, with its behaviour shaped by a reward function.

The agent discussed here does not learn during a workflow run: its weights remain fixed, its objective is provided as a written brief, and its capabilities come from pretraining. The two share the basic idea of observing a state and choosing an action, but differ in how that behaviour is produced and evaluated.

An LLM agent operates as a closed-loop system. It selects a tool, executes it, observes the resulting state, and uses that observation to determine what to do next. The loop continues until the agent reaches a defined outcome or determines that the workflow cannot proceed.

The tools themselves are not fundamentally new. They can be a shell, file reader, search interface, domain-specific application, plotting library, or any other software the agent can invoke. What changes is the control layer above them. The same construction can therefore be applied across very different domains without requiring the underlying tools to be redesigned.

The important difference is where the decisions are made. In a scripted workflow, the execution path is largely determined before the run begins. In an agentic workflow, the path is selected incrementally, based on the state the workflow has actually reached. An intermediate result can therefore change what happens next, including whether an earlier assumption needs to be revisited.

A comparison makes the distinction concrete. A scripted validation step typically treats its output as a binary condition: it either ignores the report entirely or checks it against a predefined set of strings, thresholds, or exit codes. An agent can instead interpret the report in the context of the current case. It can identify which warnings are relevant, assess their likely impact, and decide whether to proceed, modify the current setup, or return to an earlier stage with a targeted change to a specific parameter.

A comparison makes the distinction concrete. Both are handed the same validation report at the same point in the workflow.

Scripted vs Agent driven automation

In simulation, mesh quality is a useful example. A quality check can return dozens or hundreds of warnings, many of which are acceptable for the physics and geometry being modelled. The difficult part is distinguishing those from the few that indicate a mesh is likely to compromise the solution. An experienced engineer makes that assessment using the geometry, operating conditions, solver requirements, and prior experience with similar failure modes. That ability to distinguish a harmless warning from a consequential one is a significant part of engineering expertise.

Every complex workflow contains decision points like this: an intermediate output may be technically valid, but still require domain knowledge to determine whether the workflow should proceed and what should happen next. This is where fixed automation starts to become difficult to extend.

The table above illustrates the trade-off between control and flexibility. A free-running agent is given a goal and a set of tools and decides the rest, including which stages to perform, their order, and when the work is complete. This gives it considerable flexibility for unfamiliar cases, but makes individual runs harder to compare because the execution path can vary. A rigid workflow does the opposite: the stages and their order are fixed in advance, making runs predictable and comparable, but leaving little room to respond when a case falls outside what was anticipated.

There is a third option: keep the workflow structure fixed, but introduce agentic decision-making within individual stages. The stages, their order, and the conditions for accepting each stage are defined before the run begins. Within those boundaries, an agent decides how to reach the required outcome using the tools available to it. This preserves the structure needed for consistency and comparison while allowing the workflow to respond to cases that were not explicitly anticipated.

The third arrangement keeps the structure and moves the freedom inside it. The stages, their order, and the condition for accepting each one are fixed before the run begins. Within a stage, an agent decides how to reach that acceptance condition using whatever tools it has. A run remains comparable to every other run because it passed through the same stages in the same order, and it can still absorb a case nobody anticipated, because the work inside each stage was chosen while the run was in progress. This is the arrangement worth building, and it is the one the rest of this article describes. It also raises the obvious question. Fixing an acceptance condition for every stage means that stages will sometimes fail to meet one.

What happens when a stage fails its acceptance criterion?

The three arrangements discussed above differ most visibly at a point where a stage fails. A script that fails simply stops, and someone has to figure out what went wrong and pick the workflow back up. An agent can inspect the failure, form a hypothesis about the cause, make a targeted change, and continue from there.

For that recovery to be useful, two conditions matter: First, the failure needs to contain enough information to suggest what should change. A review step that only says "mesh quality failed" is not enough; the agent needs to know which metric, region, or constraint caused the failure. Second, recovery needs to go back to the stage that introduced the problem, which is often not the stage where the failure becomes visible.

A solve that diverges because of a sliver in the original geometry will not be fixed by tightening under-relaxation. It may suppress the symptom for a few hundred iterations, making the run look healthier while leaving the geometry problem untouched. The broader failure mode is fixing the stage that reported the problem rather than tracing the problem back to where it was introduced.

Orchestration with specialized agents

Consider how a competent engineering team handles the same work. Nobody expects one person to own all the stages end to end. The work is divided by specialism, each handoff carries an implicit definition of what is good enough for the next stage, and someone has to decide what happens when a reviewer rejects an output. An orchestrated system makes that structure explicit in software. The control layer takes on the role of coordinating the stages, interpreting review outcomes, and deciding where rejected work should go.

Instead of giving one general-purpose agent responsibility for the entire workflow, an orchestrated system assigns each stage to specialised agents. The pipeline discussed here uses eighteen agents across five stages. Most stages have a single agent. Boundary-condition assignment uses three agents, because it benefits from separating the work: one agent reads and interprets the case, another applies the values, and a third reviews both before the stage is accepted. The other four stages terminate at a reviewer gate that can either approve the output or reject it with findings.

These gates are what make the system recoverable. When a reviewer finds a problem, the stage can be run again with those findings passed directly to the agents responsible for it. If the reviewer determines that the problem originated further upstream, the run can be routed back to the relevant earlier stage rather than forcing the downstream stage to compensate for it. If a stage cannot recover the case, the pipeline can return to planning, with the findings given to the planner rather than repeatedly passed through every agent in the workflow. Every recovery path is bounded as well, because an unrestricted retry loop is a system that can quietly consume compute and run indefinitely.

Closing

The shift from scripts to agents changes the main engineering challenge. With scripts, the challenge is coverage, anticipating cases and writing branches to handle them. With agents, the system can handle cases that were never explicitly anticipated. The harder problem becomes verification.

An agent can adapt to an unfamiliar case and still produce a result that is complete, plausible, and wrong. This means evaluation needs to look beyond whether the workflow finished:

• Completion is not correctness. A run can finish successfully and still have an incorrect setup or result.
• Results must be traceable. Reported values should be recoverable from artifacts produced by the run, not just from the agent's own summary.
• The execution path matters. Two runs can produce the same result while reaching it through very different and not equally valid paths.
• Recovery must be justified. A retry is meaningful only if the agent identified and addressed the underlying cause rather than masking the symptom.
• Infrastructure failures are not engineering failures. Timeouts, unavailable tools, or refused requests should not be treated as findings about the quality of the engineering work.

Part two focuses on how to evaluate agentic workflows against these requirements: not just whether they complete, but whether they make sound decisions, recover for the right reasons, and produce results that can be trusted.