DREAMS

New materials for batteries and catalysts are screened by simulation before anyone synthesizes them. The workhorse method is density functional theory (DFT). DFT is hard to automate: each simulation needs settings that experts tune by hand, a single study can require hundreds of runs, and those runs must be mutually comparable. To compare N calculations, all N have to be run with compatible settings; otherwise the comparison, and any result built on it, is invalid.

DREAMS (DFT-based Research Engine for Agentic Materials Simulation) automates this work. It is described in the DREAMS paper (arXiv:2507.14267), where I am first author. This page covers the framework and its benchmark results.

(Automation at this level creates a second problem: an agent can report a correct-looking answer built on reasoning it never performed. The provenance records, verification systems, and safety guard that address this are covered on the Transparency, Provenance, and Trustworthiness page.)

One supervisor plans, specialized agents execute

DREAMS splits DFT work across a planning supervisor and specialized worker agents, so no single model carries the whole problem.

The supervisor turns a research objective into a task list and revises it as results arrive. A DFT agent builds crystal structures, runs convergence tests, prepares calculations, and analyzes and post-processes the results. An HPC agent allocates compute resources and submits and monitors jobs on the supercomputer. When a calculation fails, a dedicated convergence agent diagnoses it from the input and output files. Every agent reads and writes one shared memory, the canvas.

A shared memory keeps the agents consistent

All agents communicate through the canvas, a structured shared memory, instead of passing text to each other.

The figure shows one full communication cycle: the user’s request goes to the supervisor, the supervisor checks the canvas and assigns a task, and the worker agent reads what it needs from the canvas and calls its tools. The tools themselves also read from and write to the canvas, looking up prior information and storing new data and results before handing control back to the agent, which then writes its own results back. Keeping every value in its original form, rather than as text in a conversation, prevents copy errors and lost context during long runs.

The canvas records where every value came from, under which settings, and under which conditions, which is what makes provenance tracking and verification possible. That story continues on the trust page.

Benchmark 1: all 27 crystal structures correct (Sol27LC)

DREAMS reproduced 27 of 27 crystal structures on the Sol27LC lattice-constant benchmark, with average errors below 1% of human DFT expert results.

Sol27LC contains 27 elemental crystals with varying structures. For each one, DREAMS planned the workflow, chose its own simulation settings, submitted the calculations, and calculated the lattice constant, end to end, without human intervention.

DREAMS picks its own simulation settings by systematic convergence testing, the same way an expert would.

Every DFT setting trades cost against accuracy. Set it too fine and the calculation becomes too slow to ever finish; set it too coarse and the result cannot be trusted. Before running production calculations, DREAMS varies each numerical setting until the result stops changing, then locks in the point where the answer is stable at the lowest cost that still preserves accuracy. This is the step that normally consumes expert time and is skipped by naive automation.

Benchmark 2: the CO/Pt(111) puzzle to 0.2%

On the CO/Pt(111) adsorption puzzle, DREAMS reproduced the human expert answer to 0.2%, recovering from seven failed calculations on its own.

CO/Pt(111) asks which surface site a carbon monoxide molecule prefers on a platinum surface. It is a long-standing benchmark, chosen both for its sensitivity to calculation settings and for its industrial relevance: CO on platinum sits at the center of automotive catalytic converters and fuel-cell electrodes, and pinning down the preferred site has been a persistent test for simulation methods. Mid-run, DREAMS noticed a missing calculation script and revised its own plan; when seven of eight production jobs failed, the convergence agent diagnosed the failures and DREAMS resubmitted corrected calculations until all runs converged. Crucially, whenever it changed a setting on one calculation, it applied the same change to every related calculation. This matters because the final adsorption energy is a difference between separate calculations; if those calculations do not all share the same settings, the difference is meaningless and the entire run is invalid.

The convergence agent recovers failed calculations the way an experienced practitioner would, which a fixed pipeline cannot do.

When a calculation fails to converge, a traditional automated pipeline has no recourse: it cannot reason about why the failure happened. DREAMS’ convergence agent reads the failed run’s input and output files and proposes specific parameter changes, each with a justification grounded in DFT practice. The suggestions below are from the CO/Pt(111) run.

Each of these is a judgment an expert makes from experience, not a rule a pipeline can hard-code: recognizing charge sloshing from a mixing factor set too high, or seeing that a run was still improving when it hit its iteration limit. Automating this recovery is what lets DREAMS finish long, failure-prone studies without a person watching.

Quantifying the uncertainty of the physics itself

DREAMS quantified how much the CO/Pt(111) answer depends on the chosen physics approximation, and the site preference held across the whole uncertainty range.

Different DFT approximations (functionals) give different results. DREAMS ran a Bayesian ensemble analysis (BEEF-vdW) that samples thousands of plausible functionals, producing a distribution of answers instead of a single value. The agent’s distribution agrees with the human expert’s, and both keep the same site preference.

Against other agentic frameworks

On the harder CO/Pt(111) challenge, DREAMS completed 100% of steps at 0.2% error while baseline frameworks stalled or produced a 389% error, and it used 2 to 3x fewer tokens than the strongest baseline.

The two baselines represent different agent designs. MDCrow is an early single-agent framework, built on LangChain, that reasons and calls tools in one sequential loop, which limits how well it can coordinate multi-step dependencies. ChemGraph is a graph-based multi-agent framework, built on LangGraph, with modular coordination, but unlike DREAMS it has no specialized worker agents for domain-specific subtasks, no persistent communication layer for exchange between agents and tools, and no way to adapt its plan from intermediate results. To keep the comparison fair, both baselines were given the same DFT toolset as DREAMS, without the canvas, and only their prompts were adjusted to the DFT setting while preserving each framework’s original design (for example, “You are a molecular dynamics expert” became “You are a DFT expert”).

Each framework was run several times on both tasks, so the comparison measures reliability as well as accuracy, using four metrics: how many workflow steps it attempted, how many it completed successfully, the error of its final number, and the spread across repeated runs.

All three handle the short Sol27LC workflow. The differences appear on the long-horizon problem: MDCrow loses context and misuses tools; ChemGraph completes most steps but repeats calculations and overwrites intermediate files, producing an invalid answer. DREAMS keeps full context through the canvas and hierarchical communication, and its lower token usage comes from shared context and clear handoffs rather than repeated work.

What keeps the answers honest

A correct number means little if the reasoning behind it cannot be checked. Beyond reaching the right answer, DREAMS keeps its entire process transparent and traceable, and it judges every result strictly before that result is trusted. The provenance records, verification systems, and the safety guard that make this possible have their own page: Transparency, Provenance, and Trustworthiness.