LLM Agents Send HPC Workloads to Heterogeneous Clusters, with Descriptive Hardware Data Raising the Success Rate from 48% to 87%

Researchers at Lawrence Livermore National Laboratory unveiled an agent-based HPC job-dispatch experiment on August 12 that separates “understanding workload requirements” from deterministic scheduling and submission mechanisms. Their open-source [Resource Secretary](https://github.com/converged-computing/resource-secretary) can detect CPUs, GPUs, memory, networks, containers, and ten workload managers, exposing available operations as MCP-like tool functions. The agent translates natural-language intent into job specifications, submits jobs, reads status and logs, and finally returns a job receipt that can be verified through the Flux API.

In the first set of tests, the team ran LAMMPS in a five-node EKS/Flux environment, varying the workload manager, resources, application configuration, additional flags, and four prompting styles to produce 432 job dispatches. Of those, 423 completed successfully, for a 97.9% success rate. The nine failures included incorrectly concatenating flags with filenames, inserting `False`, and shrinking a 320-task job to a single node during a retry, causing it to time out. The results show that log inspection and parameter validation can curb agents from merely claiming that a job is complete, but cannot replace checks for command-line syntax and resource quantities.

The second experiment distilled 219 containers into 11 applications and deployed them across six three-node clusters on AWS and Google Cloud. The hardware spanned amd64, arm64, EFA, different memory capacities, and hourly costs ranging from $0.29 to $3.78. Fluxq first matched workloads against a resource graph, then selected a cluster and converted commands using deterministic templates. After architecture, network, and memory descriptions were added, the success rate across 220 jobs rose from 48% to 87%, while architecture incompatibilities were eliminated. Five of the ten measurable applications ran faster, with MiniFE achieving the largest speedup at up to 3.3×.

However, the [paper](https://arxiv.org/abs/2608.11524) emphasizes that metadata primarily helped avoid nodes on which workloads could not run at all; it did not reliably identify the fastest machines. The test clusters were small and had no GPUs, and the agent model was not compared with other models. All fallback jobs triggered by five API outages also failed. From an engineering perspective, the priorities worth tracking are schema validation for every command; incorporating queue depth, cost, and historical performance into scoring; and determining whether workloads can be safely rematched after an initial dispatch failure, rather than simply allowing the agent to retry on its own.