The most uncomfortable observation about agentic AI in engineering domains is that, by default, the agent is doing the wrong job. Ask a Copilot or Claude Code instance to diagnose a fault in a motor controller’s flux observer, and what you get back is — at best — literary criticism on the symptom: a pattern match against text the model has seen describing similar faults, presented with a confidence the model has no business having. The agent never tested anything. It has no access to the physics. It cannot ground its hypothesis in execution. The result is a guess dressed up as an analysis, and the gap between that and a useful engineering tool is the gap this monograph is about.
The fix is not a bigger model. It is the physics sandbox — an architecture that puts a real simulator (FMU, Simscape, GT-SUITE, or any combination) on the other end of an MCP tool surface, so the agent’s hypothesis can be tested against executable reality before it ever reaches the engineer who has to act on it. The architecture is three layers: a physics oracle (the simulator), an MCP server (the protocol layer that exposes the oracle’s capabilities to the agent), and the agent itself (the LLM that’s now reasoning against ground truth instead of against its priors). Add tiered fidelity (explore cheap with reduced-order models, verify expensive with full FMUs) and you have a workflow that’s both fast enough to use interactively and rigorous enough to put your name on.
This is one of the more directly job-adjacent posts on this site. The motor-control / VHM / propulsion examples are the working domain; the architecture generalizes to any engineering field where simulation already exists but is currently disconnected from the agent layer. The natural companions are the Why Agentic AI Fails field guide (the grounding-failure lesion is precisely what this architecture addresses), the API · CLI · MCP · ADK post (the protocol layer this whole architecture rests on), and the Loop Engineering field guide (since the inner loop of the sandbox — propose, simulate, observe, revise — is a feedback loop in the classical sense).
What it covers
Fourteen sections, about twenty-eight minutes of careful reading.
§ 01 — Why agents need a physics oracle. The grounding problem in concrete terms. A worked example of what a model-only agent produces vs. what a physics-grounded agent produces for the same prompt. The cost of literary criticism on the symptom in an engineering context.
§ 02 — Three layers, one protocol. The architecture, drawn. Physics oracle (the simulator at the bottom). MCP server (the protocol bridge in the middle). Agent (the LLM at the top). Why MCP specifically is the right protocol for this — the discoverability, the standardization, the cross-vendor portability.
§ 03 — Copilot ↔ MCP server ↔ MATLAB/Simscape. The concrete wiring. The actual handshake, with annotated traces. The data formats that flow between the three layers. The boundary discipline that keeps each layer’s failures from contaminating the next.
§ 04 — Tiered fidelity: explore cheap, verify expensive. The discipline that makes the workflow tractable. Reduced-order models for hypothesis generation (fast, cheap, approximate). Full FMUs for verification (slow, expensive, accurate). Decision-theoretic framing of when to escalate.
§ 05 — A minimal server you could run on Monday. The starter kit. About 150 lines of Python — a FastMCP server exposing three tools (simulate, step, compare) backed by a toy DC-motor model. Drop it onto your machine, point Copilot at it, and you have a working physics sandbox by lunch.
§ 06 — A working sandbox, in your browser. The interactive figure that runs in-browser. Drag the load torque slider, see the flux-observer error envelope respond. The proof-of-concept that the architecture isn’t theoretical.
§ 07 — Diagnosis as physics-refereed hypothesis testing. The workflow pattern. Symptom → hypothesis space → simulator-mediated rejection → narrowed hypothesis → root cause. The discipline that distinguishes “the agent thinks it’s the flux table” from “the agent has eliminated four other hypotheses by simulation.”
§ 08 — Patterns and anti-patterns. What works and what doesn’t. The “let the agent design the experiment, but reserve simulation triggers for human approval” pattern. The “agent decides which model fidelity to use” anti-pattern (don’t).
§ 09 — Choosing the physics engines. The trade-offs. FMI/FMU for portability. Simscape for the MATLAB-stack shop. GT-SUITE for propulsion-specific work. Python physics libraries (PyDy, scipy, custom) for prototyping. The decision matrix.
§ 10 — Practical notes before you build. The hard-won field observations. Cache simulation results aggressively (LLM workflows are repetitive). Log every simulation call (the audit trail is the future training data). Constrain the parameter space the agent can probe (otherwise it will probe the unphysical corners). The dozen habits that compound.
§ 11 — Where this bites in VHM. New in this revision. The Vehicle Health Management application. The specific failure modes in propulsion diagnostics where a physics-grounded agent is dramatically better than a model-only one. The integration with existing VHM telemetry pipelines.
§ 12 — A roadmap that fits in three quarters. New in this revision. The execution plan if you wanted to actually ship this. Quarter one — minimal server + one diagnostic skill. Quarter two — fidelity tiering + parameter-space constraints. Quarter three — fleet-scale rollout + the labeling-becomes-dataset loop. With the milestones and the realistic risk register.
§ 13 — Limitations and failure modes. New in this revision. The honest section. What this architecture cannot do. The simulator-reality gap. The cost ceiling when fidelity is the bottleneck. The cases where a model-only agent is still the right answer.
§ 14 — References & further reading. The relevant papers (the simulation-grounded agents literature is small but growing). The MCP spec. The FMI standard documentation. The handful of write-ups from teams who have shipped systems like this.
Read it
The monograph lives at its own URL with a warm-paper editorial layout — teal for physics / simulation, orange for the agent / action layer, violet for fidelity tiers. Fourteen sections plus an interactive browser sandbox and a minimal Monday-morning server example.
← Back to Autonomy