Overcoming Automation Bottlenecks with Agentic AI

TL;DR

Engineering workflows (or, in other words, automation scripts/suites) are amazing to have, since they save a lot of time and result in massive gains in efficiency. At the same time, they are expensive to build, maintain, and scale.

The software stack in an enterprise gets updated periodically, requiring us to update the workflows along with it. Things become even more complicated when the engineer who built the workflow 10 years ago leaves the organization.

Generative AI can enhance workflows by interpreting unstructured inputs and interacting with software tools. Agentic AI goes a step further, using these capabilities in a closed loop to observe, decide, act, and adapt.

In this blog, we talk about how agentic AI differs from conventional workflows, where each approach works well, and the pros and cons of using one over the other. We close with the new challenges that agentic AI brings to the table.

The world without automation

Consider a team running external aerodynamic studies across multiple vehicle design iterations. A typical design change might involve a revised exterior, a change in ride height, or a new underbody panel. While the solve may run overnight on a cluster, significant engineering effort happens before the solve. This includes importing and repairing CAD, simplifying geometry, generating and validating the mesh, defining boundaries, and setting up operating conditions.

Many of these tasks, such as meshing and solver setup, are repetitive and can be automated. It reduces the time spent on repetitive work, and makes the process more consistent across analysts and teams.

Automating this process requires:

1. Deep knowledge of automation tools

2. Deployable environment where the scripts can live

3. Most importantly, the scripts must always follow a sequence of independent steps that work almost in all situations.

Where to start if you are new to automation

Automation of engineering work is not new. Teams have used journal files, macros, batch jobs, build pipelines, and ETL processes to automate work that follows a known pattern. The approach is simple: define the steps once and run them again for new inputs.

For teams that have not yet automated their workflows, this is where to start.

This gets you to have some structure in execution. Further, it also has the following benefits:

1. Scripting makes the process explicit and provides a baseline for understanding how long a case takes, which steps are repeatable, and where engineering judgement is still required.

2. It also gives us a clear way to identify where conventional automation is less effective.

As workflows evolve, supporting more cases typically means adding more rules and branches to the script. Over time, this makes the automation harder to maintain and its operating envelope harder to define. The opportunity, then, is to introduce decision-making where deterministic scripting reaches its limits, which brings us to AI agents.

Agent-driven workflows

The term AI agent is used in several contexts, including reinforcement learning, so it is worth clarifying what we mean here. The AI agent discussed here is an LLM that has the capability to execute tools in addition to producing text only. More information can be found here. It is highly encouraged to read through this article since a lot of terms used below assume a basic knowledge of AI agents.

This is the key difference from a scripted workflow. In a script, the execution path is largely defined before the run.

In an agentic workflow, the path is selected intelligently based on the state of the current case.

Below is a table that offers some information on differences of execution.

The trade-off between flexibility and control for Agentic AI

Fully autonomous agents offer the most flexibility, but their execution can be harder to predict and validate.

At Curlscape, we have built and tested both the agent driven and script based automations for various use cases like CAD creation, CFD design automation etc.

Based on our learnings, we have architected and built hybrid agents, which take best of both worlds in terms of automation.

• Low cost and Low ROI (Un-automated):
  • Low cost of operations and least benefits.
  • You can start here and slowly automate the workflow
• Low cost and Mid-High ROI (Automated Workflow):
  • Automation can bring about efficiency and bring in repeatability/traceability
  • Fails when underlying systems change - such as upgraded software
• High cost and Low-Mid ROI (AI Agent):
  • AI agents are great to spin off quickly
  • The cost of operations are very high, especially for very high volume
  • Stochastic outputs are the major cons
  • Need a very strong evaluation harness for trusted and repeatable outcomes which is difficult for safety critical nature of the engineering workflows
• Mid-High cost and High ROI (Hybrid Automation):
  • Brings in the intelligent decision making in workflow
  • Cost of operations is low due to AI not being used all the time
  • Underlying tools/softwares can change because AI agents can self-correct in failure terms
  • Reduces the stochasticity with defined workflows

How are edge cases handled in production?

The hybrid approach keeps the workflow structure and acceptance criteria fixed, while giving the agent flexibility in how it meets them. But what happens when a stage still fails its acceptance criterion?

This is where the ability to reason about the current state becomes useful. A script typically stops and requires an engineer to diagnose the problem, while an agent can inspect the failure, form a hypothesis about its cause, make a targeted change, and retry the stage.

For this recovery to work, the failure needs to provide enough information to act on. “Mesh quality failed” is not enough. The system needs to identify what failed, where, and why. It should also trace the problem back to the stage that introduced it, rather than simply trying to fix where the problem became visible.

For example, if a solver diverges because of a sliver in the original geometry, changing solver settings may only mask the symptom. Effective recovery means identifying the root cause, correcting it at the right stage, and then continuing the workflow.

But this introduces a new question: how do we know the agent made the right decision and that the recovered result can be trusted? This is where evaluation becomes critical.

How to know if the results can be trusted?

The edge case handling discussed in the previous section brings us to the main challenge with agentic workflows: verification and validation.

Scripts focus on anticipating cases and defining rules, while agents can respond to cases that were not explicitly anticipated. The challenge is now verifying that those decisions are sound.

Evaluation needs to look beyond whether the workflow finished:

• Does the underlying physics hold? And does it fit well in the overall scope of what is being achieved?
• Is the result correct and traceable? It should be supported by the artifacts produced during the run.
• Was the path taken to avoid error valid? The agent should address the root cause, not just the symptom.
• Can we distinguish engineering failures from infrastructure failures? A timeout or unavailable tool should not be treated as an engineering failure.

In the next blog, we will look at how to evaluate agentic workflows and determine whether an agent is making sound decisions, not just completing the task.