The optimization problem is not simply to run simulations faster. It is to spend the next simulation where the result could change what we do.

For an autonomous design agent, a simulator is both an instrument and a scarce resource. A workflow can be perfectly automated yet waste most of its budget confirming details that do not affect the next choice.

Assign different jobs to different models

A simplified circuit model can help reject implausible ideas. A surrogate can make a broad parameter search tractable. A lower-cost electromagnetic setup can investigate a local trend. A more demanding physical evaluation can test the candidate that will support the final claim.

Combining models with different costs and accuracies is the subject of multifidelity methods. My interest here is their role as an agent-facing engineering tool: not a second agent that takes over the design, but a service that helps choose informative evaluations.

Uncertainty must be tied to the decision

Suppose two candidates appear close under a cheap model. The important question is not only the model’s average error. It is whether its uncertainty could reverse the choice, violate a constraint, or conceal a failure mode.

A useful evaluation request therefore records the question being asked. Are we screening a family, estimating sensitivity, distinguishing two finalists, or checking an absolute requirement? These purposes justify different costs.

A decision-oriented request

“Determine whether the apparent matching improvement survives a more faithful physical model” is more useful than “run the fine simulation because this is the next stage.”

Keep the agent and the scheduler distinct

I would let the agent own the design intention and the proposal. The evaluation service would expose available fidelities, approximate costs, applicable domains, previous evidence, and uncertainty information where it can be justified.

The service can recommend an evaluation, but its recommendation should be inspectable. It should not silently redefine the objective, pick the final design, or upgrade a low-fidelity result into a sign-off claim.

This separation also keeps the tool reusable. A human engineer, a general-purpose agent, and a specialized optimizer should be able to ask the same evaluation service meaningful questions.

Reusing evidence requires identity

Simulation caching is useful only when we know what the cached answer describes. Geometry, ports, material stack, boundary conditions, solver settings, and the surrounding circuit can all be part of the identity of a result.

A cached response should remain attached to those conditions. Similarity can justify using a result as a clue; it does not make two evaluations identical. When a design has changed, the system must be able to distinguish a prediction about the new design from evidence measured on the old one.

Do not turn fidelity into a ritual

I do not favor a universal rule that every candidate must pass through the same ladder of solver settings. Some candidates can be rejected cheaply. Some require an expensive check early because the cheap abstraction omits the relevant effect.

At the same time, a constrained budget does not excuse weakening an agreed acceptance requirement. If the available budget cannot produce the necessary evidence, the honest outcome is an unresolved claim—not a cheaper definition of success.

The goal is a shorter path to a defensible engineering decision. A fast wrong answer is not efficiency. Neither is an expensive answer to a question we no longer need to ask.

Background reading

Ideas in progress. Corrections welcome.

Find me online