Automation without verification just ships wrong answers faster

Here is a failure mode we hit in an automated simulation study, and why it did not end up in the client's report.

A post-processing step had a sign-convention error. A force-and-torque integration came out with a flipped sign, the kind of mistake that is easy to make when your solver, your mesh tool, and your reporting code each define "positive" differently. The number was not noise. It was a clean, confident, wrong value.

In a fully automated pipeline with no checks, that value would have flowed straight through: from the solver, into the aggregation step, into the summary table, into the PDF, onto someone's desk. Automation does not hesitate. It does not squint at a torque pointing the wrong way and think "that cannot be right." It formats the number nicely and moves on.

What caught it was a verification step whose only job is to ask whether the physics is plausible. A torque that opposes the rotation it should be driving, a drag force pointing upstream, a lift that does not scale with angle of attack: these are cheap to check and expensive to miss. The check flagged the inconsistency, we traced it to the sign convention, fixed it, and the report shipped correct.

Automation amplifies whatever you feed it

The uncomfortable truth about automating engineering work is that speed is not selective. A pipeline that can produce a correct answer in twenty minutes can produce a wrong one just as fast, and with the same polished formatting that makes it look trustworthy.

Manual workflows have accidental safety nets. An engineer running a case by hand sees the residuals, notices the mesh looked strange, remembers that this geometry usually gives a different number. Those instincts are friction, and automation removes friction. Remove the human staring at intermediate results and you remove the person who would have caught the flipped sign.

So the question is not "can we automate this?" Almost always, yes. The question is "what replaces the judgment we just automated away?"

Verification is the whole game

Our answer is that agentic simulation is only safe when the agents check each other, adversarially, at every stage. Not a single QA pass bolted on at the end, but checks embedded where mistakes are actually made:

• Geometry review: is the CAD watertight, correctly scaled, and oriented the way the boundary conditions assume?
• Mesh QA: are cell quality, aspect ratio, and boundary-layer resolution within bounds for the physics being solved?
• Solver QA: are boundary conditions, turbulence model, and numerical schemes consistent with the case, and are they what the study actually called for?
• Run monitoring: are residuals converging and forces settling, or is the case quietly diverging toward a plausible-looking but meaningless number?

Each of these is a place where a confident wrong answer can be born, and each gets its own reviewer. The reviewers are not there to rubber-stamp. They are there to disagree. A geometry agent that never rejects a geometry is not doing its job.

Why "adversarial" matters

A checker that shares the same assumptions as the thing it checks will miss the same errors. If your post-processing defines torque one way and your verification uses the same convention, the flipped sign passes both. The value of a separate verification step comes precisely from it reasoning independently, from physical first principles, not from the pipeline's internal bookkeeping.

That is what a physical-plausibility check does. It does not ask "did the code run?" It asks "does this result obey the physics we know must hold?" Conservation, expected signs, order-of-magnitude sanity, monotonic trends where trends must be monotonic. These are the checks a good engineer runs in their head, made explicit and repeatable.

The error and the cost are asymmetric

A sign flip is a small bug. Finding it after it has shipped is not a small problem. Once a wrong number is in a report, it does not stay in the report. Someone sizes a motor against it, sets a safety factor from it, or greenlights a design review on the strength of it. The cost of the error grows the further downstream it travels, while the cost of catching it stays flat, a cheap check at the point where the number was produced.

This is the asymmetry that justifies verification. A physical-plausibility check costs a few seconds of compute and a few lines of logic. A wrong result that reaches a design decision costs a redesign, a schedule slip, or worse. You are trading a tiny, certain cost now against a large, uncertain cost later, which is exactly the trade a good engineering process should always take.

It also matters where the check sits. Catching the flipped sign in post-processing is cheap. Catching it after the summary table has been built means re-running the aggregation. Catching it after the PDF has gone to the client means an awkward correction email. The earlier the reviewer sits in the chain, the less the error costs to unwind, which is why the checks belong at each stage rather than in one pass at the end.

What this means for building agentic CAE/CFD

The reason we build agentic simulation the way we do, with review agents at the geometry, mesh, solver, and run stages, is not to add ceremony. It is because we have watched automation propagate a single upstream error into a finished deliverable, and we have watched a verification agent stop it before it shipped.

If you take one thing from this: the value of an automated simulation pipeline is capped by the quality of its checks. An unchecked pipeline is not faster engineering, it is faster risk. The checking is not overhead wrapped around the real work. The checking is the real work.

That is the philosophy behind how we build agentic simulation at Curlscape, and you can see examples of it in the Lab.

Speed without verification does not get you to the answer sooner. It gets you to the wrong answer sooner, and then asks you to trust it.