2026-09-17: Paper Summary: "A self-correcting multi-agent LLM framework for language-based physics simulation and explanation"

As stated in the paper, "A self-correcting multi-agent LLM framework for language-based physics simulation and explanation" [1], physics simulations are essential in science and engineering, but creating them often requires expert level knowledge of a variety of domains. For example, the development of a fluid simulation requires a strong understanding of the Navier-Stokes equations and the appropriate numerical solvers surrounding that area. In addition, users require proficiency in a programming language and familiarity with physics libraries, as building a simulation entirely from scratch is rarely, if ever, practical. The figure below illustrates the outcome of their research. Most notably, the user provides a basic ‘layman’ input and a basic set of parameters, while being afforded the luxury of omitting critical information required to develop a comprehensive solution. This is all accomplished using the Memory-Coordinated Physics-Aware Simulation (MCP-SIM), a self-correcting multi-agent framework producing a human readable output.

Figure 1: MCP-SIM Output

Traditionally, a “single-shot” has the anatomy of a user prompt, system prompt, and background information. Each of these components are combined to make up the context in which the Large Language Model (LLM) begins working on its output.

User Prompt: Initial input, request, and or instruction provided by a human user to the system. In this case, the type of physics simulation the user is looking to have created.

System Prompt: System instructions provided by the system’s designer helping define the context the LLM will use. It defines the persona, constraints, boundaries and ultimately the role before it processes any user input.

Background Information: Information that wouldn’t normally be stored within the LLM, but would be required to process the request.

Context: The collection of user prompts, conversation history, and additional environmental data produced by both the user and the model.

The primary limitation of this approach is the extensive information users must provide in their initial prompt. Furthermore, a single LLM is tasked with operating across multiple domains rather than maintaining a singular focus. This multidisciplinary scope introduces risks of cross-disciplinary terminology and variable confusion, further compounded by rapid context expansion that demands substantial VRAM to process.

To keep the system focused and to lower the barrier of entry for evaluating ideas, this paper introduces the MCP-SIM framework. This framework replaces simple one-shot requests that are sent to a singular LLM and instead builds a framework of multiple LLM based agents chained together in order to take advantage of an iterative cycle of expert evaluations. Each agent reviews the context, modifies, and enhances it to serve as input for the next. The cycle is defined by the figure below.

Figure 2: The MCP-SIM Iterative Cycle

MCP-SIM Core Architecture

The authors suggest an architecture that takes a user prompt and carries it through an assembly line of experts. Each expert adds or enhances based on their expertise to the context to produce a final output that is refined and constructed into a human readable format that’s delivered back to the user.

Figure 3: The MCP-SIM Workflow and Agent Collaboration

Specialized Agents

Input Clarifier Agent

The Input Clarifier is our Physics PhD Expert, and their job is to take a user’s input prompt and infer missing details such as domain geometry, boundary conditions, and initial conditions. A simple way to think of this agent’s purpose is that it generates a restatement of the layman’s description of the request and instead translates it to how a PhD’s view would define the request.

Code Builder Agent

The Code Builder Agent is an expert at writing Finite Element Computational Software (FEniCS) simulation code. Given the cleaned up prompt from the Input Clarifier, this agent then attempts to generate the appropriate simulation code.

Simulation Executor Agent

The Simulation Executor Agent’s job is to oversee the simulation. The Code Builder Agent delivered a set of blueprints for a FEniCS simulation and this agent’s job, for better or worse, is to see that they are executed to the letter. The code is executed and consequently evaluated for physical and numerical errors. At the end of this process, a quality assurance evaluation is performed and leads to one of two outcomes, on one hand, the simulation executes without critical runtime errors, syntax errors, or severe physical/numerical anomalies and the results are referred to the Mechanical Insight Agent. On the other hand, the simulation executes with a critical runtime error, syntax error, or a severe physical or numerical anomaly and is referred to the Error Diagnosis Agent.

Error Diagnosis Agent

The Error Diagnosis Agent is the clinician of the system. The Simulator Executor Agent detected an issue with the simulation, the executed code, collected the execution logs, tracebacks, numerical metrics, solver metrics, and any physical inconsistencies and referred them to be diagnosed. The Error Diagnosis Agent then determines whether it was an error in the code generation or an error in the PhD input. If the issue is determined to be an error in simulation code (most likely due to an error in the execution logs or the tracebacks), it is then resubmitted to the Code Builder Agent to attempt to correct the issue. However, if the error is with a simulation that fails to converge to a physical result, then the agent determines the issue is with its premise of the input and forwards the issue to the Input Rewriter Agent.

Input Rewriter Agent

The Input Rewrite Agent is the physics auditor of the framework. The Code Building expert did their job correctly and produced functional code, but the PhD overlooked a couple variables and possibly made a few mistakes. The auditor reviews the numerical and solver metrics, along with the physical inconsistencies and develops recommendations based on its findings. These findings are then forwarded to the Input Clarifier to rework the input into a more accurate description of the request and the process continues through the framework as before.

Mechanical Insight Agent

The Mechanical Agent is the multi-lingual publisher of MCP-SIM and its purpose is to generate a human readable report from the successfully run simulation.  The report includes an explanation of the physics behind the simulation, what equations governed the simulation and a graphically generated output from the simulator.

Performance & Benchmarks

Benchmarks

The evaluation of the MCP-SIM framework was built around 12 benchmarks, where each level increases in complexity. The complexity of each level is tuned with the amount of prompt completeness and modeling complexity. These tasks are divided into 3 tiers: Simple, Intermediate, and Challenging.

Figure 4: The 12 Benchmark Prompts used [2]

Simple (Level 1-4)

The lower third of benchmarks are all designed to be fully specified, single physics problems. In other words, the user is providing a superior amount of information, in terms of the type of simulation that they want developed, along with exact variable values.

Intermediate (Level 5-9)

The middle third of benchmarks contains prompts that are incomplete and require additional inference for properties like geometry, materials, and/or boundary conditions. A great example is L6, where the prompt is looking to create an L-Shaped 2D pipe and to use that as a constraint to simulate viscous flow. This is more challenging for the LLM, since the viscosity of the fluid isn’t specified, not any of the geometry of the pipe included. The LLM must infer these missing parameters to successfully generate a simulation.

Challenging (Level 10-12)

Lastly, the most challenging benchmarks introduce multi-physics scenarios with missing assumptions based on published problems without existing code. Here, the LLM is expected to not only choose geometric and other physical properties, but also choose the correct set of physics models. For instance, the piezoelectric deformation under voltage is a mixture of material properties with electrodynamics.

Quantitative Performance

The performance of the MCP-SIM framework was measured against three other baselines. The first being, B1, a submission of the user prompt to a Generative Pre-Trained Transformer (GPT) as a single-shot request. The other two were implemented as stepping stones towards the full MCP-SIM framework. B2 being a single-shot enhanced with the clarifying input, and B3 extending it further into error diagnosis.

Figure 5: Number of Iterations of Success (L1-L12)

As seen in the figure above, the single-shot GPT setup (B1) consistently fails once the benchmark complexity reaches L7. With the exception of L4, the number of iterations required generally increases complexity.

Adding the Input Clarifier (B2) results in a relatively consistent requirement of four iterations until L6 where it begins to increase quadratically after discounting the Levels in which it was unable to generate a solution.

Following the inclusion of the Error Diagnosis Agent, the B3 baseline maintains a stable interaction count up to L10, again discounting for Levels in which it was unable to generate a solution.

Most notably, the Full MCP-SIM framework was able to develop a solution in each of the 12 benchmarks. While maintaining a low number of iterations up to L10, it experiences an increase rather rapidly for highly complex tasks. Nonetheless, the MCP-SIM framework demonstrates a clear increase in performance over the other three model baselines.

Comparisons

Examining purely the outcome of whether or not a baseline generates a solution, we can see that each sub-component of the MCP-SIM adds an increase in performance to each baseline. B1 baseline successfully generates a solution for the entire lower half of levels.  The MCP-SIM framework significantly outperformed previous baselines, demonstrating that its self-corrective nature yields substantial performance gains.

Figure 6: Success Rate Across Baselines

Extending the Framework to Other Domains

Building upon the MCP-SIM framework, several extensions can be introduced to support a multi-domain expert ensemble capable of generating flight trajectories governed by physical dynamics and tactical mission objectives.  This modular architecture enables each agent to maintain a concise and specific context.  By restricting the context length, performance degradation in the language model is mitigated [3], thereby ensuring higher-quality outcomes.  Another advantage of this design is parallelism. Assuming the input clarifiers are mutually independent, any number (N) of them can execute concurrently depending on hardware availability, rendering the increase in execution time negligible.

Although primarily a human-systems interface (HSI) study, this multi-domain, multi-agent  implementation can be illustrated by modeling a system targeting objectives similar to those evaluated in the study "“Fly Like This”: Natural Language Interface for UAV Mission Planning"[2].  The synthesis of these papers is focused around generating two experts, the Aerospace Engineer and the Mission Engineer Agents.  Both are designed to refine the user’s request into a capable set of mission parameters that ultimately develop a valid and effective flight path through the use of an MCP-SIM type framework seen below.

MCP-SIM Type Framework

Figure 7: Proposed MCP-SIM Framework Update

Specialized Agents

As before, each agent’s system prompt would be clearly and concisely defined allowing a user’s input to be placed into the assembly line of experts.

Aerospace Engineer (Input Clarifier): Translates high-level aircraft configurations into aerodynamic specifications (stall speeds, turning radii, lift/drag constraints).  In addition, fuel or power usage rates of the aircraft would further constrain the full capability of the aircraft.

 

Mission Engineer (Input Clarifier): Translates high-level mission goals into optimized operational recommendations. To accomplish this, the agent would have to account for parameters such as terrain classification and geographical features, determining the most effective flight pattern for the mission.

Navigator (Path Generation): Given the limitations of the aircraft, this agent would generate a 3D Dubins flight path as defined by minimum turn radii, entrance and exit angles for each point.  Furthermore, the output of this agent would be the evaluation of the combinations of various flight path segments allowing the agent to choose the most efficient path, in terms of distance and/or the most efficient flight path in terms of mission success.

Figure 8: Representative Dubins paths "Implementing Dubins Airplane Paths on Fixed-Wing UAVs" [4].

Simulation Executor Agent: Tied into a simulation to flight the planned path by adjusting control surfaces of the aircraft. Locations at time (t) are tracked and logged

Error Diagnosis Agent: Reviews the logged data and determines how ‘on-course’ the drone was able to fly. If there are large divergences between the planned path and the executed path, it is examined and determined whether or not it was a fault in the Aerospace Engineer’s ability to determine flight characteristics or if the Navigator generated an impossible path to follow.

Flight Auditor: Upon a failed mission, this agent revises the input to be resubmitted to the set of input clarifying agents.  This is accomplished by adjusting mission parameters or switching aircraft types (if possible).  Could also recommend a change in the number of aircraft to be used or a change in altitude to perform the mission.

Record Generation (Mechanical Insight Agent): If the flight was successful, a report on the flight and its error (distance away from given path) as well as a graphical image of its journey is generated.

Conclusion

In this architecture, code isn’t necessarily generated, but a plausible flight path is determined based on aerodynamic features of the craft and what its designated mission is.  A successful implementation of this modified framework could serve as either a basis to study a multi-domain, multi-agent MCP-SIM based framework or as a fourth user interface to be studied further building upon “Fly like this”.  In either case, both avenues provide new areas of study on a path toward more robust and resilient interfaces.

- John Deasy

References

[1] Park, D., Moon, H. & Ryu, S. A self-correcting multi-agent LLM framework for language-based physics simulation and explanation. Nature Partner Journal Artif. Intell. 2, 10 (2026). https://engrxiv.org/preprint/view/4723 

[2] Chandarana, M., Meszaros, E., Trujillo, A., & Allen, B. D. (2017). "Fly like this": Natural language interfaces for UAV mission planning. In Proceedings of the Tenth International Conference on Advances in Computer-Human Interactions (ACHI 2017) (pp. 40–46). IARIA. https://www.researchgate.net/publication/313903668_Fly_Like_This_Natural_Language_Interfaces_for_UAV_Mission_Planning 

[3] Du, Y., Tian, M., Ronanki, S., Rongali, S., Bodapati, S. B., Galstyan, A., Wells, A., Schwartz, R., Huerta, E. A., & Peng, H. (2025). Context length alone hurts LLM performance despite perfect retrieval. In C. Christodoulopoulos, T. Chakraborty, C. Rose, & V. Peng (Eds.), Findings of the Association for Computational Linguistics: EMNLP 2025 (pp. 23281–23298). Association for Computational Linguistics. https://doi.org/10.18653/v1/2025.findings-emnlp.1264 

 

[4] Owen, M., Beard, R.W., McLain, T.W. (2015). Implementing Dubins Airplane Paths on Fixed-Wing UAVs. In: Valavanis, K., Vachtsevanos, G. (eds) Handbook of Unmanned Aerial Vehicles. Springer, Dordrecht. https://doi.org/10.1007/978-90-481-9707-1_120