Computational materials agents: from task demonstrations to executable scientific workflows

INTRODUCTION

Large language models (LLMs) have changed how scientific information is accessed, summarized, and recombined, but question answering alone is insufficient for scientific work. Many research tasks require systems that interact with external resources and adjust their actions in response to observations. Artificial intelligence (AI) agents provide this capability by coupling a model with planning, action, observation, and feedback^[1]. In ReAct-like settings, reasoning and action are interleaved in repeated think-act-observe cycles. Tool-use systems^[2] further show that models can operate through application programming interfaces (APIs), calculators, databases, or instruments.

Computational modeling of materials and molecular systems is central to modern materials research because it connects physical theory, atomistic mechanisms, and measurable materials properties^[3]. First-principles calculations, molecular dynamics (MD), thermodynamic modeling, and high-throughput screening allow researchers to test hypotheses, evaluate candidate materials, interpret experiments, and guide design decisions before or alongside laboratory work^[4-6]. However, such studies rarely consist of a single calculation. They require choices about structures, models, parameters, convergence criteria, software environments, post-processing methods, and physical interpretation. The reliability of a computational result therefore depends not only on its numerical output but also on whether the full workflow is traceable, reproducible, and scientifically justified. These requirements make computational materials modeling a natural but demanding setting for agentic systems. Recent studies have begun exploring agentic coordination in this domain^[7-9]. Established computational workflow systems already support standardized execution, provenance tracking, job management, and reproducible calculations within predefined procedures^[10-12]. However, designing and adapting these procedures still requires substantial domain expertise and practitioner judgment. LLM-based agents can complement such systems by lowering technical barriers through natural-language interaction, enabling more flexible coordination when procedures are not fully specified, and linking computational workflows to automated experimental platforms.

Against this background, studies of LLM-based materials agents have increased markedly since 2023 [Figure 1]. Reported systems span literature extraction^[13], candidate design^[14,15], synthesis planning^[16], autonomous experimentation^[17,18], closed-loop discovery^[19], and computational modeling^[20-23]. Within this landscape, computational materials agents have focused primarily on density functional theory (DFT), MD, and related atomistic simulations. These systems organize materials knowledge, simulation software, databases, and feedback signals around executable calculations, allowing materials questions to be translated into computational tasks. The central question is whether they can support routine research by setting up, executing, checking, and reporting calculations that produce usable computational evidence.

Figure 1. Curated publication landscape of materials-agent studies by year and category. Stacked bars show the annual number of included works from 2021 through May 2026. Works are grouped into benchmark/evaluation studies, neighboring agent systems, pre-agent infrastructure, materials knowledge assistants, other materials agents, and computational materials agents. Open circles connected by a dotted line show the cumulative number of works. The distribution highlights a shift from early pre-agent infrastructure toward rapidly expanding agent-based systems after 2023. Computational materials agents have become a major component of recent studies. Studies were identified by searching arXiv and Google Scholar using combinations of the terms “materials agent”, “computational materials agent”, “atomistic simulation agent”, and “materials agent benchmark”. Retrieved records were screened for direct relevance to materials-agent systems, executable scientific workflows, or agent evaluation. Reviews and perspectives were excluded. Duplicate preprint and journal versions were counted only once, and each included study was assigned to a single primary category based on its principal contribution.

In this review, we examine computational materials agents as executable scientific workflow systems rather than as isolated language or tool-use demonstrations. We first describe their architectures through a model-harness-skill framework, then trace their operation across computational workflow stages, and finally analyze how current evaluation practices shape claims about reliability, reuse, and scientific correctness. This organization clarifies what current agents can already support, where the evidence remains limited, and what is needed to move from task demonstrations toward reusable computational materials workflows.

ARCHITECTURES FOR COMPUTATIONAL MATERIALS AGENTS

Common requests in computational materials research, such as structure optimization, band-structure calculation, or adsorption energy evaluation, require agents to choose methods, prepare structures and inputs, run domain software, and inspect logs and outputs. An agent architecture must therefore connect scientific intent with executable skills while keeping files, errors, checks, and decisions available for inspection and revision.

Drawing on general formulations of LLM reasoning and tool use^[1,2] and recurring functional components in the computational chemistry and materials-agent systems reviewed here^[24,25], we organize the architectural discussion around a coupled model-harness-skill framework [Figure 2A]. The model provides reasoning and generation capabilities. The harness turns model outputs into controlled workflows by managing task decomposition, tool routing, workflow state, and validation or stopping rules. Skills are callable procedures or tool wrappers through which the agent acts on external resources, files, software, or data. Although these roles are often coupled in practice, distinguishing them clarifies their functions. The harness determines when and in what order actions are taken, whereas skills provide the executable channels for those actions.

Figure 2. Model-harness-skill framework and executable workflow of computational materials agents. (A) Model-harness-skill framework. The model supports reasoning and generation, the harness controls the workflow, and domain skills execute actions through materials databases, structure tools, simulation codes, parsers, validators, and analysis tools; (B) Executable workflow loop. A materials request is converted into a computational task. Domain software executes the task, whose outputs and error messages are then evaluated. Feedback determines whether the task is revised, accepted, or stopped. The figure was assembled by the authors using Microsoft PowerPoint and the generic graphical symbols were selected from the built-in Microsoft 365 icon library.

Materials-specific design can be implemented at any layer of this architecture. At the model layer, a system may use a materials-specialized language model or a broader materials foundation model to improve the use of domain terminology and support reasoning about structures, compositions, and properties^[26-28]. LLaMat illustrates model-layer specialization. It combines continued pretraining on tens of billions of materials-science tokens from millions of publications and crystallographic records with subsequent instruction and task fine-tuning on a large materials question-answering corpus^[27]. Such specialization can improve performance on materials-related tasks, including language understanding, extraction, and generation, but it is resource-intensive and not uniformly beneficial. The study also reports adaptation rigidity in extensively pretrained base models^[27]. The benefit of a materials-specialized LLM therefore depends on the base model, training procedure, task family, and evaluation setting.

Given these limitations of model-layer specialization, many current agent systems place materials-specific knowledge in the harness and skills. In such systems, domain knowledge is embodied in task templates, software-specific validators, retry rules, input and output handlers, and interfaces to simulation codes or computing resources. These functions are often implemented together rather than separated into distinct harness and skill layers. TritonDFT^[20] maps DFT requests to Quantum ESPRESSO (QE) subproblems and executable calls, parses and evaluates the outputs, and retries with revised parameters. MDAgent2^[21] organizes Large-scale Atomic/Molecular Massively Parallel Simulator (LAMMPS) code generation around syntax and potential-file checks, execution feedback, and regeneration; MatClaw^[25] uses Python code as the action interface for materials libraries and remote high-performance computing (HPC) workflows, with memory and source-code retrieval supporting repair during long tasks.

Harness-level specialization can also be implemented through role-based organization in multi-agent systems. Agents with different responsibilities handle distinct parts of the calculation^[29]. The multi-agent atomistic-simulation framework of Vriza et al. provides a concrete example^[30]. An administrator agent routes a user request through structure-generation, potential-search, LAMMPS-input, HPC-execution, property-specific, and results-analysis agents. In the gold (Au) workflow, these roles generate the face-centered cubic (FCC) structure and locate and validate an embedded-atom method (EAM) potential. They then prepare and submit LAMMPS jobs to an HPC cluster and parse lattice-constant and cohesive-energy outputs.

A complementary approach keeps the coordinator general and places most domain specificity in skill packages. OpenClaw-based computational-chemistry skills^[24] illustrate this pattern: OpenClaw maintains task state, reads execution feedback, and decides which skills to invoke, whereas the skills supply domain-specific procedures. In the methane-oxidation case study^[24], skills for molecular conversion, packing, LAMMPS/Deep Potential Molecular Dynamics (DeePMD) execution, job dispatch, and trajectory analysis assemble a reactive MD workflow spanning molecular preparation through reaction-pathway analysis. This separation facilitates reuse because the coordinator can remain general while the skills encapsulate executable domain procedures, validation logic, and recovery behavior.

In summary, coupled workflow controllers can be efficient and relatively easy to validate within a fixed software stack, but they may be less transferable when the engine, file conventions, or target property changes. Multi-agent role separation makes domain responsibilities and handoffs visible, but it also adds coordination overhead and more pathways for errors to propagate between roles. General coordinators with domain skills support reuse, yet their performance depends on whether the skills expose sufficient procedural detail, validation hooks, and failure information for the harness to control them. For computational materials agents, the architecture determines which parts of a calculation can be inspected, replaced, or reused, and whether the workflow can recover from failure.

COMPUTATIONAL WORKFLOW PRACTICES

Building on the architectures discussed above, recent computational materials agents can perform a range of tasks^[31-33]. Although their software stacks, target tasks, and execution environments differ, they often follow the same basic process: they translate a user request into a calculation plan, implement the plan as runnable inputs or scripts, execute them with domain software, and parse or check the resulting outputs [Figure 2B].

A request for a band gap, diffusion barrier, adsorption energy, elastic constant, or thermodynamic quantity may leave unspecified the structure source, level of approximation, convergence target, reference state, allowable computational cost, and acceptable error. To reduce this uncertainty, a user’s scientific request should be formalized in terms of the materials system, target property, method family, constraints, and success criteria before input generation, execution, and checking. The user specifies some choices; others are drawn from templates, defaults, or software-specific recommendations. TritonDFT^[20] makes this step concrete by mapping the request to DFT task classes such as self-consistent calculation, variable-cell relaxation, band structure, or density of states. Through a knowledge-graph-based recommendation layer, GENIUS^[23] interprets a natural-language request in light of QE parameter details and constraints, then uses this interpretation to initialize the workflow before input generation. QUASAR^[22] emphasizes the planning aspect of this stage: its strategist interprets a user-defined research objective, decomposes it into scientifically grounded subtasks, and uses a second planning pass to identify missing domain-specific steps before execution. User-adjustable granularity and accuracy settings further determine the depth of task decomposition and the stringency of the calculation protocol.

During executable setup, the agent uses skills and tool interfaces to convert the formalized task into runnable files or software calls. TritonDFT^[20] links DFT task classes to QE workflow functions and executables: self-consistent calculations, variable-cell relaxations, and band-mode calculations use pw.x, whereas band-structure and density-of-states post-processing steps use bands.x and dos.x, respectively. In GENIUS^[23], QE input generation begins with the template returned by the recommendation system; the language model then selects from the suggested parameters based on the user prompt and additional context. For MD, MDAgent2^[21] uses a Writer LLM to draft a LAMMPS script and an output-file contract before tool-based checks. This contract provides a concrete basis for validating the files produced by LAMMPS. These examples also show why executable setup remains environment-dependent: many successful demonstrations rely on predefined engines, prompt constraints, local file availability, and benchmark task design. If the environment changes, a generated input may be syntactically plausible yet still fail because a pseudopotential is missing, a potential file is misnamed, a package version interprets a keyword differently, an HPC queue is unavailable, or the directory state differs from the expected state. Executable setup should therefore record sufficient information about software versions, file locations, auxiliary models, and resource assumptions so that another user or the agent in a subsequent run can determine what was executed.

After execution, agents must extract usable results from raw simulation outputs. TritonDFT^[20] parses QE outputs to obtain structures, symmetry information, energies, band structures, and density-of-states results. QUASAR^[22] places greater emphasis on preserving the run record: archived runs retain raw outputs, parsed summaries, plots, reports, and associated metadata. Beyond extraction, output handling requires organizing simulation products into task-level records and determining whether the results answer the scientific question. Current agents are most reliable at extraction and organization when the output formats are known. Interpretation depends more strongly on physical context, reference choices, uncertainty, and comparisons with prior knowledge. A numerical result can support different claims depending on the calculation route and the scientific question; the result is useful only when interpreted in that context.

To keep a calculation or simulation moving through the workflow, checks and repairs are required at multiple points. Generated inputs or scripts must be tested against domain software, execution logs must be inspected, and parsed outputs must be checked against task criteria. In MDAgent2^[21], the drafted LAMMPS script is revised through tool-mediated syntax and potential-file checks: the syntax tool identifies code-level errors, whereas the potential-file tool verifies whether the specified LAMMPS potential file is locally available or recommends the top-k most similar alternatives. The Writer LLM uses this feedback to regenerate code until it passes the checks or an iteration limit is reached. In GENIUS^[23], the generated QE input is syntactically validated by running QE; failed validation triggers automated error handling to diagnose crash messages and repair the protocol. In these examples, repair begins only after a tool, validator, or result criterion identifies a local error. Some repairs restore input validity or keep an engine running; others address non-convergence, missing outputs, or results that fail a task criterion. A correction loop can improve workflow continuity, but it does not by itself validate the physical model, convergence protocol, or interpretation. Repair loops therefore show both whether the computation can proceed and which types of failure the agent can detect and address.

These checks become workflow-level decision points when their signals guide retries, acceptance, stopping, or replanning. In TritonDFT^[20], unsatisfactory results can trigger parameter revisions and reruns; in QUASAR^[22], evaluator feedback can return a task to the Operator for a limited retry before it is accepted or marked as unresolved. AutoDFT extends this pattern in its Vienna Ab initio Simulation Package (VASP) workflows^[34]: a dual-path monitor, a recovery agent, and a step reflector diagnose failed or physically implausible steps, revise inputs or plans, and limit the number of recovery attempts. These mechanisms can detect missing files, invalid scripts, startup failures, convergence problems, or mismatches with predefined task criteria.

Not every detected failure should trigger the same response. A formatting error may require only a local edit, whereas an unsuitable method or workflow route may require replanning. A retry may be inexpensive during input generation but costly once a production DFT calculation or long MD simulation has been launched. In some cases, stopping is preferable to continuing with an unsupported calculation. In discovery settings, these decisions must also account for branch value, computational budget, and the expected information gain from an additional calculation. Current demonstrations include early forms of such decision-making, generally implemented through predefined validators or limited retry policies.

Most reported successes still come from scaffolded DFT, MD, and atomistic tasks with well-specified software environments, file conventions, validation points, and target outputs^{[20,21,34,35]}. These studies show that agents can progress through several stages of a computational workflow rather than merely make isolated code or tool calls. However, these demonstrations remain limited in scope because many otherwise challenging aspects of open-ended computation are predefined: the engine is known, the task type is constrained, the expected output is identifiable, and the failure modes are often detectable by formal checks.

BENCHMARKING AND EVALUATION EVIDENCE

Reported workflow successes raise a further evaluation question: what claims can be supported by a correct answer, a valid tool call^[36], a runnable input file, a completed run, or a scientifically justified conclusion? To compare heterogeneous studies, we classify current evaluation practices into three forms: local component checks, end-to-end case studies, and structured benchmarks. Figure 3 illustrates their relationship: local checks assess specific elements of an agent run, case studies examine the complete record of a selected workflow, and structured benchmarks evaluate performance across predefined tasks and repeated runs under common conditions. Across all three forms, the strength of the resulting claims depends on the completeness of the workflow record and on whether formal execution checks are complemented by scientific assessment.

Figure 3. Common evaluation forms for computational materials agents. Local component checks assess formal properties of individual artifacts or execution steps. An end-to-end case study places these checks within the complete record of a selected agent run, including the task and inputs, software setup, actions and decisions, execution record, and interpreted results. Structured benchmarks evaluate performance across a predefined task set through repeated runs conducted under a common protocol and environment, with scoring based on metrics, rubrics, or reference results. The figure was assembled by the authors using Microsoft PowerPoint. Icons were adapted from Lucide Icons and used under the ISC License and, where applicable, the MIT License for Feather-derived icons.

Early LLM benchmarks, such as MaScQA^[37] and MSQA^[38], commonly evaluated the accuracy of models’ answers to materials-science questions^[39]. As the field progressed toward materials-agent systems, MatTools extended this evaluation paradigm from question answering to materials tool use and executable code^[40]. More recent studies align more closely with simulation practice by incorporating runtime feedback, short correction loops, and selected workflow steps under predefined conditions. For example, MDAgent2^[21] evaluates LAMMPS script generation together with execution feedback, syntax and potential-file checks, limited regeneration loops, and expert scoring.

Such local component checks support specific but limited claims. They can show that a model knows relevant terminology, can select a tool, can generate a script that passes a known check, or can revise an artifact after a visible error. These capacities are necessary for workflow agents; weak performance at this level would make longer workflows fragile. However, local success does not show how errors accumulate, whether intermediate assumptions are preserved, or whether an apparently correct step remains valid when embedded in a longer calculation. For computational materials agents, these checks mainly test individual workflow components and therefore cannot establish the reliability of a complete scientific workflow.

To evaluate behavior across complete workflows, several studies rely on case-study evidence. QUASAR^[22], for example, uses three tiers of selected atomistic-simulation tasks to test single-task execution, literature-grounded workflow orchestration, and performance on more open-ended simulation problems. Because these studies report end-to-end cases and release some run records, they support assessments beyond isolated tool-level success: planning, execution, error response, and reporting can be evaluated within a complete workflow trajectory. Related studies of agents for DFT^[33], MD^[21,41], and other atomistic simulations take two approaches: they evaluate selected examples against expert judgments or reference results, or pair workflow demonstrations with tests of retrieval, input preparation, code generation, or evaluator components.

The value of such case studies is that they preserve the workflow episode intact, allowing integration failures to become visible when a later step depends on earlier choices or local resources. A limitation is that the cases are selected: they demonstrate connected execution in the reported settings but do not establish whether the same behavior generalizes across other task families, materials systems, software environments, or failure modes.

More structured evaluations specify the task family, run conditions, or scoring rules before execution. For DFT-focused materials agents, TritonDFT’s DFTBENCH^[20] asks the agent to complete QE workflows for 68 crystalline materials across four task types: variable-cell relaxation, static calculations, band-structure calculations, and density-of-states calculations. It then evaluates completion, accuracy-cost trade-offs, and parallelization choices against expert-derived references. GENIUS^[23] targets a different point in the workflow: its 295 researcher-written prompts test whether a natural-language DFT request can be converted into a QE input setup that survives a 60-second validation run. Recovery is assessed through the automated error-handling loop rather than on the basis of converged production calculations or the correctness of final properties. El Agente Sólido^[42] emphasizes repeatability and expert judgment through seven types of solid-state exercises, Level 1 and Level 2 prompt variants, repeated trials, reported results, and rubrics developed by computational chemists. These designs make each study more controlled than an open demonstration, but the evaluation settings still differ substantially in task definitions, software stacks, prompt conditions, scoring rubrics, artifact completeness, and expert involvement.

The unit of assessment also varies across studies. Some evaluations score input validity or code execution, whereas others assess completed workflows, agreement with reference properties, code quality as judged by experts, or case-study completion. AutoMat extends this line of evaluation beyond tool use by assessing claim-level reproduction^[43]. It tests whether an agent can reconstruct the relevant computational procedure, execute it, and determine whether the resulting evidence supports a specific computational claim from a materials paper. These units cannot be compared directly: a valid input, a successful run, a value that matches a reference, and a reproduced computational claim support different types of conclusions. Evaluations should therefore specify their unit of assessment before comparing scores.

Across these forms of evaluation, automated methods usually assess local, formalized signals^[40,44]. Syntax validity, required-file generation, startup success, completion status, convergence flags, and agreement with predefined reference values can be checked at scale, supporting reproducible evaluation. These checks are necessary, but they do not cover all aspects of scientific assessment. AutoMat shows why this distinction matters in practice: a run can generate outputs yet still fail as a reproduction if the results do not support the target claim or if the calculation procedure deviates from the intended method^[43]. For example, in the AUTOMAT-0007 task, the agent completed the workflow and achieved an accuracy of 0.8894, close to the reported value of approximately 0.89. However, the agent used an incorrect temperature feature and evaluated a different data subset; therefore, the apparent numerical agreement did not constitute a reproduction of the intended scientific claim. Expert or reference-based judgment is still needed when the claim depends on the choice of method, the physical adequacy of the model, reference-state selection, the reasonableness of parameter choices, or interpretation. Rubrics can make this judgment more reproducible^[42,45,46], especially when they specify what evidence should be present and which errors matter most; however, they also encode task-specific disciplinary assumptions. Evaluation protocols should therefore state which components are checked automatically, which require expert or reference-based judgment, and which remain outside the benchmark.

Clear task definitions and scoring rules are still insufficient when the workflow record is incomplete. Success on individual checks or tool-use steps does not establish robustness across complete workflows, and local repair loops do not show whether recovery remains reliable in longer workflows, across changing software environments and task types, or when unexpected failures occur. Intermediate artifacts are therefore important: without procedures, files, logs, and failure records, it is difficult to determine whether a failure stems from agent behavior, missing evidence, unavailable files, or an underspecified task. AutoMat’s failure analysis supports this concern: many failed reproductions were attributed to incomplete procedures, methodological deviations, or execution fragility, indicating process-level failures rather than simply incorrect final answers^[43]. Related agent studies increasingly release portions of such records^[20,22,47], but papers and repositories still often leave the process only partly visible. Benchmarks should therefore treat artifact completeness as part of the evaluation and state whether they assess a runnable artifact, a checked computational result, or an inspectable workflow record.

These visibility issues point back to the same evaluation problem: each form of evidence supports a different type of claim. Local component checks support claims about components; end-to-end case studies support claims about selected workflow episodes; structured benchmarks support claims about performance within a defined task distribution; automated checks support claims about formalized signals; expert rubrics support broader judgments of scientific adequacy when their criteria are explicit. Conflating these evidence types makes computational materials agents appear more reliable than their evaluations warrant. Keeping the evidence types distinct makes reported progress easier to interpret.

CONCLUSION AND OUTLOOK

In materials research, computation often connects theoretical ideas with experimental or design decisions. It maps structures, mechanisms, theoretical assumptions, and experimental questions onto quantities that can be compared, tested, or used for screening, while experimental constraints and observations determine which calculations are meaningful. In this context, computational materials agents extend language assistance into executable research workflows.

Computational materials agents can help make this connection operational by selecting a calculation route, preparing executable inputs, running domain-specific software, checking whether outputs are usable, and preserving the context needed for subsequent scientific decisions. Usable outputs can then inform those decisions. A relaxed structure may be reused in a higher-level calculation; an adsorption energy may alter a screening decision; and a failed recovery may leave a branch underexplored. Agents must therefore make clear the basis of each computed value, the remaining uncertainty, and the actions the result can justify.

Reported systems already show that agents can carry a computational materials task through input generation, software execution, output parsing, and limited repair. To date, these capabilities have mostly been demonstrated in settings with well-specified tasks and software configurations. Progress toward routine research use requires benchmarks that go beyond showing that a single example can run and instead test whether an agent remains reliable across task families, software environments, materials systems, and failure modes. Agent systems must also preserve the calculation route, assumptions, checks, recovery history, and uncertainty needed for other researchers to interpret or reuse the result.

The broader value of computational materials agents will depend on whether they enable computational workflows that are traceable, verifiable, and reusable. Their outputs need to be evaluated against relevant scientific standards and integrated responsibly into materials design, hypothesis testing, or experimental decision-making. Under these conditions, executable agent workflows may become a practical part of everyday materials research.