An LLM Agent That Does Your System Identification Homework — and Documents Its Reasoning for Under $4

ASPIRE wraps an LLM agent around nonlinear system identification, producing closed-form models with documented reasoning. 30/30 runs valid, $0.96–$3.38 each. The real question: can it match a domain expert?

Imagine you hire a junior engineer to build a mathematical model of your robot. You hand them sensor data, maybe a sketch of the physics, and say 'figure it out.' They pick a modeling method, fit parameters, write up what each term means, and hand you a report. If they're good, you get a usable model with clear documentation. If they're mediocre, the model works but the write-up fudges why certain structure choices were made. ASPIRE is that junior engineer, except it's an LLM agent — and its most honest failure mode is exactly the one you'd expect from a confident but inexperienced modeler. The committed claim: an LLM agent can autonomously select and execute nonlinear system identification methods on real measured data, producing closed-form dynamic or static models with interpretable documentation, at commodity cost. This is not a toy demo on synthetic data. The three test systems — a mobile robot, a rotational system with dry friction, and a laboratory fermenter — are real physical systems with real measurement noise. Each was tested with and without a system description, five runs per configuration, yielding 30 total runs. All 30 produced valid models. The quality assessment is where things get interesting. The authors evaluated 150 items across the 30 recommended models (five quality dimensions per model). Of those 150, 132 were fully satisfied and 18 partly satisfied — zero outright failures. But the most common partial failure, appearing in 9 of 30 models, was 'inaccurate or unsupported claims about model structure selection.' In plain language: the agent picked reasonable models but sometimes confabulated the justification for why it picked them. This is the LLM hallucination problem wearing an engineering lab coat. The model works; the reasoning paper trail doesn't always hold up to scrutiny. Architecturally, ASPIRE sits in the LLM-as-agent family — the model doesn't do the math itself but orchestrates existing identification methods (likely symbolic regression, least-squares variants, and standard nonlinear fitting routines) through tool use. The LLM handles method selection, prompt construction, interpretation, and documentation. The physical requirements verification is done independently of the agent, which is a smart architectural choice — it means the agent can't grade its own physics homework. The framework supports both autonomous and interactive modes, letting users steer or request additional identification rounds. The cost numbers are the headline engineering result: $0.96 to $3.38 per run. That's the API cost for the LLM calls, not including compute for the actual fitting, which is presumably negligible for the system sizes tested. For context, a human expert doing the same task — choosing methods, fitting models, writing documentation, validating — would bill hours to days depending on the system. The question is whether the 12% partial-satisfaction rate on documentation quality is an acceptable trade for three orders of magnitude cost reduction. What's missing is a direct head-to-head against expert-built models on the same systems. The authors — who are themselves the domain experts — assessed quality, but we don't see 'here is the expert model, here is ASPIRE's model, here are the prediction errors side by side.' We also don't see scaling: the three systems tested are well-studied laboratory setups. The fermenter is the most complex, but none approach the dimensionality or chaos of real industrial systems. The 30/30 valid-model rate is impressive but the denominator is small and the systems are friendly. The framework's real contribution may be less about replacing experts and more about democratizing the first pass. A controls engineer who isn't a system identification specialist could use ASPIRE to get a reasonable starting model with documentation, then refine from there. That's genuinely useful — most system identification in practice is done by people who aren't specialists in it, and the gap between 'no model' and 'reasonable first model with documented assumptions' is where most projects stall.