A Locally Deployable Tool-Grounded LLM Multi-agent Framework for Automating Methane Emission Analysis and Reporting
Authors: Yang Yan, Zifan Zhou, Xuan Wang, Erum Hassan, Bilguunzaya Mijiddorj, Jie Cao, Bin Li, Binbin Weng
Organizations: School of Electrical and Computer Engineering, University of Oklahoma, Norman, OK, 73019 USA · Department of Electrical Engineering, Pennsylvania State University, University Park, PA, 16801 USA · School of Computer Science, University of Oklahoma, Norman, OK, 73019 USA
Methane field monitoring requires the integration of sampling design, meteorological interpretation, sensor processing, plume analysis, visualization, and reporting, but these steps are often distributed across separate expert-driven workflows. We developed a locally deployable, tool-grounded large language model (LLM) multi-agent framework for our low-cost methane sensing and field-monitoring campaigns. The framework uses LLM agents as workflow coordinators that link field measurements, meteorological data, deterministic sensor-processing routines, Gaussian plume inversion, and report generation, rather than directly estimating methane concentrations or emissions. Extensive field deployments across diverse real-world environments (e.g., wastewater treatment facilities, landfills, and oil and gas sites) demonstrate that our framework can achieve 92.0% accuracy in workflow routing and parameter extraction, 85.0% success in emission-rate estimation and plume prediction, and 95.0% success in generating editable reports under practical operating conditions. Compared with manual and general-purpose LLM-assisted workflows, it reduced workflow time from hours-level to minutes-level, lowered manual coordination and prompt-engineering requirements, and retained traceable plume-based outputs. In addition, most processing can be performed locally, reducing exposure of sensitive facility and field data to cloud services. These results indicate that tool-grounded LLM coordination can reduce the time, labor, usability, and data-security barriers of methane field monitoring.
Figures & tables
Figure 1: Conventional multi-expert methane monitoring workflows. The figure was generated with AI assistance based on author-provided content and subsequently reviewed and refined by the authors.
Figure 2: System architecture and workflow of the tool-grounded LLM multi-agent framework for methane monitoring.
Figure 3: Example conversion of a natural-language request into structured parameters for methane leak localization.
Figure 4: Route-planning outputs generated by the AIMNet agent for three methane monitoring scenarios
Figure 5: Reverse Prediction of Leak Points from Field Measurement Results at a Wastewater Facility
Figure 6: Gaussian plume reconstruction under different meteorological conditions using manual and automated input workflows
Agent Decision Task
Test Cases
Success Criterion
Success Rate
Failure Description
Workflow routing and parameter extraction
50 prompts
Correct workflow selected and all required parameters extracted
92.0%
Errors mainly occurred when prompts contained incomplete field descriptions for graphing.
Methane column and unit selection
10 CSV files
Correct methane column selected and ppm/ppb unit handled correctly
90.0%
One case failed due to unclear column naming and missing unit for high methane concentration
Weather source decision
10 cases
Correctly selected user provided wind, weather API, inferred wind, or fallback
100%
None
Single source vs multi-source decision
8 CSV files
Correctly classified the survey as single source or multi-source
87.5%
Errors were mainly caused by overlapping methane enhancement regions from nearby potential sources.
Validity decision
10 cases
Validity label matched the actual error category
80.0%
Misclassification occurred when multiple error types appeared simultaneously in the same input case.
Table 1: Agent decision accuracy across workflow and data interpretation tasks.
Agent Decision Task
Test Cases
Success Criterion
Success Rate
Failure Description
Missing wind plume reconstruction
30 cases
Correctly used the weather API when time information was available, or applied the default wind setting when detailed time information was missing.
100%
None
Potential measurement area prediction
10 cases
Correctly cover the potential methane detection area
90%
Only occurs when wind and environmental conditions are unstable
Leak source localization
15 cases
Correctly localize the Highest reading point, and Predicted source error <5 m
73.3%
Errors mainly occur under unstable or weak wind conditions, which reduce the reliability of plume-based source localization.
Emission Rate and Emission plume prediction
20 cases
Leak rate estimates and plume visualizations were physically meaningful and consistent with manual calculation.
85%
Incorrect stability class was selected for calculation-based on the weather conditions.
Report Generation
20 cases
Generated an editable report with meaningful content and structure aligned with the user’s request
95%
Failures mainly occurred when the revised report contained corrupted text or misplaced elements
Table 2: Methane analysis performance of AIMNet after workflow execution.
Figure 7: Quantitative validation of leak source localization, emission rate estimation, and plume reconstruction across field scenarios.
Figure 8: External LLM-based and expert evaluation of the locally deployed AIMNet agent across different report generation tasks
Figure 9: Estimated time comparison among the manual workflow, general purpose LLMs (ChatGPT), and the AIMNet agent
Score range
Description
9–10
Excellent: accurately presents methane data, meteorological inputs, source location, model-derived emission rate, plume results, uncertainty, and validity information. Figures and conclusions are consistent and require only minor edits.
7–8
Good: main analytical results are correct and usable, with only minor omissions or unclear details in weather sources, uncertainty, validity, figures, or recommendations.
5–6
Fair: major outputs are identifiable, but important information is incomplete, inconsistent, or requires expert revision before use.
3–4
Poor: major omissions or errors in methane units, meteorological inputs, source localization, plume results, figures, or conclusions substantially limit usability.
1–2
Very poor: mostly incorrect or incomplete, with unsupported conclusions, physically inconsistent results, or unreadable report content.
0
Failed: no valid report, failed execution, unreadable output, or content unrelated to the methane-monitoring task.
Table S1: General scoring rubric for evaluating LLM-agent outputs.
No.
Example prompt
1
I want to conduct a methane field test around [latitude, longitude] tomorrow morning. What is the best time to start?
2
I want to conduct a methane field test around [latitude, longitude] this week. Which day and time would be most suitable?
3
I plan to test methane emissions around [latitude, longitude] on July 5. What would be the best time of day?
4
I want to conduct a field test around [latitude, longitude] this afternoon. Are the expected weather and wind conditions suitable?
5
I want to conduct a methane survey around [latitude, longitude] next week. Recommend the best date and time based on the weather forecast.
6
I want to conduct a methane field test around [latitude, longitude]. What route should I follow?
Table S2: Example prompts for evaluating methane field-test route planning
No.
Example prompt
11
Plot CH 4 , humidity, and temperature from the uploaded CSV file on the same time axis.
12
Plot CH 4 , CO 2 , and H 2 O measurements from the uploaded CSV file for comparison.
13
Filter out abnormal methane measurements from the uploaded dataset and plot the cleaned data.
14
Process the uploaded raw AIMNet sensor data and plot the methane measurements before and after preprocessing.
15
Collect ten minutes of data from AIMNet devices 001, 002, and 003 and plot their methane measurements on the same figure.
16
Compare the methane measurements from AIMNet devices 001, 002, and 003. Identify which device reports the highest values and whether any device shows abnormal measurements.
Table S3: Example user prompts for methane-data retrieval, preprocessing, and input validation
No.
Example prompt
21
The methane source is located at [latitude, longitude]. The wind speed was 6 mph and the wind direction was 150 degrees. Methane enhancement was 1 ppm at 5 m and 200 ppb at 10 m. Reconstruct the plume.
22
I tested a methane source at [latitude, longitude]. The wind speed was 3 m/s and the wind direction was 220 degrees. Methane enhancement was 1.2 ppm at 5 m, 500 ppb at 10 m, and 150 ppb at 20 m. Estimate the emission rate and plot the plume.
23
I tested a methane source at [latitude, longitude] on July 5, 2026, at 10:00 a.m. Methane enhancement was 800 ppb at 8 m and 300 ppb at 15 m. Retrieve the weather conditions and reconstruct the plume.
24
I tested a methane source at [latitude, longitude] on January 20, 2026, at 2:00 p.m. Methane concentrations were 3.0 ppm at 5 m and 2.3 ppm at 10 m, with a background of 2.0 ppm. Retrieve the weather conditions and plot the plume.
25
The methane source is located at [latitude, longitude]. The wind speed was 3.1 m/s and the wind direction was 295 degrees. Methane enhancement was 2400 ppb at 6 m and 700 ppb at 12 m. Reconstruct the plume.
26
I tested a methane source at [latitude, longitude]. The wind speed was 2.5 m/s and the wind direction was 45 degrees. Methane concentrations were 3.4 ppm at 4 m and 2.5 ppm at 9 m, with a background of 2.1 ppm. Estimate the emission rate.
Table S4: Example prompts for known-source plume reconstruction and emission-rate estimation.
No.
Example prompt
31
I conducted a vehicle-based methane survey. Plot the methane measurements along the survey route, identify the suspected source location, and generate a plume map.
32
I uploaded a manual-survey CSV file containing methane concentrations and GPS coordinates. Estimate the most likely source location and reconstruct the plume.
33
I conducted a vehicle survey around [latitude, longitude] on July 5, 2026, at 10:00 a.m. Retrieve the corresponding weather conditions and identify the most likely methane source.
34
I uploaded vehicle-survey data with a wind speed of 3 m/s and a wind direction of 220 degrees. Estimate the source location, emission rate, and plume distribution.
35
Compare the possible source locations around the survey route and identify the location that best matches the observed methane measurements.
36
I uploaded a vehicle-survey CSV file containing methane concentrations, GPS coordinates, and timestamps. Identify the suspected source location, estimate the emission rate, and generate a plume map.
Table S5: Example user prompts for inverse methane-source localization and emission analysis
No.
Example prompt
41
Generate a methane-monitoring report for the monitoring point at [latitude, longitude].
42
Generate a report summarizing the results from the last three monitoring points.
43
Generate a report for the field-test route planned on July 10.
44
Prepare a report for the most recent vehicle-based methane survey, including the concentration map, predicted leak location, plume visualization, and emission-rate estimate.
45
Generate a short field report for the manual methane test conducted at [latitude, longitude].
46
Combine the last three source-localization results into one report and compare their predicted source locations and validity assessments.
Table S6: Example user prompts for validity assessment, report generation, and report revision
Figure 10: Successful Example of Automated Methane Report Generation.
Figure 11: Representative failure in automatic methane-column identification and visualization. Because the CSV file contained ambiguous column headers and multiple candidate columns with similar numerical distributions, the preprocessing routine selected the wrong methane field and generated an incorrect methane concentration plot.
Figure 12: Representative failure caused by incomplete time-series data. Missing timestamps and data gaps in the original files caused the agent to incorrectly connect discontinuous measurements during visualization, resulting in a misleading methane concentration plot.
Figure 13: Representative plume-reconstruction failure caused by nonrepresentative meteorological inputs. The wind speed and direction retrieved by the Weather Agent did not capture the transient local wind conditions during field measurement, resulting in an inaccurate Gaussian plume visualization and unreliable source-localization and emission-rate estimates.
Anthropogenic methane (CH4) point sources are critical drivers of near-term climate forcing, safety hazards, and system-inefficiencies. Space-based imaging spectroscopy is an emerging tool for identifying emissions globally, but existing approaches largely rely on manual plume identification. Here, we present the Methane Analysis and Plume Localization with EMIT (MAPL-EMIT) model, an end-to-end vision transformer framework that leverages the complete radiance spectrum from the Earth Surface Mineral Dust Source Investigation (EMIT) instrument to jointly retrieve methane enhancements across all pixels within a scene. This approach brings together spectral information with spatial context to significantly lower detection limits. MAPL-EMIT simultaneously supports enhancement quantification, plume delineation, and source localization, even for overlapping plumes. The model was trained on 3.6 million physics-based synthetic plumes injected into global EMIT radiance data. Synthetic evaluation confirms the model's ability to identify plumes with high recall and precision and to capture weaker plumes relative to existing matched-filter approaches. On real-world benchmarks, MAPL-EMIT captures 84% of known hand-annotated NASA-L2B plume complexes across a test set of 1084 EMIT granules, while capturing roughly 1.5 times as many plausible plumes compared to human analysts. Further verification against coincident airborne data, top-emitting landfills, and controlled release experiments confirms the model's ability to identify previously uncaptured sources. By incorporating model-generated metrics such as spectral fit scores and estimated noise levels, the framework can limit false-positives. Overall, MAPL-EMIT enables high-throughput implementation on the full EMIT data catalog, shifting methane monitoring to a rapid, scalable paradigm for global plume mapping at the facility scale.
Vishal V. Batchu, Michelangelo Conserva, Alex Wilson +5
Google Research · Carnegie Institution for Science · Jet Propulsion Laboratory, California Institute of Technology
Tool-using LLM agents are increasingly used to automate workflows governed by procedural manuals, such as company rules for booking travel or procuring hardware. These manuals are written in natural language for humans and describe general requirements over such complex workflows. Ensuring compliance of LLM agents with these manuals is difficult, and state-of-the-art techniques use either LLM judges or manually written rules to forbid problematic tool-calls locally at runtime. This is insufficient because (i) only blocking tool calls keeps the agent clueless about how to make correct progress towards fulfilling its task, and (ii) can lead to overly conservative behavior of the agent, as tool calls might only be problematic in certain contexts. To overcome these challenges, we introduce MENTOR, which (i) additionally provides guidance for the agent to make procedural-compliant progress on the task, and (ii) ensures that this compliance is context-aware. We achieve these goals by building a novel history-dependent runtime shield that is obtained from the procedural manual via a multi-step autoformalization pipeline. At its core, MENTOR utilizes a game-based technique to ensure robustness against runtime uncertainty without over-resticting agents' behavior. This yields a formally assisted framework for procedural shielding of LLM agents that improves compliance well beyond existing methods. In particular, MENTOR lifts the compliance of shielded light-weight open-source LLMs above that of non-shielded proprietary models. Since a shield is synthesized once per manual and then serves every task, a MENTOR-shielded agent becomes a viable choice for repeatedly executed workflows, potentially reducing deployment costs when the offline construction cost is amortized over repeated tasks.
Ashwani Anand, Ivi Chatzi, Ritam Raha +1
Max Planck Institute for Software Systems, Kaiserslautern, Germany · TNO-ESI, Eindhoven, The Netherlands
Tool-using large language model (LLM) agents are increasingly deployed in settings where their reliable behavior is governed by strict procedural manuals. Ensuring that such agents comply with the rules from these manuals is challenging, as they are typically written for humans in natural language while agent behavior manifests as an execution trace of tool calls. Existing evaluations of LLM agents rely on manually constructed benchmarks or LLM-based judges, which either do not scale or lack reliability for complex, long-horizon manuals. To overcome these limitations, we present MANTRA, a framework for automatically synthesizing machine-checkable compliance benchmarks from natural-language manuals and tool schemas. MANTRA independently generates (i) a symbolic world model capturing procedural dependencies, and (ii) a set of trace-level compliance checks for a given task, and validates their consistency using SMT solving. A structured repair loop resolves inconsistencies, requiring human intervention only as a fallback. %This yields benchmarks that are formally validated. Importantly, MANTRA supports arbitrary domains and long procedural manuals, and provides a tunable notion of task complexity which is utilized to automatically derive challenging tasks accompanying compliance checks. Using MANTRA, we build a new benchmark suite with 285 tasks across 6 domains scaling to 50+ page manuals with minimal human effort. Empirically, we show that the compliance checks are richer with stronger constraint enforcement compared to existing benchmarks. Additionally, the granularity of the checks can be used for debugging the agents' failure modes. These results demonstrate that combining automated benchmark generation with formally grounded validation methods enables scalable and reliable benchmarking of tool-using agents.
Ashwani Anand, Ivi Chatzi, Ritam Raha +1
Max Planck Institute for Software Systems, Kaiserslautern, Germany