The Case Against Rebuilding Everything as Agents

Consider a real-world scenario in which a structural engineer drags a node into a parametric model. He updates geometry, solves the constraints, and redraws the stress contours. The entire process takes 40 milliseconds, and the engineer's hand is already on the next node.

Now imagine routing that operation through an AI agent. The LLM agent analyzes the engineer’s intent, calls the geometry kernel, waits for the response, reasons for the constraints, and generates an explanation. The engineer's hand is still on the mouse. The geometry has not updated. Stress contours are not redrawn. Somewhere along the way, the LLM agent may have hallucinated a constraint that doesn't exist.

This is what happens today as most engineering software firms race to wrap artificial intelligence agents around workflows that didn't ask for them.

I think the industry is making a category mistake. Not about whether agents are useful, they clearly are, but about where they belong. And the cost of getting it wrong is not theoretical: slower software, less predictable behavior, hallucination risk in places hallucinations don't belong, and complexity layered on top of tools that already worked.

The decision intelligence layer I argued for in the previous piece is itself agent-appropriate work. That is exactly why the discipline of where the agent layer belongs matters to me.

Read the previous blog on decision intelligence here:
https://www.cctech.co.in/blog/from-design-to-decision-intelligence-in-engineering-workflows

Where agents fail

Now consider what happens when you force an agent onto work that doesn't require it:

Real-time CAD geometry operations - When a structural engineer changes a parametric model, each step has a clear, correct answer. Speed is important, and feedback loops make CAD work well. Adding an LLM agent here just slows things down, makes results less predictable, and can even create errors. The tool already works as it should, so an agent only makes it worse.

Regulatory compliance pipelines. A building permit submission must comply with a specific regulatory code. The rules are written down. The compliance check is deterministic, leading to either the design meeting the setback requirement or not. This situation demands a rule engine that is fast, auditable, and consistent, with zero risk of hallucination. An LLM-based agent checking compliance introduces confidence intervals where the regulator wants binary answers. The agent doesn't make this better. It makes it worse and creates liability exposure that the agent layer was never designed to handle.

File-format and data-schema conversions. Many engineering interop tasks have clean, deterministic specifications. EPANET INP parsing. STL-to-OBJ mesh conversion. DXF header transformations. CSV-to-database loads. These have right answers. They are not interpretation problems. A purpose-built parser is faster, cheaper, exhaustively testable, and immune to hallucination. An agent that "translates" between formats is reinventing badly what compiler writers solved fifty years ago.

This pattern keeps showing up. Agents add complexity when tasks are predictable, speed is important, mistakes are costly, or when you need clear records instead of explanations. Sometimes, they even make things worse.

What Agents do Best

Agents may be trusted by developers in the following three situations:

First, LLM agents are useful when the work is truly open-ended and needs interpretation. If a mechanical engineer asked, "What bracket geometry meets this load case while minimizing material," they weren’t just asking a simple command. They were describing a problem with many possible answers. Solving it would require an agent that could use a topology optimization solver, consider stress and manufacturing limits, and explain which options are best and why.

The second is cross-tool orchestration. The engineering questions that are interesting in terms of cross-product lines. "Does the drainage design in InfoDrainage handle the rainfall pattern in this regional climate model, given the structural load from the BIM model, at the cost shown in the quantity takeoff?" No product has an answer. An agent that knows how to call on the right specialist tools, capture their output, and synthesize an answer is doing the work discussed in the last piece of this series, the decision intelligence layer.

Third, LLM agents are very helpful when it’s more important to move quickly than to avoid every mistake. In early design stages, engineers expect to review and check the results. A wrong answer doesn’t cost much, but a fast, correct answer is very valuable.

The taxonomy nobody's drawing

There are three categories of work in engineering software workflows.

Agent-appropriate work: Agent belongs to open-ended interpretation, cross-tool orchestration, design decision support, and knowledge synthesis across unstructured sources. As I wrote in my previous blog in this series, the decision intelligence layer is used for decision-making.

Rules-and-engines work: Agents complicate regulatory compliance, constraint checking, code validation, and structured data transformation. Rule engines and specialist tools win here.

Pure execution work: Geometry-based operations, file conversions, and simulation runs are deterministic, latency-sensitive, and intolerant of errors. The tools you are using are correct. There is nothing to gain by adding an orchestration layer with agents.

The discipline the industry is missing is the discipline to sort workflows into these categories before deciding what to build. Instead, the incentive structure pulls at agents everywhere because agents are the story investors fund, features users want, and modern capabilities. Thus, LLM inference calls are added to hot paths that should run deterministically, increasing the risk of hallucinations in workflows. A single wrong answer can have far-reaching engineering consequences.

What discipline looks like in practice

A company looking to innovate doesn’t simply add agents to everything. It focuses on how its workflows fit into the right category and only uses agents where they really add value.

Three questions for each user-facing operation: Is this work interpretive? Does it cross tool boundaries? Is the cost of imprecision low enough that speed is more important than accuracy? All three are yes, and an LLM agent has a place. With one “no,” there’s the answer we’ve been looking for: a purpose-built tool that will have an agent in front of it as a natural language entry point, but never with an agent replacing it.

The firms that develop this discipline will outbuild the firms that don't. Not because they use less AI, but because they use AI where it pays. The hallucination tax compounds when agents are inserted into deterministic paths. The agent-trust budget gets spent on the wrong workflows. By the time the firm wants to use agents for the hard, valuable problems - the decision intelligence layer, the cross-tool orchestration, the open-ended design exploration - the agent has already burned its credibility on a CAD operation it should never have touched.

The case for agents in engineering software is real. The case against rebuilding everything as agents is the same case, told honestly. The firms that can tell both stories at once are the ones that will still be standing when the agent hype cycle ends and the actual architecture remains.