Paper deep dive
El Agente Gráfico: Structured Execution Graphs for Scientific Agents
Jiaru Bai, Abdulrahman Aldossary, Thomas Swanick, Marcel Müller, Yeonghun Kang, Zijian Zhang, Jin Won Lee, Tsz Wai Ko, Mohammad Ghazi Vakili, Varinia Bernales, Alán Aspuru-Guzik
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 7/20/2026, 11:12:18 PM
Summary
The paper introduces 'El Agente Gráfico', a single-agent framework for scientific automation that utilizes structured execution graphs and dynamic knowledge graphs to manage computational state. Unlike previous multi-agent systems that rely on unstructured text, this approach uses typed Python objects and an object-graph mapper to ensure type safety, provenance tracking, and efficient orchestration of heterogeneous tools. The system is evaluated on quantum chemistry tasks, conformer ensemble generation, and metal-organic framework (MOF) design, demonstrating superior efficiency and robustness compared to multi-agent baselines.
Entities (10)
Relation Signals (9)
El Agente Gráfico → uses → GPU4PySCF
confidence 95% · We evaluate Gráfico on GPU-accelerated quantum chemistry tasks using GPU4PySCF.
El Agente Gráfico → uses → Knowledge Graph
confidence 95% · El Agente Gráfico persists computational state in an external knowledge graph via an object graph mapper.
El Agente Gráfico → uses → Object Graph Mapper
confidence 93% · Scientific state is represented as structured Python object graphs... persisted in an external knowledge graph via an object graph mapper.
Routing Agent → controls → Execution Graph
confidence 92% · The routing controller selects and invokes the next node via schema-conditioned structured output...
El Agente Gráfico → uses → ConceptualAtoms
confidence 90% · The ConceptualAtoms class provides a unified in-memory interface for molecular and periodic systems...
El Agente Gráfico → implements → pydantic-ai
confidence 88% · We implement the system using pydantic-ai, leveraging type hints and pydantic validation...
El Agente Gráfico → appliesto → Metal-Organic Framework
confidence 85% · We further extend this paradigm to... metal-organic framework design...
El Agente Gráfico → appliesto →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Large language models (LLMs) are increasingly used to automate scientific workflows, yet their integration with heterogeneous computational tools remains ad hoc and fragile. Current agentic approaches often rely on unstructured text to manage context and coordinate execution, generating often overwhelming volumes of information that may obscure decision provenance and hinder auditability. In this work, we present El Agente Gráfico, a single-agent framework that embeds LLM-driven decision-making within a type-safe execution environment and dynamic knowledge graphs for external persistence. Central to our approach is a structured abstraction of scientific concepts and an object-graph mapper that represents computational state as typed Python objects, stored either in memory or persisted in an external knowledge graph. This design enables context management through typed symbolic identifiers rather than raw text, thereby ensuring consistency, supporting provenance tracking, and enabling efficient tool orchestration. We evaluate the system by developing an automated benchmarking framework across a suite of university-level quantum chemistry tasks previously evaluated on a multi-agent system, demonstrating that a single agent, when coupled to a reliable execution engine, can robustly perform complex, multi-step, and parallel computations. We further extend this paradigm to two other large classes of applications: conformer ensemble generation and metal-organic framework design, where knowledge graphs serve as both memory and reasoning substrates. Together, these results illustrate how abstraction and type safety can provide a scalable foundation for agentic scientific automation beyond prompt-centric designs.
Tags
Links
- Source: https://arxiv.org/abs/2602.17902v1
- Canonical: https://arxiv.org/abs/2602.17902v1
Trouble viewing inline? Open PDF directly →
Full Text
176,484 characters extracted from source content.
Expand or collapse full text
El Agente Gráfico: Structured Execution Graphs for Scientific Agents Jiaru Bai 1,2,†, , Abdulrahman Aldossary 1,2,†, , Thomas Swanick 3,4, , Marcel Müller 1,2, , Yeonghun Kang 1,2, , Zijian Zhang 2,3, , Jin Won Lee 5, , Tsz Wai Ko 1,2, , Mohammad Ghazi Vakili 1,2,3, , Varinia Bernales 1,3,9,∗, , Alán Aspuru-Guzik 1,2,3,6,7,8,9,10,11,∗, 1 Department of Chemistry, University of Toronto, 80 St. George St., Toronto, ON M5S 3H6, Canada 2 Vector Institute for Artificial Intelligence, W1140-108 College St., Schwartz Reisman Innovation Campus, Toronto, ON M5G 0C6, Canada 3 Department of Computer Science, University of Toronto, 40 St George St., Toronto, ON M5S 2E4, Canada 4 Department of Mathematics, University of Toronto, 40 St George St., Toronto, ON M5S 2E4, Canada 5 School of Computer Science, McGill University, 3480 University St., Montréal, QC H3A 0E9, Canada 6 Department of Materials Science & Engineering, University of Toronto, 184 College St., Toronto, ON M5S 3E4, Canada 7 Department of Chemical Engineering & Applied Chemistry, University of Toronto, 200 College St., Toronto, ON M5S 3E5, Canada 8 Institute of Medical Science, 1 King’s College Circle, Medical Sciences Building, Room 2374, Toronto, ON M5S 1A8, Canada 9 Acceleration Consortium, 700 University Ave., Toronto, ON M7A 2S4, Canada 10 Canadian Institute for Advanced Research (CIFAR), 661 University Ave., Toronto, ON M5G 1M1, Canada 11 NVIDIA, 431 King St W #6th, Toronto, ON M5V 1K4, Canada † Contributed equally to this work. Large language models (LLMs) are increasingly used to automate scientific workflows, yet their integration with heterogeneous computational tools remains ad hoc and fragile. Current agentic approaches often rely on unstructured text to manage context and coordinate execution, generating often overwhelming volumes of information that may obscure decision provenance and hinder au- ditability. In this work, we presentEl Agente Gráfico, a single-agent framework that embeds LLM-driven decision-making within a type-safe execution environment and dynamic knowledge graphs for external persistence. Central to our approach is a structured abstraction of scientific concepts and an object-graph mapper that represents computational state as typed Python objects, stored either in memory or persisted in an external knowledge graph. This design enables context management through typed symbolic identifiers rather than raw text, thereby ensuring consistency, supporting provenance tracking, and enabling efficient tool orchestration. We evaluate the system by developing an automated benchmarking framework across a suite of university-level quantum chemistry tasks previously evaluated on a multi-agent system, demonstrating that a single agent, when coupled to a reliable execution engine, can robustly perform complex, multi-step, and parallel computations. We further extend this paradigm to two other large classes of applications: conformer ensemble generation and metal-organic framework design, where knowledge graphs serve as both memory and reasoning substrates. Together, these results illustrate how abstraction and type safety can provide a scalable foundation for agentic scientific automation beyond prompt-centric designs. Date: February 23, 2026 Correspondence: varinia@bernales.org and alan@aspuru.com 1 arXiv:2602.17902v1 [cs.AI] 19 Feb 2026 1 Introduction The integration of large language models (LLMs) into scientific workflows enables agents to invoke external tools and orchestrate multi-step procedures (1;2;3;4;5;6;7;8;9;10;11;12;13). These agents can parameterize function calls, reason over quantitative outputs, and synthesize results conversationally. In our previous work,El Agente Q(5) introduced a computational chemistry agent, reporting>87 % accuracy using a multi-agent architecture. A new family of agentic frameworks based on this architecture is expanding into a wide variety of applications (14; 15; 16; 17). To mitigateLLMcontext limits, a common approach is multi-agent decomposition to reduce per-agent context load (18), but this introduces coordination and verification failures typical of multi-agent systems (19;20). Consistent with this view, recent work (21) reports diminishing or negative returns from coordination once a single agent exceeds a moderate capability threshold. These limitations are acute in scientific computing, where numerical correctness and state fidelity dominate over conversational coherence. Numerical simulation pipelines generate large volumes of structured data and binary artifacts (22;23) that are impractical to transmit throughLLMcontext windows. Several systems, therefore, externalize execution metadata; for example, DREAMS (10) uses a centralized “canvas” to track calculation status and file paths. However, repeated disk-based (de-)serialization of large objects can still impose substantial overhead, especially in GPU-accelerated settings (24;25). A further barrier is software heterogeneity: workflows span diverse molecular formats [e.g.,xyz, SELFIES (26), InChI (27)] and large configuration spaces, making misconfiguration both common and costly. Hard-coded converters and probabilistic LLM-based glue remain brittle at scale and under composition. We argue that these issues share a root cause: the execution context is treated as unstructured and ephemeral, rather than a first-class representation of the scientific state. Scalable agents require execution state to be explicitly typed, validated, and decoupled from transient textual context (28). A typed abstraction layer enables safe state transmission across heterogeneous tools, supports automated trace validation and benchmarking, and preserves provenance of intermediate results. In this work, we presentEl Agente Gráfico, a single-agent framework with a type-safe execution environment for scientific workflows. Scientific state is represented as structured Python object graphs through a typed abstraction layer and is persisted in an external knowledge graph (KG) via an object graph mapper (OGM). We evaluateGráficoon GPU-accelerated quantum chemistry tasks using GPU4PySCF (24) and demonstrate its extensibility through case studies in conformer search for Boltzmann-weighted spectroscopy in solution and metal-organic framework (MOF) design. An overview of the main components ofGráfico can be found in Figure 1. 2 Results We first discuss the architecture ofGráfico, the underlying technology, and the tools used. We then discuss the results of the quantum chemistry exercises, comparing differentLLMs with respect to performance and cost. Finally, we present two case studies that demonstrate applicability to other tools, namely conformer search and MOF design. 2.1 System design Figure 2 presents an overview of theGráficoarchitecture, highlighting its core design principles and modular components. We describe the key elements below to provide context for how the system enables structured, extensible scientific workflows. Execution Graph At its core,Gráficoexposes typed execution graphs as tools, reducing context pressure by treating workflows as validated state transformations rather than free-form text. In the GPU4PySCF workflow, for example, the key challenge is managing complex intermediate objects (e.g., mean-field state) that are expensive to recompute and impractical to serialize throughLLMcontext windows. We encode single-point, geometry optimization, frequency, and time-dependent density functional theory (TDDFT) 2 Here are 20 conform ers of the system ! selected: O1 Live Sof t w ar e & Tools Ask or chat with El Agente Gráfico! What is the DMSO solvation effect? MCP code execution Web search Knowledge graph query Execu t ion Gr aph s Gr aph Ch at Functional Solvation DFT Calculation DFT Result Energy Object Gr aph M apper M OF GPU4PySCF Rou t er Agen t XYZ UnitCell Frequency Conceptual Atom s BasisSet PORMAKE CrystalNets Gen er al pu r pose t ools Ot h er t ools MOFid Figure 1 High-level illustration showing the main components ofEl Agente Gráfico: (i) GraphChat as the user interface, displaying real-time events such as geometry optimization; (i) the object graph mapper (a customized version of Ref. (29)) is used to (de)serialize Python objects into a knowledge graph; (i) execution graphs for the main workflows with router agents; and (iv) additional tools, including web search, sandboxed code execution, and knowledge graph interaction. The GraphChat user interface can be viewed from the Supplementary Video https://w.youtube.com/playlist?list=PLaUD8plXw_ecR7A1EwVAKL3pzIZqjvuVU. calculations as nodes connected by directed edges that define admissible data flow, including conditional and cyclic transitions (e.g., imaginary-frequency checks). Routing Agent When the graph tool is invoked, the agent supplies a summary of the user’s request and initial configurations to the start node. When multiple successor nodes are admissible, a focused routing controller (anLLMcall) selects and invokes the next node via schema-conditioned structured output that both constrains transitions and instantiates valid inputs. The controller can also terminate early once the request is satisfied. Abstraction Layer Across heterogeneous packages, theConceptualAtomsclass provides a unified in-memory interface for molecular and periodic systems, including charge/multiplicity verification. Package-specific input/output classes composeConceptualAtomsfor state representation, enabling on-the-fly transformations (e.g., conformer sampling followed by electronic-structure calculations) while maintaining direct Python object references for zero-copy state transfer. 3 Memory Management Python objects created by the agent, either directly or through the execution graph, are persisted to a graph database (KG). TheOGMserializes the Python instances intoKGentries with unique identifiers (internationalized resource identifier (IRI)) for subsequent retrieval. This enables retrieval of prior results and allows “heavy” scientific data to propagate across computation stages without repeated serialization or re-initialization, while also supporting relation-aware queries over persisted state. Tools and Implementation We implement the system usingpydantic-ai, leveraging type hints andpydantic validation for runtime type safety and schema enforcement across all graph transitions. Domain-specific tool chains used in this work (molecular generation, quantum chemistry, machine-learned force fields, conformer search, andMOFanalysis) are detailed in section 5.2. Additionally, the agent has general-purpose tools for web search, sandboxed code execution, and KG retrieval. Execution Journey The execution journey begins when the agent invokes the graph tool per molecule, instantiating multiple graphs in parallel. For each execution graph, the agent initializes the appropriate ConceptualAtomssubclass, a summarized user request, and the configurations needed for the entry node (typically a single-point calculation). If initial configurations are invalid (e.g., incorrect charge/multiplicity), theLLMis automatically reprompted for correction. Each graph initializes with isolated GPU execution contexts to maximize parallelism, typically with three concurrent calculations per GPU. The routing controller then selects subsequent nodes, parameterizing any intermediate settings until the graph exits. The agent retrieves the results, each containing an instance of ConceptualAtoms, executes any subsequent graph/tool calls as needed, and finally responds to the user’s request. UserGr áf ico a) Syst em over view tool call d) Dyn am ic r ou t in g or exit (En d N ode) -Collect outputs (as tool results) -Updat e k n ow ledge gr aph (if configured) d) c) Sh ar ed r u n t im e st at e Gr aph Depen den cies -Frontend access port -Graph database endpoint Wor k f low St at e (t yped) -ConceptualAtoms -Large num erical arrays -Node specific inputs -Node local outputs Wor k in g M em or y (t ext u al) -Sum m arised user intent -Node execution sum m aries Object s shipped in Python memory Geom et r y Opt im isat ion Fr equ en cy Calcu lat ion Im agin ar y Fr eq. Rem oval M olecu lar An alysis St ar t N ode: Single Point Calculation b) GPU-acceler at ed PySCF execu t ion gr aph (t yped) 1 supports directed cyclic graph 2 3 d) ever y n ode can term inate c) c) TD-DFT Wor k in g Su m m ar y Node A: [sm iles: ... Node B: [coord: ... adm issible n ext n odes 3 2 In pu t sch em a "key": ... 1 -Reasoning -Confidence -Generated inputs "key": ... 3 select n ext n ode Rou t er LLM (in -gr aph ) user prom pts and interaction stream ed events t r igger f u r t h er r ou t in g n ode execu t ion Figure 2 Overall structure ofEl Agente Gráfico: (a) Users can interact withGráficothrough prompts or by uploadingxyzfiles, whileGráficoprovides real-time updates of calculations and molecular trajectories; (b) Typed execution graph for GPU4PySCF showing the execution nodes with multiple admissible states that are controlled by the router agent; (c) Generated runtime (typed) states are kept in the knowledge graph for later retrieval and allow real-time user inspection; (d) Routing agent allows for schema-compliant decision making while instantiating typed arguments to the next node. 4 2.2 Benchmark for performance evaluation University-level quantum chemistry exercises We evaluateEl Agente Gráficoon six quantum chemistry exercises fromEl Agente Q(5), each with two difficulty levels. Tasks include analysis of organic/inorganic molecules, hydrogen-abstraction energetics, cycloalkane ring strain, pKa prediction for halogenated acetic acids, andTDDFTexcited-state energies. Prompts and rubrics are provided in Supplementary Sec. B.2 and B.3. Each task was repeated ten times, for a total of 120 runs per evaluated LLM. Models We selected eightLLMs for comparison, including both open-source and proprietary frontier models. For benchmarking, the agent was restricted to the PySCF workflow, code execution, and unit conversion tools to avoid unnecessary degrees of freedom in the evaluation setting, and the routing controller was fixed as gpt-4o-mini. Within this controlled execution framework, each evaluatedLLMwas responsible solely for planning and tool parameterization, thereby enabling direct comparison of agent reliability under identical constraints. 2.2.1 Automated evaluation framework Evaluation Strategy EvaluatingLLM-driven scientific agents poses unique challenges due to their stochastic decision-making, multi-step tool use, and the absence of a single ground truth in text-based outputs. To enable scalable benchmarking, we implemented a fully automated evaluation framework usingpydantic-evalsthat operates directly on execution traces and structured outputs. In line with the recommended best practices (30), we adopt a dual-evaluator design that independently assesses: (i) computational correctness, and (i) semantic task adherence. The computational evaluator is a deterministic numerical checker that verifies the validity of Python objects produced by the agent’s execution graph (e.g., energies and geometries; details are provided in section 5.1). The semantic evaluator uses anLLM-as-a-judge to assess task completeness, reasoning, and reporting quality based on the full agent trace, including all tool calls and final text outputs. Metrics For each model, we report the numerical andLLMjudge evaluation scores, averaged across all runs. Over the agentic trace, we also track total tokens, monetary cost, and the number of application programming interface (API) requests. During an agentic trace, all previous messages are resent to theLLMprovider, creating a “snowball effect” that typically leads to accumulating token costs, particularly when accounting for tokens induced by re-prompting models in the event of errors. To further understand the impact of varying LLMbehaviours, we introduce additional metrics: (i) context window saturation, which measures the ratio of the total tokens in the finalLLM APIrequest to its maximum context window allowed by the provider; (i) error recovery cost, which is associated with the exceptions and tracebacks provided to the model during error handling; and (i) carryover tokens, defined as the ratio of accumulated cacheable tokens to the total tokens consumed throughout the agentic trace. This metric highlights the importance of careful cache management for efficient agentic systems over long-horizon tasks. While many providers offer reduced rates for cached tokens, implementation varies across providers. For simplicity, our calculations rely on raw token counts and original pricing rather than cached rates. The monetary cost could be further reduced by employing additional caching strategies 1,2 or deploying local models. In Table 1, we show a summary of the benchmarking experiment. Compared toEl Agente Q(5), which adopts a multi-agent architecture driven bysonnet-3.7,Gráficoachieves substantially higher efficiency in both monetary cost and wall-clock time. Operational cost drops from $4.67 to as low as $0.17 withgpt-5 (≈96% reduction), while wall-clock time decreases from 1,827 s to 200–300 s (≥6xspeedup), along with a reduction in trace token consumption from∼1.6Mto∼100k. These gains arise primarily from the single-agent execution-graph design, which eliminates inter-agent communication overhead that would otherwise amplify LLM APIrequests in multi-agent systems. The reduction in execution time further demonstratesGráfico’s ability to exploit parallelized, GPU-accelerated PySCF workflows without incurring coordination latency. For computational chemistry workflows characterized by sequential reasoning and strict numerical validation, these results imply that once a single agent reaches a high baseline accuracy, additional multi-agent coordination is unlikely to yield proportional performance gains. Instead, a single agent can provide optimal accuracy 1 https://platform.claude.com/docs/en/build-with-claude/prompt-caching 2 https://openrouter.ai/docs/guides/best-practices/prompt-caching 5 Table 1 Performance benchmarking ofLLMdrivers within theGráficoarchitecture, averaged over 6 exercises with 2 difficulty levels repeated 10 times, for a total of 120. The token cost assumes no cached tokens. Context window saturation is the number of tokens used in the lastLLM APIrequest of the trace divided by the maximum context window. Retry cost captures error-recovery overhead. Carryover tokens capture repeated processing of cacheable tokens across successive calls. All calculations were performed on a compute node with 4 H100 GPUs, a maximum concurrency of 3 calculations per GPU, and 4 agents running in parallel. The specification of eachLLMis provided in Supplementary Sec. B.1. LLM model Numerical eval. (%) LLM Judge eval. (%) Trace tokens LLM API requests Token cost (USD) Task duration (s) Context window saturation (%) Error recovery cost (%) Carryover tokens (%) El Agente Q (5) 88.25 with human eval 1,649,616 168.434.671,827n/an/an/a gpt-4.193.7196.52113,1755.110.252083.598.1766.79 gpt-598.8898.5083,6133.320.17 2289.789.5953.21 gpt-5.198.3796.6199,7753.650.1721110.438.6958.19 gpt-5.298.6996.1995,1534.400.221808.428.2764.59 minimax-m289.6687.61210,0186.400.0531521.9316.3878.60 qwen3-max93.5490.33178,6713.840.2429626.2711.8261.45 sonnet-3.793.6990.94284,0369.140.9240419.465.0786.30 sonnet-4.596.0795.67320,3976.581.0927326.799.0283.28 and cost, particularly for sequential reasoning tasks, in which multi-agent systems can exhibit up to 39–70% performance degradation (21). Beyond aggregate efficiency We observe a consistent pattern in performance reflected in reasoning behaviour across model generations within the GPT family. In the ring strain level 2 task,gpt-4.1frequently generates cycloalkenes instead of cycloalkanes, which is resolved in later generations ofgpt-5.xor in level 1, which includes more hints. The scores for each exercise can be found in Supplementary Figure S1 and S2. Under a fixed reasoning budget (configured by the samereasoning_effortparameter), threegpt-5.xmodels achieve comparable accuracy, while their reasoning token consumption decreases monotonically across generations (see Supplementary Figure S10), consistent with prior observations in pureLLMbenchmarks (31;32). As raw accuracy approaches saturation, gains across model generations increasingly manifest as reductions in token usage rather than further accuracy improvements, aligning with independent analyses reporting a sharp decline in the “cost of intelligence” (33). We also observe systematic differences in interaction patterns between GPT and Claude models that affect workflow efficiency: GPT tends to batch and parallelize tool calls, while Claude more often interleaves incremental reasoning with serial tool use. In our setting,sonnet-3.7is costlier due to limited parallelization of GPU4PySCF workflows, whereassonnet-4.5incurs overhead from frequent code-execution calls, suggesting that better-aligned (or more specialized) tools could reduce unnecessary invocations. This divergent interaction behaviour further reveals a critical engineering challenge: the need to reconcile agentic systems with the temporal constraints of provider-side prompt caching (typically a 5-minute time-to-live (TTL)). For high-concurrency models, this results in an “all-or-nothing” cost profile, where the delay of a single tool to return within theTTLwindow can trigger a costly re-computation of the entire context. Full discussions can be found in Supplementary Sec. B.5. This dual-evaluator design proved essential in practice; across repeated runs of the same task, agents frequently exhibited variability in workflow structure and reporting style despite executing similar underlying computations. The numerical evaluator remained stable across such variations, while theLLMjudge captured differences in task completeness and interpretability. To rigorously evaluate agent performance beyond statistical means, we adopt two complementary metrics that balance capability and reliability: pass@k (34) and passˆk (30). We define pass as numerical score equals to 1.00 and LLM-as-a-judge score greater than 0.90 and achieve pass@3 of 0.99 and passˆ3 of 0.51 with gpt-5. Details can be found in Supplementary Sec. B.4. 6 A lightweight “bare”LLMagent An agent equipped only with web search and code execution was tested on two El Agente Qtasks: inorganic compounds (L1) and pKa prediction (L2) usinggpt-5. These two exercises examine theLLM’s ability to perform multi-step tasks that cannot be performed with a single command in PySCF. While it could script molecule setup and PySCF runs through trial and error, it failed key scientific checks and was inefficient compared toGráfico. For the inorganic (L1) task, the bare agent built molecules with OpenBabel and ran GPU4PySCF geometry optimization followed by single-point calculations. However, it made errors in point-group detection and population analysis, omitted frequency/imaginary-mode handling, and produced the wrong ClF 3 geometry (trigonal planar instead of T-shaped). For pKa (L2), it performed geometry optimization and Gibbs free energies but handled solvation incorrectly, by mixing up COSMO solvation vs. deprotonation energy, and did not check for imaginary frequencies, yielding pKa≈−5.0, which is outside the acceptable range in the rubric. The runs consumed∼40 min/650k tokens (inorganic) and∼16 min/450k tokens (pKa), roughly an order of magnitude more tokens thanGráficowhen usinggpt-5(∼3 min/25k tokens for inorganic L1 and∼5 min/122k tokens for pKa L2). Due to the stochastic nature of these runs, it was infeasible to evaluate them automatically with repetition. The lightweight agent’s capability for on-the-fly web search and iterative code execution nonetheless demonstrates its potential for bootstrapping tool generation. Full discussion of these results, including session transcripts, can be found in Supplementary Sec. B.6. 2.3 Extending the abstraction We now demonstrate the extensibility of theGráficoarchitecture by introducing additional specialized tools, showcasing use cases in two distinct fields that leverage advanced workflow orchestration capabilities. These examples illustrate howGráficocan accommodate complex, multi-step computational chemistry tasks that require dynamic decision-making, parallel execution, and robust error handling. More importantly, they demonstrate the practical utility of the OGM-backedConceptualAtomsabstraction for seamless data exchange across different packages and workflow stages, while supporting persistent storage and retrieval through a shared KG. 2.3.1 Boltzmann-weighted spectroscopic properties in solution Chemical processes are rarely governed by a single static molecular structure; instead, thermodynamic ensembles usually comprise many distinct conformations that contribute to observable properties (35). Accurate prediction of spectroscopic properties, therefore, requires explicit conformer sampling and Boltzmann- weighted ensemble averaging, motivating the use of modern conformer-search algorithms beyond brute-force molecular dynamics (35;36;37;38). To demonstrate agentic atomistic simulation workflows that coordinate conformer sampling, solvation modelling, and spectral analysis, we assessed solvent effects on electronic absorption spectra under both implicit and explicit solvation. In both cases,Gráficoenables reproducible across-tool handoff via persistentConceptualAtomsidentifiers. Further discussions and methodological details on conformer ensemble generation and Boltzmann-weighted spectral construction are provided in Supplementary Sec. C. A summary of the case studies is presented in Figure 3, which shows the tasks and plots generated by Gráfico. Implicit solvation To investigate the effect of different implicit solvents on the absorption spectra of a mero- cyanine compound (see Supplementary Sec. C.1),Gráficoperformed independent and concurrent CREST conformer searches at the GFN2-xTB/ALPB level (39;40) for water and n-heptane. TheConceptualAtoms identifiers served as lightweight handles for dispatching downstream PySCF workflows in parallel, resulting in five and four density functional theory (DFT) calculations, respectively, for water and n-heptane at the ωB97X-D4 (SMD)/def2-TZVP level (41;42;43;44). In the water pipeline, one conformer exhibited an imagi- nary frequency after optimization; consequently, the router returned control to the main agent, prompting it to reuse the intermediate geometry in a targeted repair loop before proceeding toTDDFT. After deduplication of conformers using an energy-based filter with additional root mean square deviation (RMSD) validation, and recomputation of Boltzmann weights fromDFTenergies, ensemble absorption spectra were generated via weighted Gaussian broadening. Under the chosen model and broadening parameters, the ensemble maxima for water and n-heptane overlapped closely, indicating minimal spectral shifts induced by the implicit solvation. 7 Figure 3 Generation of Boltzmann-weighted absorption spectra using time-dependent density functional theory (TDDFT), showingGráficogenerating (solvated) conformers and passing their internationalized resource identifiers (IRIs) to (GPU4)PySCF. Absorption spectra plots were generated withGráfico. In the top plot, the geometry was provided in the prompt (not shown here). Prompts were summarized for brevity; complete prompts and transcripts are provided in Supplementary Sec. C. This query was completed in 35 minutes with 440k tokens costing $1.11 withgpt-5.2(medium reasoning effort). Effect of explicit solvation To capture explicit solute–solvent interactions,Gráficocompared absorption spectra of 2,3-epoxybutanol (45) in the gas phase and in explicit solvation within a single execution (see Supplementary Sec. C.2). Gas-phase conformers were generated using CREST, while, in parallel, an explicit solvation shell of 15 water molecules was constructed around the solute using quantum cluster growth (QCG) (46) and further sampled with CREST in its non-covalent interaction (--nci) mode. Conformers contributing up to 95 % cumulative Boltzmann weight were refined at theωB97X-D4 (SMD)/def2-SVP, andTDDFTcalculations were executed concurrently to exploit conformer-level parallelism. Spectra were subsequently broadened and combined for a direct visual comparison. The explicitly solvated ensemble exhibits a pronounced solvent-induced red shift of the dominant absorption band relative to the gas-phase spectrum, consistent with stabilization of the excited state by the surrounding water cluster. Together, 8 this demonstrates an agentic system that performs high-level scientific planning over a structured scientific state while orchestrating stochastic sampling, explicit solvation, and electronic-structure calculations within a unified workflow. This query was completed in 30 minutes with 185k tokens costing $0.44 withgpt-5.2 (medium reasoning effort). 2.3.2 Interactive design for metal-organic frameworks Reticular chemistry reframes crystalline materials as assemblies of modular building blocks constrained by topological frameworks, generating an immense combinatorial space that is ideal for graph-based reasoning (47; 48;49). Navigating this vast landscape (50;51) requires the orchestration of heterogeneous data sources (52;53) and specialized tools ranging from structure generation (54;55;56) to high-throughput GPU-accelerated machine-learned interatomic potentials (MLIPs) (57;58;59). Connecting these isolated computational steps into a coherent discovery process requires a stateful representation that preserves context across tools. To demonstrate this agentic reticular design paradigm, we tasked the agent with incrementally constructing and exploring aKGof experimentally reported, hypothetical, and graph-inferredMOFs. Further discussions and methodological details are provided in Supplementary Sec. D. Figure 4 TheMOFworkflow includes: (1) structure acquisition by CCDC refcode (60) from CoRE-MOF database (52), (2) semantic decomposition of CIF files into topology, metal nodes, and organic linkers, (3) combinatorial search within KGto propose new hypotheticalMOFs, (4)MOFconstruction with PORMAKE (56), (5) geometry optimization using GPU-acceleratedMLIPs, and (6) porosity analysis using Zeo++ (61). These tools allowGráficoto process, propose and analyze newMOFs, as well as perform the necessary queries for both in-memory and external graph. Prompts were summarized for brevity; complete prompts and transcripts are provided in Supplementary Sec. D. Buildandexplore We taskedGráficowith processing CIF files and hypotheticalMOFs based on the building blocks, and propose newMOFs accordingly (see Figure 4 (b) Q1). To build the requestedMOFs,Gráfico 9 dispatched seven parallel workflows (see Supplementary Sec. D.2.1). Across concurrently executed tasks, a deduplication strategy managed by theOGMensured that topology and building blockIRIs remained unique and consistent. This was achieved via a “retrieve-or-create” strategy across both in-memory canonicalization of Python objects andKGpersistence. To propose newMOFs,Gráficoperformed a combinatorial search based onKG, enumerating feasible (topology, metal node, and organic linker) combinations derived from the accumulated graph entities, and the workflow subsequently built and analyzed seventeen hypothetical MOFs. Candidates were ranked by surface area, identifying the highest-performing structures among both experimentally sourced and newly proposedMOFs. Agent analysis of the generated structures concluded that altering topology while keeping the components fixed could strongly decouple pore size from surface area, offering a distinct design lever relative to linker substitution. This query was completed in 10 minutes, consuming 124k tokens and costing $0.16 with gpt-5.2 (medium reasoning effort). Cross-session persistence We asked the agent in a new session to query theKGfor all previously investigated MOFstructures containing a specific metal node, group them by topology, and summarize the observed trade-offs between pore size and surface area (Figure 4 (b) Q2, see Supplementary Sec. D.2.2). The agent inspected the ontology to identify relevant classes and properties, composed targeted graph queries to retrieve the persisted structures along with their porosity descriptors, wrote Python code to compute per-topology statistics and rank structures, and synthesized a concise takeaway. It concluded that for a given topology, increasing pore size, especially pore limiting diameter, was associated with a higher accessible surface area, whereas across topologies they did not correlate. Framework density and surface-to-volume effects can cause very large-pore variants to underperform smaller but more accessible ones. This query was completed in 2 minutes, consuming 136k tokens and costing $0.20 using gpt-5.2 (medium reasoning effort). 3 Discussion The development and evaluation ofGráficoyield several critical insights into the design of robustLLM- driven scientific systems. Our work shows that scaling scientific agents requires shifting from prompt engineering to context engineering 3 by externalizing and typing scientific state (viaOGM/ConceptualAtoms) such that control remains lightweight, token-efficient, and robustly parallelizable. Herein, we discuss the lessons learned and the limitations of our design, along with an outlook toward future work. These are summarized in the roadmap in Figure 5. Codegenerationagents From the “bare”LLMexercise, we found that the outputs are only trusted after domain experts manually audit both the generated code and the scientific results. This shifts the cognitive burden from tool design to results evaluation post-query, consistent with analyses of AI-assisted engineering (62). These unconstrained systems (bare agents equipped with code execution and web search) can function as developmental scaffolding, rather than as reliable scientific copilots. In domains with real-world consequences, such as self-driving labs (63;64;65;66), strict and validated experimental procedures prior to execution necessitate structured frameworks (67). Trust through structured execution A scientific copilot is only as useful as the trust it engenders in its outputs. We therefore embrace engineering techniques that makeLLM-driven systems more reliable and scalable (68).Gráficoenforces schema validation withpydanticbefore tools run and execute code in controlled environments, aligning with emerging practices in autonomous laboratory systems (67). To avoid the information overload often caused by overly verboseLLMoutputs (69),Gráficoexposes a curated, state-driven interface that makes the internal states co-observable to users and agents alike in real time. For example, the user can inspect three-dimensional molecular structures in real time during geometry optimization and review explicit execution traces and logs. Bridging the engineering gap Building on this, we envision a shift in scientific software development focused on runtime-generated tool repositories (70; 71). While lightweight agents incur high token costs and require the supervision noted above, their capacity to rapidly generate functional prototypes marks a new frontier, 3 https://w.anthropic.com/engineering/effective-context-engineering-for-ai-agents 10 reducing hours of manual development to moments. We argue that the primary challenge is no longerLLM code generation capability, but rather the transition from agent-generated prototypes to robust systems. By automating ground-truth generation and verification loops, one can harness the speed of rapid prototyping while maintaining the scientific rigour essential to the field. 0 Text-centric agentic system Agen t ic Ar ch it ect u r e Ch em ist r y Capabilit y St r u ct u r ed execu t ion -Typed execution graph -KG for persistence 1 Dist r ibu t ed & lon g-h or izon agen t s -Self-driving labs -Multi-m odal m onitoring -Web of agents -Self-evolving agents 4 Sem an t ic bou n dar y evolu t ion -Reaction networks -Hypothesis generation -Ontology evolution -Versioned tool generation 3 Asyn ch r on ou s & r esou r ce-aw ar e -Full PySCF functionalities -MLIP and MD -Partial results return -Docker and sandbox 2 Figure 5 Current stage and roadmap of future work showing: (1) structured execution of typed execution graphs and tools (as implemented in the currentGráficosystem); (2) asynchronous and resource-aware execution to enable proactive agents; (3) semantic boundary evolution allowing rapid extension of tools and ontologies; (4) long-horizon agents towards a distributed network of AI scientists. Asynchronous and resource-aware environment The current single-runtime design enables low-overhead, in-memory state sharing but implicitly couples workflows through global GPU contexts and dependencies, requiring careful parallelism configuration (e.g., multi-threading or by the launch of computational subprocesses) and making hardware resource policies implicit. Moreover, maintaining heterogeneous tools via custom forks is brittle and does not scale. Future work will encapsulate domain-specific workflows as portable agent skills 4 , expose resource and environment primitives as first-class concepts (e.g., device selection, memory/concurrency limits), and adopt hybrid, selectively isolated containerization and/or sandboxing (72) for high-risk tools to balance fault containment and reproducibility with low-latency composability. Semantic boundary evolutionGráficosemantic boundaries are reflected in both the design of the ontologies underlying the execution graphs and the automatic evaluation. Nonetheless, the benchmark construction and the underlying ontological definitions remain time-consuming and laborious. Because agents are inherently probabilistic, they often discover solution pathways that fall outside manually-specified rubrics, making it increasingly difficult to evaluate accurately (73;74). These observations allude to a central challenge for future research, which is the co-evolution of semantic representation and the evaluation framework, in direct analogy to how unit tests co-evolve with software. Future work will expand the semantic space through controlled ontology refinement to guide adaptive tool generation while simultaneously updating the evaluation criteria. Progress along these directions would transform benchmarking from a manual, post-hoc process into an integral component of agentic system design and optimization. Distributed and long-horizon tasks Distributed and long-horizon tasks require more advanced context man- agement strategies. WhileGráficoeffectively externalizes state to minimize token usage, the current design assumes a single-agent, single-session context operating over a persistentKG. Extending this to 4 https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills 11 multi-agent collaboration or long-term operation introduces not only challenges in synchronizing shared state, managing divergentKGs, and ensuring consistency across sessions, but also the need for richer context graphs that capture evolving decision traces across agents and time 5 . Future work could explore distributed KGarchitectures, versioned ontology expansion synchronization withgit 6 , and inter-agent communication protocols to support collaborative scientific workflows. Additionally, mechanisms for temporal reasoning and memory consolidation would enable agents to build upon prior knowledge over extended time horizons. 4 Conclusions In this work, we introduceEl Agente Gráfico, a type-safe agentic framework that embedsLLMreasoning within explicit execution graphs and structured computational state, enabling robust orchestration of complex scientific workflows. By representing scientific concepts, intermediate results, and execution context as typed objects (rather than unstructured text), the system decouples high-level decision making from low-level execution while preserving provenance and auditability. Across quantum chemistry and materials design tasks, including conformer search andMOFdesign space exploration, this architecture supports parallel execution and failure recovery, with efficient context management enabling these tasks to run within a single agent. Benchmarking against a previous multi-agent system (5) demonstrated over a 14-fold reduction in token usage with overall improved accuracy. Our results suggest that as agentic systems move toward persistent, stateful operation, their reliability is increasingly governed by execution semantics rather than by prompt engineering alone: specifically, by how tools and concepts are represented and constrained. By foregrounding type-safe abstractions and explicit execution structure, this work reframes agentic scientific workflows as a systems engineering problem and provides a concrete foundation for scalable and extensible AI-driven scientific discovery. Ultimately, we envision deployingGráficoas part of theEl Agentefamily (5;14;15;16;17) on the cloud, facilitating the global democratization of science. 5 Methods 5.1 Gráfico infrastructure The object graph mapper (OGM) in this work is a customized version of the World Avatar (75;76;77) Python packagetwa(29), refactored to provide a fully Python-native interface and to align more closely with Pydantic data structures and usage patterns. This OGM provides a bidirectional serialization layer in which Python classes are mapped to classes and relationships in ontologies, with strict type enforcement. Key custom features include a lazy-loading mechanism that efficiently retrieves subgraph data on demand when processing large-scale ontologies, and specialized support for serializing NumPy arrays usingnumpydantic. By integrating withrdflibandpydantic-ai, the OGM ensures that complex chemical data structures are represented with formal semantic validation while maintaining idiomatic Python interoperability for downstream integration with LLM-based agents. The computational chemistry agent was instantiated using thepydantic-aiframework, configured with a system prompt that injects the workflow constraints and domain-specific instructions. Tools are strictly typed using Pydantic models and registered via a tool decorator or through the tools list, enabling the LLMto invoke complex functions with validated schemas. The framework’s dependency injection system is critical for our architecture, passing aGraficoDepsobject to tools that provide access to shared resources like the frontend andKGendpoints. We also leverage pydantic-ai’s model context protocol (MCP) support to integrate external execution environments (e.g., a sandboxed Python runner) and itsModelRetrymechanism to handle tool execution failures by providing feedback loops back to the model. TheLLMs were configured with temperatures of 0 for non-reasoning models and 1 for models using explicit reasoning modes. Custom GPU scheduling was developed for GPU4PySCF to prevent CUDA context initialization conflicts and illegal memory access patterns common in multi-threaded GPU4PySCF jobs. The concurrency levels were managed by a thread-safe token queue, defaulting to three execution slots per GPU to optimize device 5 https://neo4j.com/blog/agentic-ai/hands-on-with-context-graphs-and-neo4j/ 6 Analogous to agent teams collectively working on a codebase:https://w.anthropic.com/engineering/building-c-compiler 12 utilization while preventing memory exhaustion. Upon task submission, a dedicated scheduler assigns an available GPU identifier and execution slot, filtering visible devices through environment variables. Each workflow executes in a separate OS-level child process while sharing the same CUDA driver context. Inter- process communication is handled via pickled execution payloads. Integrated distributed tracing (via logfire) provides real-time observability into slot occupancy. The evaluation benchmark was developed usingpydantic-evals. The system assesses the agent’s performance by extracting structured workflow results from tool outputs and comparing them against the ground truth. The evaluation methodology employs a multi-dimensional scoring metric that verifies correctness across several chemical properties: (i) parameter integrity, to ensure that the selected functional, basis set, charge, and multiplicity match the intended calculation; (i) energetic accuracy, which validates total energies against reference values within a threshold of 0.01 Ha; (i) structural fidelity, quantified by the RMSD of atomic positions relative to reference geometries within a threshold of 0.15 Å, utilizingspyrmsdto account for symmetry and atom indexing permutations; and (iv) property analysis, which checks derived observables such as dipole moments, HOMO-LUMO gaps (threshold of 0.1 Ha), point group symmetry, and vibrational frequencies (ensuring no imaginary modes for stable minima). Scores are aggregated and normalized across these dimensions to yield a composite accuracy metric for each test case, with distributed tracing (via logfire) used to monitor agent reasoning and tool-invocation patterns during execution. Token counts and cost information were taken from thelogfirerecords. For evaluations performed prior to the release of pydantic-evals==v1.23.0(2025-11-25), token counts recorded bylogfirewere corrected to account for a double-counting bug (https://github.com/pydantic/pydantic-ai/issues/3529), which was resolved in the v1.23.0 release. 5.2 Computational tools The project employeduvfor a virtual environment using Python 3.12.12. All computational packages were installed in the same environment to enable single-agent operation using a shared Python runtime. To resolve dependency conflicts and enable custom functions, some packages were forked from their original repositories. Specific modifications are noted for each package. Where feasible and once the interfaces stabilize, we intend to upstream generalizable improvements to the original repositories via pull requests. 1. pydantic and numpydantic: The customized object graph mapper is implemented usingpydantic(v2.11.7) for basic typed classes and numpydantic (v1.6.11) for serialisation of NumPy arrays. 2.pydantic-ai family: The agentic framework and workflow execution are implemented usingpydantic-ai (v1.44.0), which provides type-safe agent definitions, tool registration, and validated data exchange. Structured workflow graphs are managed via thepydantic-graphcomponent, with customized base node classes for dynamic routing over typed node definitions. The framework was iteratively updated during development to incorporate new features and was stabilized at version v1.44.0. Execution traces, tool invocations, and structured state transitions were instrumented usinglogfire(accessed viapydantic- ai ) to enable fine-grained observability, debugging, and post-hoc analysis of agent behaviour. For lightweight external information retrieval, the agent utilised the DuckDuckGo search tool viapydantic_- ai.common_tools.duckduckgo, allowing web search without direct dependency on proprietary search APIs or internal web search tools that are only available for proprietary LLM models. 3.PySCF family: Density functional theory calculations were performed using thepyscf(v2.10.0), with gpu4pyscf-cuda12x(v1.5.0) for GPU acceleration on CUDA 12.x hardware andpyscf-dispersion(v1.3.0) for semiclassical dispersion corrections (78; 79; 80; 42; 81). 4. PubChemPy: The molecular generation from names or SMILES was implemented usingpubchempy (v1.0.4) (82; 83). 5. RDKit: The molecular generation from SMILES was implemented using rdkit (v2025.3.5) (84). 6. OpenBabel: In cases where RDKit failed,openbabel-wheel(v3.1.1.22) (a prebuilt wheel through PyPI) was used (85; 86). 7. QCElemental: Elemental data, physical constants, and unit conversions were standardized usingqcele- mental (v0.29.0), ensuring consistent representation of molecular quantities across electronic-structure 13 calculations and workflow components. 8.QCG and CREST: The conformer and rotamer ensemble sampling tool CREST generates ranked en- sembles of low-energy conformers for a given three-dimensional molecular structure (36;37). Using iterative metadynamics simulations (87) in combination with conventional molecular dynamics, CREST systematically samples the potential energy surface and explores the accessible conformational space. In this work, we implemented its GPU-accelerated variant described in Ref. (25) (commit 75135d). For the generation of explicitly solvated molecular structures, we use the Quantum Cluster Growth (QCG) algorithm (46) implemented in crest-3.0.2 together with xtb-6.7.1. 9. PORMAKE: PORMAKE (56) enables topology-aware assembly of hypotheticalMOFs from predefined building blocks (metal nodes and organic linkers). Building blocks are assigned to topology connection sites using RMSD-based matching of local coordination environments (RMSD≤0.3 Å). PORMAKE’s experimental decomposition routines are used to extract provisional building blocks from existing CIF files. We use a GitHub snapshot of PORMAKE pinned to commit639caad(https://github.com/San gwon91/PORMAKE), ensuring reproducible behaviour. 10.CoRE-MOF-Tools: CoRE-MOF-Tools (package:coremof-tools, v0.3.1) (52) is used for preprocessing experimental CIF files, including solvent removal and structural normalization, and for interfacing with Zeo++ to compute porosity-related descriptors. We use a fork of CoRE-MOF-Tools (https: //github.com/jb2197/CoRE-MOF-Tools) in which modifications are confined tosetup.pyto resolve dependency incompatibilities with the broader software environment. Specifically, strict version pins are relaxed to compatible lower bound constraints (e.g.,scikit-learn==1.3.2toscikit-learn>=1.3.2). The fork also redirects theMOFClassifier(88) dependency to a compatible fork (https://github.c om/jb2197/MOFClassifier), where analogous changes are applied insetup.py: strict version pins for numpy,torch,pymatgen,scikit-learn,tqdm, andpandasare relaxed to lower-bounded constraints, therequestspackage is added toinstall_requires, and an unusedrequestsimport is removed from the setup script. 11.MOFid: MOFid (upstream v1.1.0; forked and released as v1.1.1 with mofid-v2 utilities) provides the convert_ase_pymatfunction for ASE-to-pymatgen conversion, used during building block deduplication. This conversion enables structural comparison via pymatgen’sStructureMatcher, as part of a second- stage verification when PORMAKE’s experimental hash-based decomposition yields multiple candidate metal nodes or organic linkers. We use a fork of MOFid (https://github.com/swanickt/mofid) that corrects the upstream package distribution to make the mofid-v2 analysis code programmatically accessible. Specifically, the fork updatessetup.pyto include themofid_v2modules in the installable package set, adds missing__init__.pyfiles, refactors the node-grouping logic into an importable library module (group_node_by_structure_library.py), and updates dependency declarations to support reliable installation in Python environments. These changes remove script-style side effects present in the upstream implementation and enable direct programmatic use within Python workflows. 12.pymatgen: pymatgen (v2024.8.9) (89) provides structure-level equivalence checking throughout the workflow. For building block deduplication,StructureMatchercompares candidate structures converted from ASE via MOFid’sconvert_ase_pymatutility. For general structure validation and matching in theConceptualAtomsdata model, pymatgen’s nativeAseAtomsAdaptorperforms ASE-to-pymatgen conversion, withStructureMatcherused for periodic structures andMoleculeMatcherfor non-periodic molecules. Together, these capabilities support deduplication,KGqueries for equivalent components, and structure validation. 13.CrystalNets.jl: CrystalNets.jl (v1.1.0) (90), accessed viajuliacall(v0.9.29), is used for topological classification of MOF structures. The package determines the underlying net topology, dimensionality, and catenation from input CIF files. We employ theSingleNodesclustering mode, in which each identified building block is mapped to a single vertex. 14. Zeo++: Zeo++ (v0.3) (61) is used for porosity analysis, including largest cavity diameter (LCD), pore limiting diameter (PLD), largest free sphere path diameter (LFPD), accessible surface area, pore volume, and framework dimensionality. Zeo++ is accessed through the CoRE-MOF-Tools interface and is obtained from the zeo++/0.3 module directly loaded on the trillium-gpu HPC compute node. 14 15.MACE: MACE-torch (v0.3.14) (58) provides machine-learned interatomic potentials for geometry op- timization. We employ MACE-MP-MOF0 (mof-omat-0-v2) to perform structure relaxation prior to porosity analysis. We use a fork (https://github.com/jb2197/mace) that relaxes the strict depen- dency constrainte3n==0.4.4to an unpinned version (e3n), and further in our environment, we pin e3n==0.5.0 to ensure compatibility with other packages (MatterSim). 16.MatterSim: MatterSim (v1.2.0) (91) is supported as an alternative machine-learned force-field backend for geometry optimization within the workflow. 17.Orb models: The Orb models (v0.5.4) (92) provide an additional machine-learned interatomic potential option for geometry relaxation. 18. ASE: The Atomic Simulation Environment (v3.26.0) (93) serves as the common data structure for atomic configurations throughout the workflow. Building blocks from the PORMAKE decomposer, structures for MLIP optimization, and final MOF geometries are all represented as ASE Atoms objects. 19.RDFLib and SPARQLWrapper: RDFLib (v7.1.4) is used for RDF serialization and local graph operations, while SPARQLWrapper (v2.0.0) handles remote SPARQL queries against theKG. Together, they enable combinatorial search algorithms, equivalence queries for component deduplication, and persistence of workflow results. 20.Blazegraph: Blazegraph (engine v2.1.6) serves as the triplestore backend, hosting the persistentKG and exposing a SPARQL endpoint for queryingMOFcomponents, topologies, and compatibility relationships. TheKGis deployed using the Cambridge CARES Docker imageghcr.io/cambridge- cares/blazegraph:1.2.0 (container registry:https://github.com/orgs/cambridge-cares/packages/co ntainer/package/blazegraph), which provides a standardized containerized runtime consistent with the World Avatar KG infrastructure. 21. mcp-run-python: Sandboxed Python code executionmcp-run-pythonwas used as a model context protocol server, where a specific forked version (https://github.com/jb2197/mcp-run-python/releas es/tag/0.0.22.2-file) was used to enable output files. 22.PythonREPL: The Python code execution tool fromlangchain-experimental(v0.4.0) used for the “bare LLM” agent benchmark. This tool should be used with caution as it can execute arbitrary code on the host machine (e.g., delete files, make network requests). 5.3 Graphical user interface The Graphical User Interface (GUI) is implemented using the React framework. Communication between the frontend and backend is facilitated by theGraphChatSDK, a custom Python library that utilizes the WebSocket protocol for efficient data exchange. The key features of the chat interface include real-time streaming of agent responses, visibility into tool execution logs, and display of the agent’s reasoning steps, all implemented using the Pydantic AI framework and rendered viapycrdtfor synchronization and real-time updates. Furthermore, the interface dynamically renders a molecular viewer upon agent activation. When the agent generates molecules, the molecule viewer uses the corresponding conceptual atomIRIas a unique identifier. The molecule viewer supports both molecular and periodic systems, with interactive 3D rendering, optional atom selection, and the ability to send snapshots (captured images) to theLLM. The molecule viewer visualizes the molecular trajectory in real-time and allows users to download structures (and trajectories) in standard formats such as (extended)xyzand CIF. Additionally, plots generated by calls to the code execution tool are displayed directly in the chat interface for immediate interpretation. The frontend also supports dynamicLLMmodel switching, allowing users to experiment with different models on the fly without interrupting the ongoing session. Acknowledgments The authors thank Yiqun Bian for the helpful discussions in data analysis and Dr. Pit Steinbach for the helpful suggestions in setting up the GPU-accelerated implementation of CREST. J.B. acknowledges funding from the Eric and Wendy Schmidt AI in Science Postdoctoral Fellowship Program, a program by Schmidt 15 Futures. A.A. acknowledges support from King Abdullah University of Science and Technology (KAUST), Kingdom of Saudi Arabia, for the KAUST Ibn Rushd Postdoctoral Fellowship. Y.K. acknowledges support from the CIFAR AI Safety Catalyst Award (Catalyst Fund Project #CF26-AI-001). T.W.K. acknowledges the support of the Vector Distinguished Postdoctoral Fellowship. A.A.-G. thanks Anders G. Frøseth for his generous support. A.A.-G. also acknowledges the generous support of Natural Resources Canada and the Canada 150 Research Chairs program. This work was supported by the AI2050 program of Schmidt Sciences. This work was supported by the Defense Advanced Research Projects Agency (DARPA) under Agreement No. HR0011262E022.This research is part of the University of Toronto’s Acceleration Consortium, which receives funding from the CFREF-2022-00042 Canada First Research Excellence Fund. This research was enabled in part by support provided by SciNet HPC Consortium (https://scinethpc.ca/) and the Digital Research Alliance of Canada (https://w.alliancecan.ca). Computations were performed on the Trillium supercomputer at the SciNet HPC Consortium. SciNet is funded by: the Canada Foundation for Innovation; the Government of Ontario; Ontario Research Fund - Research Excellence; and the University of Toronto. References [1]Andres M. Bran, Sam Cox, Oliver Schilter, Carlo Baldassari, Andrew D. White, and Philippe Schwaller. Augment- ing Large Language Models with Chemistry Tools. Nat. Mach. Intell., 6(5):525–535, 2024. doi:10.1038/s42256- 024-00832-8. [2]Daniil A. Boiko, Robert MacKnight, Ben Kline, and Gabe Gomes. Autonomous Chemical Research with Large Language Models. Nature, 624(7992):570–578, 2023. doi:10.1038/s41586-023-06792-0. [3]Juraj Gottweis, Wei-Hung Weng, Alexander Daryin, Tao Tu, Anil Palepu, Petar Sirkovic, Artiom Myaskovsky, Felix Weissenberger, Keran Rong, Ryutaro Tanno, Khaled Saab, Dan Popovici, Jacob Blum, Fan Zhang, Katherine Chou, Avinatan Hassidim, Burak Gokturk, Amin Vahdat, Pushmeet Kohli, Yossi Matias, Andrew Carroll, Kavita Kulkarni, Nenad Tomasev, Yuan Guan, Vikram Dhillon, Eeshit Dhaval Vaishnav, Byron Lee, Tiago R D Costa, José R Penadés, Gary Peltz, Yunhan Xu, Annalisa Pawlosky, Alan Karthikesalingam, and Vivek Natarajan. Towards an AI Co-Scientist. arXiv Preprint, 2025. doi:10.48550/arxiv.2502.18864. [4]Ludovico Mitchener, Angela Yiu, Benjamin Chang, Mathieu Bourdenx, Tyler Nadolski, Arvis Sulovari, Eric C. Landsness, Daniel L. Barabasi, Siddharth Narayanan, Nicky Evans, Shriya Reddy, Martha Foiani, Aizad Kamal, Leah P. Shriver, Fang Cao, Asmamaw T. Wassie, Jon M. Laurent, Edwin Melville-Green, Mayk Caldas, Albert Bou, Kaleigh F. Roberts, Sladjana Zagorac, Timothy C. Orr, Miranda E. Orr, Kevin J. Zwezdaryk, Ali E. Ghareeb, Laurie McCoy, Bruna Gomes, Euan A. Ashley, Karen E. Duff, Tonio Buonassisi, Tom Rainforth, Randall J. Bateman, Michael Skarlinski, Samuel G. Rodriques, Michaela M. Hinks, and Andrew D. White. Kosmos: An AI Scientist for Autonomous Discovery. arXiv Preprint, 2025. doi:10.48550/arxiv.2511.02824. [5]Yunheng Zou, Austin H. Cheng, Abdulrahman Aldossary, Jiaru Bai, Shi Xuan Leong, Jorge Arturo Campos- Gonzalez-Angulo, Changhyeok Choi, Cher Tian Ser, Gary Tom, Andrew Wang, Zijian Zhang, Ilya Yakavets, Han Hao, Chris Crebolder, Varinia Bernales, and Alán Aspuru-Guzik. El Agente: An autonomous agent for quantum chemistry. Matter, 8(7):102263, 2025. doi:10.1016/j.matt.2025.102263. [6]Keyan Ding, Jing Yu, Junjie Huang, Yuchen Yang, Qiang Zhang, and Huajun Chen. SciToolAgent: A knowledge- graph-driven scientific agent for multitool integration. Nat. Comp. Sci., 5(10):962–972, 2025. doi:10.1038/s43588- 025-00849-y. [7]Yeonghun Kang and Jihan Kim. ChatMOF: An artificial intelligence system for predicting and generating metal- organic frameworks using large language models. Nat. Commun., 15(1), 2024. doi:10.1038/s41467-024-48998-4. [8] Shuxiang Cao, Zijian Zhang, Mohammed Alghadeer, Simone D Fasciati, Michele Piscitelli, Mustafa Bakr, Peter Leek, and Alán Aspuru-Guzik. Automating quantum computing laboratory experiments with an agent-based AI framework. Patterns, 6(10), 2025. doi:10.1016/j.patter.2025.101372. [9]Thang D. Pham, Aditya Tanikanti, and Murat Keçeli. ChemGraph as an agentic framework for computational chemistry workflows. Commun. Chem., 9(1), 2026. doi:10.1038/s42004-025-01776-9. [10] Ziqi Wang, Hongshuo Huang, Hancheng Zhao, Changwen Xu, Shang Zhu, Jan Janssen, and Venkatasubramanian Viswanathan. DREAMS: Density Functional Theory Based Research Engine for Agentic Materials Simulation. arXiv Preprint, 2025. doi:10.48550/arxiv.2507.14267. 16 [11]Theo Jaffrelot Inizan, Sherry Yang, Aaron Kaplan, Yen-hsu Lin, Jian Yin, Saber Mirzaei, Mona Abdelgaid, Ali H. Alawadhi, KwangHwan Cho, Zhiling Zheng, Ekin Dogus Cubuk, Christian Borgs, Jennifer T. Chayes, Kristin A. Persson, and Omar M. Yaghi. System of Agentic AI for the Discovery of Metal-Organic Frameworks. arXiv Preprint, 2025. doi:10.48550/arxiv.2504.14110. [12] Jinming Hu, Hassan Nawaz, Yuting Rui, Lijie Chi, Arif Ullah, and Pavlo O. Dral. Aitomia: Your intelligent assistant for ai-driven atomistic and quantum chemical simulations. arXiv Preprint, 2025. doi:10.48550/arxiv.2505.08195. [13]Carles Navarro, Mariona Torrens, Philipp Thölke, Stefan Doerr, and Gianni De Fabritiis. Speak to a Protein: An Interactive Multimodal Co-Scientist for Protein Analysis. arXiv Preprint, 2025. doi:10.48550/arxiv.2510.17826. [14] Ignacio Gustin, Luis Mantilla Calderón, Juan B. Pérez-Sánchez, Jérôme F. Gonthier, Yuma Nakamura, Karthik Panicker, Manav Ramprasad, Zijian Zhang, Yunheng Zou, Varinia Bernales, and Alán Aspuru-Guzik. El Agente Cuántico: Automating Quantum Simulations. arXiv Preprint, 2025. doi:10.48550/arxiv.2512.18847. [15]Juan B. Pérez-Sánchez, Yunheng Zou, Jorge A. Campos-Gonzalez-Angulo, Marcel Müller, Ignacio Gustin, Andrew Wang, Han Hao, Tsz Wai Ko, Changhyeok Choi, Eric S. Isbrandt, Mohammad Ghazi Vakili, Hanyong Xu, Chris Crebolder, Varinia Bernales, and Alán Aspuru-Guzik. El agente quntur: A research collaborator agent for quantum chemistry. arXiv Preprint, 2026. doi:10.48550/arxiv.2602.04850. [16]Changhyeok Choi, Yunheng Zou, Marcel Müller, Han Hao, Yeonghun Kang, Juan B. Pérez-Sánchez, Ignacio Gustin, Hanyong Xu, Mohammad Ghazi Vakili, Chris Crebolder, Alán Aspuru-Guzik, and Varinia Bernales. El Agente Estructural: An Artificially Intelligent Molecular Editor. arXiv Preprint, 2026. doi:10.48550/arxiv.2602.04849. [17]Sai Govind Hari Kumar, Yunheng Zou, Andrew Wang, Tsz Wai Ko, Jesus Valdez Hernandez, Nathan Yu, Varinia Bernales, and Alán Aspuru-Guzik. El Agente Solido: A New Agent for Solid State Simulations. 2026. [18]Jiaqi Wei, Yuejin Yang, Xiang Zhang, Yuhan Chen, Xiang Zhuang, Zhangyang Gao, Dongzhan Zhou, Guangshuai Wang, Zhiqiang Gao, Juntai Cao, Zijie Qiu, Ming Hu, Chenglong Ma, Shixiang Tang, Junjun He, Chunfeng Song, Xuming He, Qiang Zhang, Chenyu You, Shuangjia Zheng, Ning Ding, Wanli Ouyang, Nanqing Dong, Yu Cheng, Siqi Sun, Lei Bai, and Bowen Zhou. From AI for Science to Agentic Science: A Survey on Autonomous Scientific Discovery. arXiv Preprint, 2025. doi:10.48550/arxiv.2508.14111. [19] Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Bhavya Chopra, Rishabh Tiwari, Kurt Keutzer, Aditya Parameswaran, Dan Klein, Kannan Ramchandran, Matei Zaharia, Joseph E. Gonzalez, and Ion Stoica. Why Do Multi-Agent LLM Systems Fail? arXiv Preprint, 2025. doi:10.48550/arxiv.2503.13657. [20]Arpandeep Khatua, Hao Zhu, Peter Tran, Arya Prabhudesai, Frederic Sadrieh, Johann K. Lieberwirth, Xinkai Yu, Yicheng Fu, Michael J. Ryan, Jiaxin Pei, and Diyi Yang. CooperBench: Why Coding Agents Cannot be Your Teammates Yet. arXiv Preprint, 2026. doi:10.48550/arxiv.2601.13295. [21] Yubin Kim, Ken Gu, Chanwoo Park, Chunjong Park, Samuel Schmidgall, A. Ali Heydari, Yao Yan, Zhihan Zhang, Yuchen Zhuang, Mark Malhotra, Paul Pu Liang, Hae Won Park, Yuzhe Yang, Xuhai Xu, Yilun Du, Shwetak Patel, Tim Althoff, Daniel McDuff, and Xin Liu. Towards a Science of Scaling Agent Systems. arXiv Preprint, 2025. doi:10.48550/arxiv.2512.08296. [22] Ewa Deelman, Gurmeet Singh, Mei-Hui Su, James Blythe, Yolanda Gil, Carl Kesselman, Gaurang Mehta, Karan Vahi, G Bruce Berriman, John Good, Anastasia Laity, Joseph C. Jacob, and Daniel S. Katz. Pegasus: A Framework for Mapping Complex Scientific Workflows onto Distributed Systems. Sci. Program., 13(3):219–237, 2005. doi:10.1155/2005/128026. [23]Ryan Chard, Jim Pruyne, Kurt McKee, Josh Bryan, Brigitte Raumann, Rachana Ananthakrishnan, Kyle Chard, and Ian T. Foster. Globus Automation Services: Research Process Automation across the Space–Time Continuum. Future Gener. Comput. Syst., 142:393–409, 2023. doi:10.1016/j.future.2023.01.010. [24] Xiaojie Wu, Qiming Sun, Zhichen Pu, Tianze Zheng, Wenzhi Ma, Wen Yan, Yu Xia, Zhengxiao Wu, Mian Huo, Xiang Li, Weiluo Ren, Sheng Gong, Yumin Zhang, and Weihao Gao. Enhancing GPU-Acceleration in the Python- Based Simulations of Chemistry Frameworks. WIREs Comput. Mol. Sci., 15(2), 2025. doi:10.1002/wcms.70008. [25]Pit Steinbach and Christoph Bannwarth. Acceleration of Semiempirical Electronic Structure Theory Calculations on Consumer-Grade GPUs Using Mixed-Precision Density Matrix Purification. J. Chem. Theory Comput., 21(15): 7335–7351, 2025. doi:10.1021/acs.jctc.5c00262. [26] Mario Krenn, Florian Häse, AkshatKumar Nigam, Pascal Friederich, and Alan Aspuru-Guzik. Self-Referencing Embedded Strings (SELFIES): A 100% Robust Molecular String Representation. Mach. Learn.: Sci. Technol., 1 (4):045024, 2020. doi:10.1088/2632-2153/aba947. 17 [27]Stephen R Heller, Alan McNaught, Igor Pletnev, Stephen Stein, and Dmitrii Tchekhovskoi. InChI, the IUPAC International Chemical Identifier. J. Cheminf., 7:23, 2015. doi:10.1186/s13321-015-0068-4. [28]Matthew Muhoberac, Atharva Parikh, Nirvi Vakharia, Saniya Virani, Aco Radujevic, Savannah Wood, Meghav Verma, Dimitri Metaxotos, Jeyaraman Soundararajan, Thierry Masquelin, Alexander G. Godfrey, Sean Gardner, Dobrila Rudnicki, Sam Michael, and Gaurav Chopra. State and Memory is All You Need for Robust and Reliable AI Agents. arXiv Preprint, 2025. doi:10.48550/arxiv.2507.00081. [29]Jiaru Bai, Simon D. Rihm, Aleksandar Kondinski, Fabio Saluz, Xinhong Deng, George Brownbridge, Sebastian Mosbach, Jethro Akroyd, and Markus Kraft. twa: The world avatar python package for dynamic knowledge graphs and its application in reticular chemistry. Digital Discovery, 4(8):2123–2135, 2025. doi:10.1039/d5d00069f. [30]Engineering at Anthropic. Demystifying evals for AI agents, 2026.https://w.anthropic.com/engineering/de mystifying-evals-for-ai-agents. [31] Yuyang Wu, Yifei Wang, Ziyu Ye, Tianqi Du, Stefanie Jegelka, and Yisen Wang. When More is Less: Understanding Chain-of-Thought Length in LLMs. arXiv Preprint, 2025. doi:10.48550/arxiv.2502.07266. [32]Zheng Du, Hao Kang, Song Han, Tushar Krishna, and Ligeng Zhu. OckBench: Measuring the Efficiency of LLM Reasoning. arXiv Preprint, 2025. doi:10.48550/arxiv.2511.05722. [33]Artificial Analysis. Artificial Analysis Intelligence Index, 2026.https://artificialanalysis.ai/evaluations/artificia l-analysis-intelligence-index. [34]Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojciech Zaremba. Evaluating large language models trained on code. arXiv Preprint, 2021. doi:10.48550/arxiv.2107.03374. [35]Bernardo de Souza. GOAT: A Global Optimization Algorithm for Molecules and Atomic Clusters. Angew. Chem. Int. Ed., 64(18):e202500393, 2025. doi:10.1002/anie.202500393. [36]Philipp Pracht, Fabian Bohle, and Stefan Grimme. Automated Exploration of the Low-Energy Chemical Space with Fast Quantum Chemical Methods. Phys. Chem. Chem. Phys., 22(14):7169–7192, 2020. doi:10.1039/c9cp06869d. [37]Philipp Pracht, Stefan Grimme, Christoph Bannwarth, Fabian Bohle, Sebastian Ehlert, Gereon Feldmann, Johannes Gorges, Marcel Müller, Tim Neudecker, Christoph Plett, Sebastian Spicher, Pit Steinbach, Patryk A. Wesołowski, and Felix Zeller. CREST – A program for the exploration of low-energy molecular chemical space. J. Chem. Phys., 160(11):114110, 2024. doi:10.1063/5.0197592. [38] RDKit Contributors. RDKit: Open-source cheminformatics. Zenodo, 2026. 10.5281/zenodo.591637. [39] Christoph Bannwarth, Sebastian Ehlert, and Stefan Grimme. GFN2-xTB - An Accurate and Broadly Parametrized Self-Consistent Tight-Binding Quantum Chemical Method with Multipole Electrostatics and Density-Dependent Dispersion Contributions. J. Chem. Theory Comput., 15(3):1652–1671, 2019. doi:10.1021/acs.jctc.8b01176. [40]Sebastian Ehlert, Marcel Stahn, Sebastian Spicher, and Stefan Grimme. Robust and Efficient Implicit Solvation Model for Fast Semiempirical Methods. J. Chem. Theory Comput., 17(7):4250–4261, 2021. doi:10.1021/acs.jctc.1c00471. [41]Narbe Mardirossian and Martin Head-Gordon.ωb97X-V: A 10-parameter, range-separated hybrid, generalized gradient approximation density functional with nonlocal correlation, designed by a survival-of-the-fittest strategy. Phys. Chem. Chem. Phys., 16(21):9904–9924, 2014. doi:10.1039/c3cp54374a. [42] Eike Caldeweyher, Sebastian Ehlert, Andreas Hansen, Hagen Neugebauer, Sebastian Spicher, Christoph Bannwarth, and Stefan Grimme. A generally applicable atomic-charge dependent London dispersion correction. J. Chem. Phys., 150(15):154122, 2019. doi:10.1063/1.5090222. [43]Florian Weigend and Reinhart Ahlrichs. Balanced basis sets of split valence, triple zeta valence and quadruple zeta valence quality for H to Rn: Design and assessment of accuracy. Phys. Chem. Chem. Phys., 7(18):3297–3305, 2005. doi:10.1039/b508541a. 18 [44]Aleksandr V. Marenich, Christopher J. Cramer, and Donald G. Truhlar. Universal Solvation Model Based on Solute Electron Density and on a Continuum Model of the Solvent Defined by the Bulk Dielectric Constant and Atomic Surface Tensions. J. Phys. Chem. B, 113(18):6378–6396, 2009. doi:10.1021/jp810292n. [45]Ian T. Beck, Erica C. Mitchell, Annabelle Webb Hill, Justin M. Turney, Brandon Rotavera, and Henry F. I Schaefer. Evaluating the Importance of Conformers for Understanding the Vacuum-Ultraviolet Spectra of Oxiranes: Experiment and Theory. J. Phys. Chem. A, 128(50):10906–10920, 2024. doi:10.1021/acs.jpca.4c04391. [46]Sebastian Spicher, Christoph Plett, Philipp Pracht, Andreas Hansen, and Stefan Grimme. Automated molecular cluster growing for explicit solvation by efficient force field and tight binding methods. J. Chem. Theory Comput., 18(5):3174–3189, 2022. doi:10.1021/acs.jctc.2c00239. [47] Peter G. Boyd and Tom K. Woo. A generalized method for constructing hypothetical nanoporous materials of any net topology from graph theory. CrystEngComm, 18(21):3777–3792, 2016. doi:10.1039/c6ce00407e. [48]Aleksandar Kondinski, Angiras Menon, Daniel Nurkowski, Feroz Farazi, Sebastian Mosbach, Jethro Akroyd, and Markus Kraft. Automated Rational Design of Metal–Organic Polyhedra. J. Am. Chem. Soc., 144(26):11713–11728, 2022. doi:10.1021/jacs.2c03402. [49] Jiyeon Kim, Dongsik Nam, Hye Jin Cho, Eunchan Cho, Dharmalingam Sivanesan, Changhyeon Cho, Jaewoong Lee, Jihan Kim, and Wonyoung Choe. Up–down approach for expanding the chemical space of metal–organic frameworks. Nat. Synth., 3(12):1518–1528, 2024. doi:10.1038/s44160-024-00638-x. [50] Hao Lyu, Zhe Ji, Stefan Wuttke, and Omar M. Yaghi. Digital reticular chemistry. Chem, 6(9):2219–2241, 2020. doi:10.1016/j.chempr.2020.08.008. [51]Zhiling Zheng, Nakul Rampal, Theo Jaffrelot Inizan, Christian Borgs, Jennifer T. Chayes, and Omar M. Yaghi. Large language models for reticular chemistry. Nat. Rev. Mater., 10(5):369–381, 2025. doi:10.1038/s41578-025- 00772-8. [52]Guobin Zhao, Logan M. Brabson, Saumil Chheda, Ju Huang, Haewon Kim, Kunhuan Liu, Kenji Mochida, Thang D. Pham, Prerna, Gianmarco G. Terrones, Sunghyun Yoon, Lionel Zoubritzky, François-Xavier Coud- ert, Maciej Haranczyk, Heather J. Kulik, Seyed Mohamad Moosavi, David S. Sholl, J. Ilja Siepmann, Ran- dall.Q. Snurr, and Yongchul G. Chung. CoRE MOF DB: A curated experimental metal-organic framework database with machine-learned properties for integrated material-process screening. Matter, 8(6):102140, 2025. doi:10.1016/j.matt.2025.102140. [53]Marco Gibaldi, Anna Kapeliukha, Andrew White, Jun Luo, Robert Alex Mayo, Jake Burner, and Tom K. Woo. Mosaec-db: a comprehensive database of experimental metal–organic frameworks with verified chemical accuracy suitable for molecular simulations. Chem. Sci., 16(9):4085–4100, 2025. doi:10.1039/d4sc07438f. [54] Benjamin J. Bucior, Andrew S. Rosen, Maciej Haranczyk, Zhenpeng Yao, Michael E. Ziebel, Omar K. Farha, Joseph T. Hupp, J. Ilja Siepmann, Alán Aspuru-Guzik, and Randall Q. Snurr. Identification Schemes for Metal–Organic Frameworks To Enable Rapid Search and Cheminformatics Analysis. Cryst. Growth Des., 19(11): 6682–6697, 2019. doi:10.1021/acs.cgd.9b01050. [55] Zhenpeng Yao, Benjamín Sánchez-Lengeling, N. Scott Bobbitt, Benjamin J. Bucior, Sai Govind Hari Kumar, Sean P. Collins, Thomas Burns, Tom K. Woo, Omar K. Farha, Randall Q. Snurr, and Alán Aspuru-Guzik. Inverse design of nanoporous crystalline reticular materials with deep generative models. Nat. Mach. Intell., 3(1):76–86, 2021. doi:10.1038/s42256-020-00271-1. [56]Sangwon Lee, Baekjun Kim, Hyun Cho, Hooseung Lee, Sarah Yunmi Lee, Eun Seon Cho, and Jihan Kim. Computational Screening of Trillions of Metal–Organic Frameworks for High-Performance Methane Storage. ACS Appl. Mater. Interfaces, 13(20):23647–23654, 2021. doi:10.1021/acsami.1c02471. [57] Matthew A. Addicoat, Nina Vankova, Ismot Farjana Akter, and Thomas Heine. Extension of the Universal Force Field to Metal–Organic Frameworks. J. Chem. Theory Comput., 10(2):880–891, 2014. doi:10.1021/ct400952t. [58]Ilyes Batatia, David P Kovacs, Gregor Simm, Christoph Ortner, and Gábor Csányi. MACE: Higher order equivariant message passing neural networks for fast and accurate force fields. Adv. Neural Inf. Process. Syst., 35: 11423–11436, 2022. doi:10.48550/arxiv.2206.07697. [59] Hendrik Kraß, Ju Huang, and Seyed Mohamad Moosavi. MOFSimBench: evaluating universal machine learn- ing interatomic potentials in metal-organic framework molecular modeling. npj Comput. Mater., 12(1), 2025. doi:10.1038/s41524-025-01872-3. 19 [60]Peyman Z. Moghadam, Aurelia Li, Seth B. Wiggin, Andi Tao, Andrew G. P. Maloney, Peter A. Wood, Suzanna C. Ward, and David Fairen-Jimenez. Development of a cambridge structural database subset: A collection of metal–organic frameworks for past, present, and future. Chem. Mater., 29(7):2618–2625, 2017. doi:10.1021/acs.chemmater.7b00441. [61] Thomas F. Willems, Chris H. Rycroft, Michaeel Kazi, Juan C. Meza, and Maciej Haranczyk. Algorithms and tools for high-throughput geometry-based analysis of crystalline porous materials. Micropor. Mesopor. Mat., 149 (1):134–141, 2012. doi:10.1016/j.micromeso.2011.08.020. [62]Saffron Huang, Bryan Seethor, Esin Durmus, Kunal Handa, Miles McCain, Michael Stern, and Deep Ganguli. How AI Is Transforming Work at Anthropic, 2025.https://anthropic.com/research/how-ai-is-transforming-wor k-at-anthropic/. [63]Gary Tom, Stefan P. Schmid, Sterling G. Baird, Yang Cao, Kourosh Darvish, Han Hao, Stanley Lo, Sergio Pablo-García, Ella M. Rajaonson, Marta Skreta, Naruki Yoshikawa, Samantha Corapi, Gun Deniz Akkoc, Felix Strieth-Kalthoff, Martin Seifrid, and Alán Aspuru-Guzik. Self-Driving Laboratories for Chemistry and Materials Science. Chem. Rev., 124(16):9633–9732, 2024. doi:10.1021/acs.chemrev.4c00055. [64]Shi Xuan Leong, Caleb E Griesbach, Rui Zhang, Kourosh Darvish, Yuchi Zhao, Abhijoy Mandal, Yunheng Zou, Han Hao, Varinia Bernales, and Alán Aspuru-Guzik. Steering towards safe self-driving laboratories. Nat. Rev. Chem., 9(10):707–722, 2025. doi:10.1038/s41570-025-00747-x. [65]Felix Strieth-Kalthoff, Han Hao, Vandana Rathore, Joshua Derasp, Théophile Gaudin, Nicholas H. Angello, Martin Seifrid, Ekaterina Trushina, Mason Guy, Junliang Liu, Xun Tang, Masashi Mamada, Wesley Wang, Tuul Tsagaantsooj, Cyrille Lavigne, Robert Pollice, Tony C. Wu, Kazuhiro Hotta, Leticia Bodo, Shangyu Li, Mohammad Haddadnia, Agnieszka Wołos, Rafał Roszak, Cher Tian Ser, Carlota Bozal-Ginesta, Riley J. Hickman, Jenya Vestfrid, Andrés Aguilar-Granda, Elena L. Klimareva, Ralph C. Sigerson, Wenduan Hou, Daniel Gahler, Slawomir Lach, Adrian Warzybok, Oleg Borodin, Simon Rohrbach, Benjamin Sanchez-Lengeling, Chihaya Adachi, Bartosz A. Grzybowski, Leroy Cronin, Jason E. Hein, Martin D. Burke, and Alán Aspuru-Guzik. Delocalized, asynchronous, closed-loop discovery of organic laser emitters. Science, 384(6697), 2024. doi:10.1126/science.adk9227. [66]Jiaru Bai, Sebastian Mosbach, Connor J. Taylor, Dogancan Karan, Kok Foong Lee, Simon D. Rihm, Jethro Akroyd, Alexei A. Lapkin, and Markus Kraft. A Dynamic Knowledge Graph Approach to Distributed Self-Driving Laboratories. Nat. Commun., 15:462, 2024. doi:10.1038/s41467-023-44599-9. [67]Alexus A. Smith, Edmund L. Wong, Ronan C. Donovan, Brad A. Chapman, Ryan Harry, Pooyan Tirandazi, Paulina Kanigowska, Elizabeth A. Gendreau, Robert H. Dahl, Michal Jastrzebski, Jose E. Cortez, Christopher J. Bremner, José C. Morales Hemuda, James Dooner, Ian Graves, Rahul Karandikar, Christopher Lionetti, Kevin Christopher, Andrew L. Consiglio, Alyssa Tran, William McCusker, Duy X. Nguyen, Isis Botelho Nunes da Silva, Alvaro R. Bautista-Ayala, Monica P. McNerney, Sean Atkins, Michael McDuffie, Will Serber, Bradley P. Barber, Trinh Thanongsinh, Andrew Nesson, Bibek Lama, Brandon Nichols, Cameron LaFrance, Tenzing Nyima, Alicia Byrn, Rashard Thornhill, Bryan Cai, Lizvette Ayala-Valdez, Alycia Wong, Austin J. Che, Walter Thavarajah, Daniel Smith, Jr. Thomas F. Knight, David W. Borhani, Jerry Tworek, Mostafa Rohaninejad, Ahmed El-Kishky, Nathan C. Tedford, Tejal Patwardhan, Yunxin Joy Jiao, and Reshma P. Shetty. Using a gpt-5-driven autonomous lab to optimize the cost and titer of cell-free protein synthesis, 2026.https://cdn.openai.com/pdf/5a12a3bc-9 6b7-4e07-9386-db6e5b2ed9/using-a-gpt-5-driven-autonomous-lab-to-optimize-the-cost-and-titer-of-cell-fre e-protein-synthesis.pdf. [68]Human Layer. 12-Factor Agents - Principles for building reliable LLM applications, 2025.https://github.com/h umanlayer/12-factor-agents. [69] Vadim Borisov, Michael Gröger, Mina Mikhael, and Richard H. Schreiber. Do Chatbot LLMs Talk Too Much? The YapBench Benchmark. arXiv Preprint, 2026. doi:10.48550/arxiv.2601.00624. [70]Zijian Zhang, Aiwei Yin, Amaan Baweja, Jiaru Bai, Ignacio Gustin, Varinia Bernales, and Alán Aspuru-Guzik. El Agente Forjador: Task-driven Agent Generation for Quantum Simulation. Manuscript in preparation, 2026. [71] Xu Huang, Junwu Chen, Yuxing Fei, Zhuohan Li, Philippe Schwaller, and Gerbrand Ceder. Cascade: Cumulative agentic skill creation through autonomous development and evolution. arXiv Preprint, 2025. doi:10.48550/arxiv.2512.23880. [72]Alibaba Open Source. A universal sandbox platform for AI application scenarios, providing multi-language SDKs, unified sandbox protocols, and sandbox runtimes for LLM-related capabilities., 2025.https://github.com/aliba ba/OpenSandbox. 20 [73]Miles Wang, Joy Jiao, Neil Chowdhury, Ethan Chang, and Tejal Patwardhan. FrontierScience: Evaluating AI’s Ability to Perform Expert-Level Scientific Tasks, 2025.https://cdn.openai.com/pdf/2fcd284c-b468-4c21-8e0-7 a783933efcc/frontierscience-paper.pdf. [74]Zhangde Song, Jieyu Lu, Yuanqi Du, Botao Yu, Thomas M. Pruyn, Yue Huang, Kehan Guo, Xiuzhe Luo, Yuanhao Qu, Yi Qu, Yinkai Wang, Haorui Wang, Jeff Guo, Jingru Gan, Parshin Shojaee, Di Luo, Andres M Bran, Gen Li, Qiyuan Zhao, Shao-Xiong Lennon Luo, Yuxuan Zhang, Xiang Zou, Wanru Zhao, Yifan F. Zhang, Wucheng Zhang, Shunan Zheng, Saiyang Zhang, Sartaaj Takrim Khan, Mahyar Rajabi-Kochi, Samantha Paradi-Maropakis, Tony Baltoiu, Fengyu Xie, Tianyang Chen, Kexin Huang, Weiliang Luo, Meijing Fang, Xin Yang, Lixue Cheng, Jiajun He, Soha Hassoun, Xiangliang Zhang, Wei Wang, Chandan K. Reddy, Chao Zhang, Zhiling Zheng, Mengdi Wang, Le Cong, Carla P. Gomes, Chang-Yu Hsieh, Aditya Nandy, Philippe Schwaller, Heather J. Kulik, Haojun Jia, Huan Sun, Seyed Mohamad Moosavi, and Chenru Duan. Evaluating Large Language Models in Scientific Discovery. arXiv Preprint, 2025. doi:10.48550/arxiv.2512.15567. [75] Nenad Krdzavac, Sebastian Mosbach, Daniel Nurkowski, Philipp Buerger, Jethro Akroyd, Jacob Martin, Angiras Menon, and Markus Kraft. An Ontology and Semantic Web Service for Quantum Chemistry Calculations. J. Chem. Inf. Model., 59(7):3154–3165, 2019. doi:10.1021/acs.jcim.9b00227. [76]Laura Pascazio, Simon Rihm, Ali Naseri, Sebastian Mosbach, Jethro Akroyd, and Markus Kraft. Chemical Species Ontology for Data Integration and Knowledge Discovery. J. Chem. Inf. Model., 63(21):6569–6586, 2023. doi:10.1021/acs.jcim.3c00820. [77]Xiaochi Zhou, Patrick Bulter, Changxuan Yang, Simon D. Rihm, Thitikarn Angkanaporn, Jethro Akroyd, Sebastian Mosbach, and Markus Kraft. Ontology-to-tools compilation for executable semantic constraint enforcement in LLM agents. arXiv Preprint, 2026. doi:10.48550/arxiv.2602.03439. [78]Stefan Grimme, Jens Antony, Stephan Ehrlich, and Helge Krieg. A consistent and accurate ab initio parametrization of density functional dispersion correction (DFT-D) for the 94 elements H-Pu. J. Chem. Phys., 132(15):154104, 2010. doi:10.1063/1.3382344. [79]Stefan Grimme, Stephan Ehrlich, and Lars Goerigk. Effect of the damping function in dispersion corrected density functional theory. J. Comput. Chem., 32(7):1456–1465, 2011. doi:10.1002/jcc.21759. [80]Eike Caldeweyher, Christoph Bannwarth, and Stefan Grimme. Extension of the D3 dispersion coefficient model. J. Chem. Phys., 147(3):034112, 2017. doi:10.1063/1.4993215. [81]Lukas Wittmann, Igor Gordiy, Marvin Friede, Benjamin Helmich-Paris, Stefan Grimme, Andreas Hansen, and Markus Bursch. Extension of the D3 and D4 London dispersion corrections to the full actinides series. Phys. Chem. Chem. Phys., 26(32):21379–21394, 2024. doi:10.1039/D4CP01514B. [82] Sunghwan Kim, Paul A Thiessen, Evan E Bolton, Jie Chen, Gang Fu, Asta Gindulyte, Lianyi Han, Jane He, Siqian He, Benjamin A Shoemaker, Jiyao Wang, Bo Yu, Jian Zhang, and Stephen H Bryant. PubChem Substance and Compound Databases. Nucleic Acids Res., 44(D1):D1202–D1213, 2016. doi:10.1093/nar/gkv951. [83] Matthew Swain. PubChemPy, 2017. https://pubchempy.org. [84]Greg Landrum, Paolo Tosco, Brian Kelley, Ricardo Rodriguez, et al. rdkit/rdkit: 2025_03_1 (q1 2025) release, March 2025. https://doi.org. [85] Noel M O’Boyle, Michael Banck, Craig A James, Chris Morley, Tim Vandermeersch, and Geoffrey R Hutchison. Open Babel: An Open Chemical Toolbox. J. Cheminf., 3:33, 2011. doi:10.1186/1758-2946-3-33. [86] Jinzhe Zeng. openbabel-wheel, 2026. https://github.com/njzjz/openbabel-wheel. Accessed 9 Feb 2026. [87] Stefan Grimme. Exploration of Chemical Compound, Conformer, and Reaction Space with Meta-Dynamics Simulations Based on Tight-Binding Quantum Chemical Calculations. J. Chem. Theory Comput., 15(5):2847–2862, 2019. doi:10.1021/acs.jctc.9b00143. [88]Guobin Zhao, Pengyu Zhao, and Yongchul G. Chung. Mofclassifier: A machine learning approach for validating computation-ready metal–organic frameworks. J. Am. Chem. Soc., 147(37):33343–33349, 2025. doi:10.1021/jacs.5c10126. http://dx.doi.org/10.1021/jacs.5c10126. [89]Shyue Ping Ong, William Davidson Richards, Anubhav Jain, Geoffroy Hautier, Michael Kocher, Shreyas Cholia, Dan Gunter, Vincent L Chevrier, Kristin A Persson, and Gerbrand Ceder. Python Materials Genomics (pymat- gen): A Robust, Open-Source Python Library for Materials Analysis. Comput. Mater. Sci., 68:314–319, 2013. doi:10.1016/j.commatsci.2012.10.028. 21 [90]Lionel Zoubritzky and François-Xavier Coudert. CrystalNets.jl: Identification of Crystal Topologies. SciPost Chem., 1:005, 2022. doi:10.21468/SciPostChem.1.2.005. [91]Han Yang, Chenxi Hu, Yichi Zhou, Xixian Liu, Yu Shi, Jielan Li, Guanzhi Li, Zekun Chen, Shuizhou Chen, Claudio Zeni, et al. MatterSim: A Deep Learning Atomistic Model Across Elements, Temperatures and Pressures. arXiv Preprint, 2024. doi:10.48550/arxiv.2405.04967. [92]Benjamin Rhodes, Sander Vandenhaute, Vaidotas Šimkus, James Gin, Jonathan Godwin, Tim Duignan, and Mark Neumann. Orb-v3: atomistic simulation at scale. arXiv Preprint, 2025. doi:10.48550/arxiv.2504.06231. [93] Ask Hjorth Larsen, Jens Jørgen Mortensen, Jakob Blomqvist, Ivano E Castelli, Rune Christensen, Marcin Dułak, Jesper Friis, Michael N Groves, Bjørk Hammer, Cory Hargus, Eric D Hermes, Paul C Jennings, Peter Bjerre Jensen, James Kermode, John R Kitchin, Esben Leonhard Kolsbjerg, Joseph Kubal, Kristen Kaasbjerg, Steen Lysgaard, Jón Bergmann Maronsson, Tristan Maxson, Thomas Olsen, Lars Pastewka, Andrew Peterson, Carsten Rostgaard, Jakob Schiøtz, Ole Schüt, Mikkel Strange, Kristian S Thygesen, Tejs Vegge, Lasse Vilhelmsen, Michael Walter, Zhenhua Zeng, and Karsten W Jacobsen. The atomic simulation environment—a Python library for working with atoms. J. Phys. Condens. Matter., 29(27):273002, 2017. ISSN 1361-648X. doi:10.1088/1361-648x/a680e. [94]Stefan Grimme, Fabian Bohle, Andreas Hansen, Philipp Pracht, Sebastian Spicher, and Marcel Stahn. Efficient Quantum Chemical Calculation of Structure Ensembles and Free Energies for Nonrigid Molecules. J. Phys. Chem. A, 125(19):4039–4054, 2021. doi:10.1021/acs.jpca.1c00971. 22 Supporting Information Contents A List of tools24 B University-level quantum chemistry benchmark30 B.1 LLM model specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.2 User prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 B.3 Rubrics for LLM judge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 B.4 Pass k analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 B.5 Statistics plots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 B.6 Bare LLM agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 C Use case extension 1: Boltzmann-weighted spectroscopic properties48 C.1 Boltzmann-weighted spectroscopic properties in implicit solutions . . . . . . . . . . . . . . . . 49 C.2 Boltzmann-weighted spectroscopic properties with explicit solvation . . . . . . . . . . . . . . 50 D Use case extension 2: Exploration of metal-organic frameworks design space50 D.1 MOF execution graph node implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 D.2 Chat transcripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 23 A List of tools Tool NameTool description received by agent/LLMs run_mof_workflowRun the MOF workflow graph for building, optimizing, and/or analyzing MOFs. This workflow uses dynamic AI-based routing to chain together multiple stages based on the user’s intent. The workflow is NOT limited to a single operation— it can automatically proceed through multiple stages (e.g., download -> decom- pose -> build -> optimize -> analyze). WORKFLOW STAGES (can be combined automatically): • Download: Fetch CIF from CSD/CoRE-MOF database • Decompose: Extract topology and building blocks from CIF • Search: Query knowledge graph for compatible MOF combinations • Build: Construct MOF structure from components • Optimize: Geometry relaxation via MLFF (MACE-MOF, etc.) • Analyze: Zeo++ porosity analysis SAMPLE WORKFLOWS: Build directly from PORMAKE components Required: – topology_pormake_id (e.g., "pcu", "dia) – node_pormake_id (e.g., "N409", "N111") – linker_pormake_id (e.g., "E1", "E42") Optional: – mof_name Example user intents: – "Build a MOF with topology Z using metal node X and organic linker Y." – "Construct this specific MOF (I know the building blocks)." CSD/CoRE-MOF Refcode -> Download, then automatically routed based on user intent (summarised_user_query) Required: – csd_refcode Optional: – mof_name Example user intents: – "What is the topology of MOF ABAVIJ?" – "What is the surface area of this CSD structure?" – "Optimize the MOF with refcode ABAVIJ." Process a local CIF file Required: – input_cif_filename Optional: – mof_name Typical user intents: – "Here is a CIF. What’s its topology?" – "Optimize this MOF." – "Run Zeo++ analysis on this structure." Knowledge Graph Search -> Find compatible combinations, then optionally build Optional: – topology_iris: list of topology instance IRIs to restrict – metal_node_iris: list of metal-node instance IRIs to restrict – organic_linker_iris: list of linker instance IRIs to restrict Parameters schema 24 "additionalProperties":false,"properties":"summarised_user_query":"type":"string"," topology_pormake_id":"default":null,"anyOf":["type":"string","type":"null"]," node_pormake_id":"default":null,"anyOf":["type":"string","type":"null"]," linker_pormake_id":"default":null,"anyOf":["type":"string","type":"null"],"mof_name ":"default":null,"anyOf":["type":"string","type":"null"],"csd_refcode":"default":null," anyOf":["type":"string","type":"null"],"input_cif_filename":"default":null,"anyOf":[" type":"string","type":"null"],"topology_iris":"default":null,"anyOf":["items":"type":" string","type":"array","type":"null"],"metal_node_iris":"default":null,"anyOf":["items ":"type":"string","type":"array","type":"null"],"organic_linker_iris":"default":null," anyOf":["items":"type":"string","type":"array","type":"null"],"update_graph":" default":false,"type":"boolean","required":["summarised_user_query"],"type":"object" Tool NameTool description received by agent/LLMs duckduckgo_web_- search <summary>Searches DuckDuckGo for the given query and returns the re- sults.</summary> <returns> <description>The search results.</description> </returns> Parameters schema "additionalProperties":false,"properties":"query":"description":"The query to search for.","type ":"string","required":["query"],"type":"object" Tool NameTool description received by agent/LLMs get_conversion_fac- tor <summary>Convert physical quantities from a list of UnitConvPair each containing a numerical value along with source and target units, and the function returns a list of converted values.</summary> <returns> <type>list[float]</type> <description>Converted values in the target unit. str: Error message if conversion is not supported or input is invalid.</description> </returns> Parameters schema "additionalProperties":false,"properties":"UnitConversionPairs":"description":"List of UnitConvPair objects containing value, from_unit, and to_unit.","items":"$ref":"#/$defs/ UnitConvPair","type":"array","required":["UnitConversionPairs"],"type":"object","$defs ":"UnitConvPair":"properties":"value":"type":"number","from_unit":"enum":["hartree ","eV","kJ/mol","kcal/mol","cm^-1","Hz"],"type":"string","to_unit":"enum":["hartree","eV ","kJ/mol","kcal/mol","cm^-1","Hz"],"type":"string","required":["value","from_unit"," to_unit"],"type":"object","additionalProperties":false Tool NameTool description received by agent/LLMs capture_viewer_- screenshot <summary>Capture a screenshot of the current Molecule Viewer and provide it to the model.</summary> <returns> <description>List of str with BinaryCon- tent image included in the content so the LLM can analyze it.</description> </returns> Parameters schema 25 "additionalProperties":false,"properties":"molecule_id":"default":null,"description":"Optional molecule id to target; defaults to \"current\" if omitted.","anyOf":["type":"string","type":" null"],"type":"object" Tool NameTool description received by agent/LLMs run_crest_con- former_search <summary>Run a CREST conformer search for a given molecule identi- fier.</summary> <returns> <description>A JSON-serializable dictionary describing the CREST ensemble.</description> </returns> Parameters schema "additionalProperties":false,"properties":"identifier":"description":"The molecule identifier ( SMILES string, name, or XYZ file path).","type":"string","identifier_type":"description":" The type of the identifier ('smiles', 'name', or 'xyz').","enum":["smiles","name","xyz"],"type":" string","charge":"default":0,"description":"The molecular charge (default: 0).","type":" number","spin_multiplicity":"default":1,"description":"The spin multiplicity (default: 1)."," type":"integer","implicit_solvent":"default":null,"description":"The implicit solvent model to use (default: None), example: \"water\", \"acetonitrile\".","anyOf":["type":"string"," type":"null"],"calculation_level_method":"default":"gfn2","description":"The method to use for the CREST calculation (default: 'gfn2').","enum":["tblite","gfn2","gfn1","gfnff","gfn0 ","gfn0*","xtb","gfn","gfn-xtb","orca","generic"],"type":"string","crest_runtype":"default ":"imtd-gc","description":"CREST sampling mode ('imtd-gc' for standard sampling, 'nci' for non-covalent complexes and aggregates sampling which should be used for explicitly solvated structures).","enum":["imtd-gc","nci"],"type":"string","run_on_gpu":"default":false," description":"Whether to run the calculation on GPU (default: False).","type":"boolean"," required":["identifier","identifier_type"],"type":"object" Tool NameTool description received by agent/LLMs run_qcg_clusterRun a QCG grow calculation and return the merged cluster as XYZ. Parameters schema "additionalProperties":false,"properties":"solute_identifier":"description":"Solute identifier ( SMILES, name, or XYZ string).","type":"string","solvent_identifier":"description":"Solvent identifier (SMILES, name, or XYZ string).","type":"string","solute_identifier_type":" description":"Type of solute identifier.","enum":["smiles","name","xyz"],"type":"string"," solvent_identifier_type":"description":"Type of solvent identifier.","enum":["smiles","name ","xyz"],"type":"string","charge":"default":0,"description":"Total molecular charge.","type ":"number","spin_multiplicity":"default":1,"description":"Spin multiplicity (e.g., 1 for singlet, 2 for doublet).","minimum":1,"type":"integer","nsolv":"default":15,"description":" Number of solvent molecules to add.","exclusiveMinimum":0,"type":"integer","threads":" default":12,"description":"Threads passed to CREST via --T.","exclusiveMinimum":0,"type":" integer","alpb_solvent":"default":"water","description":"ALPB solvent name (case- insensitive). Available: acetone, acetonitrile, aniline, benzaldehyde, benzene, ch2cl2, chcl3, cs2, dioxane, dmf, dmso, ethanol, ether, ethylacetate, furane, hexadecane, hexane, methanol, nitromethane, octanol, octanol (wet), phenol, toluene, thf, water","anyOf":["type":"string ","type":"null"],"required":["solute_identifier","solvent_identifier"," solute_identifier_type","solvent_identifier_type"],"type":"object" 26 Tool NameTool description received by agent/LLMs show_molecule_in_- viewer <summary>Instruct the Molecule Viewer to display a ConceptualAtoms by its IRI.</summary> <returns> <description>A confirmation message indicating the viewer has been updated.</description> </returns> Parameters schema "additionalProperties":false,"properties":"conceptual_atoms_iri":"description":"The IRI of the ConceptualAtoms instance to display.","type":"string","required":["conceptual_atoms_iri "],"type":"object" Tool NameTool description received by agent/LLMs run_pyscf_workflow<summary>Run PySCF calculations using the workflow graph with dynamic routing capabilities.</summary> <returns> <type>list[PyscfOutput]</type> <description>PySCF calculation outputs gathered from the workflow run.</description> </returns> Parameters schema "additionalProperties":false,"properties":"summerised_user_query":"description":"Description of the calculations the user wants to run, this will be used by the workflow routing agent to determine which next nodes to execute.","type":"string","identifier_type":"description":" Kind of identifier supplied to describe the molecule.","enum":["name","smiles","xyz"," xyz_filename","conceptual_atoms_iri"],"type":"string","identifier":"description":"Identifier content (name, SMILES, or XYZ string) describing the conceptual atom; for XYZ, provide the literal file text such as ``3\ \ 0.000 0.000 0.000\ 0.000 0.757 0.586\ 0.000 -0.757 0.586``.","type":"string","charge":"default":0,"description":"Overall molecular charge; defaults to 0.","type":"integer","spin_multiplicity":"default":1,"description":"Spin multiplicity of the molecule; defaults to 1.","type":"integer","basis_set":"default":null," description":"Basis set name for the calculation; falls back to workflow defaults when omitted .","anyOf":["type":"string","type":"null"],"restricted":"default":true,"description":" Whether to use a restricted reference (RHF/ROHF/RDFT) instead of unrestricted; defaults to True.","type":"boolean","xc_functional":"default":null,"description":"Exchange-correlation functional to activate DFT; when omitted, the workflow uses Hartree-Fock.","anyOf":["type":" string","type":"null"],"solvation_model":"default":null,"description":"Implicit solvation model label; uses vacuum when not provided.","anyOf":["enum":["CPCM","COSMO","IEF- PCM","S(V)PE","SMD"],"type":"string","type":"null"],"implicit_solvent":"default": null,"description":"Solvent environment name for the chosen solvation model; defaults to water when paired with an implicit model.","anyOf":["enum":["Water","Dimethylsulfoxide"," Nitromethane","Acetonitrile","Methanol","Ethanol","Acetone","Methylenechloride"," Tetrahydrofurane","Aniline","Chlorobenzene","Chloroform","Toluene","Benzene"," Cyclohexane","N-heptane"],"type":"string","type":"null"],"exit_node":"default":null," description":"Identifier of a workflow node to terminate at, enabling partial runs.","anyOf":[" type":"string","type":"null"],"required":["summerised_user_query","identifier_type"," identifier"],"type":"object" 27 Tool NameTool description received by agent/LLMs run_sparql_query<summary>Execute a read-only SPARQL query against the knowledge graph. Supports SELECT, CONSTRUCT, ASK, and DESCRIBE queries. UPDATE operations are rejected. Queries are subject to: 45 second timeout Complexity limits (max 50 triple patterns, OPTIONAL depth 5, UNION branches 10) Injection pattern detection and basic syntax validation</summary> <returns> <description>Query results as a string. Results are truncated if too large.</description> </returns> Parameters schema "additionalProperties":false,"properties":"sparql":"description":"The SPARQL query string. Must be a valid read-only query.","type":"string","required":["sparql"],"type":"object" Tool NameTool description received by agent/LLMs get_ontology_snap- shot <summary>Retrieve complete schema snapshot for an ontology. Returns all classes with their data properties and object properties in a single call, giving context for reasoning about the knowledge graph structure.</summary> <returns> <description> "ontology_iri": str, "ontology_description": str, "class_count": int, "classes": class_iri: "py_class": "module.ClassName", "description": "Class docstring summary", "data_properties": property_- iri: "field": "field_name", "type": "python.type.Path", "description": "Field description" , "object_properties": ... </description> </returns> Parameters schema "additionalProperties":false,"properties":"ontology_iri":"description":"The IRI of the ontology to inspect. : \"https://elagente.ca/ontomof\"","type":"string","class_iris":"default ":null,"description":"Optional filter - only return these specific classes. None, returns all classes in the ontology.","anyOf":["items":"type":"string","type":"array","type":"null "],"required":["ontology_iri"],"type":"object" Tool NameTool description received by agent/LLMs get_instance_from_- knowledge_graph <summary>Retrieve a knowledge graph object by its IRI. Large data fields (NDArrays, CIF text, etc.) are stripped and replaced with metadata. Use get_- cif_content to retrieve full CIF text.</summary> <returns> <description> "instance_iri": str, "class_type": "ClassName", "data": ... fields with large data stripped ... , "large_fields_available": ["cif_text", "positions", ...] </description> </returns> Parameters schema "additionalProperties":false,"properties":"instance_iri":"description":"The IRI of the object to retrieve. : \"https://elagente.ca/ontomof/ConstructedMOF_abc123\"","type":" string","recursive_depth":"default":3,"description":"How deep to recursively pull related objects. is 3 (direct properties and some related context). Increase for more context. For pulling ConceptualAtoms or related structures, use -1.","type":"integer","required":[" instance_iri"],"type":"object" 28 Tool NameTool description received by agent/LLMs get_cif_content<summary>Retrieve the CIF content for a ConstructedMOF. CIF (Crystallo- graphic Information File) contains the full atomic structure for visualization or analysis.</summary> <returns> <description> "mof_iri": str, "mof_name": str or None, "cif_text": "full CIF content...", "n_atoms": int </description> </returns> Parameters schema "additionalProperties":false,"properties":"mof_iri":"description":"The IRI of the ConstructedMOF instance.","type":"string","required":["mof_iri"],"type":"object" Tool NameTool description received by agent/LLMs run_python_code(ex- posed via MCP server) Tool to execute Python code and return stdout, stderr, and return value. Guidelines The code may be async, and the value on the last line will be returned as the return value. The code will be executed with Python 3.13 using pyodide - so adapt your code if needed. You code must be executed within a timeout. You have 60 seconds before the run is canceled. You have these python packages installed: numpy,pandas,matplotlib To output files or images, save them in the "/output_files" folder. Parameters schema "type": "object", "properties": "python_code": "type": "string", "description": "Python code to run", "global_variables": "type": "object", "additionalProperties": , "default": , " description": "Map of global variables in context when the code is executed", "properties": , "required": ["python_code"], "additionalProperties": false 29 B University-level quantum chemistry benchmark B.1 LLM model specifications Table S1 Pricing (per million tokens) and maximum context window size for benchmarkedLLMs. Data were sourced from official provider websites for proprietary models and OpenRouter for open models. Pricing for cached tokens was not considered since cashing policies vary across providers. LLM modelInput tokens ($/M) Output tokens ($/M) Maximum context window gpt-4.1281,047,576 gpt-51.2510400,000 gpt-5.11.2510400,000 gpt-5.21.7514400,000 minimax-m20.21205,000 qwen3-max1.26262,144 claude-sonnet-3.7315200,000 claude-sonnet-4.5315200,000 "gpt-4.1-2025-04-14": "temperature": 0.0, "provider_name": "openai", "provider_url": "https:// api.openai.com/v1/" "gpt-5-2025-08-07": "temperature": 1.0, "openai_reasoning_effort": "low", "provider_name": " openai", "provider_url": "https://api.openai.com/v1/" "gpt-5.1-2025-11-13": "temperature": 1.0, "openai_reasoning_effort": "low", "provider_name": " openai", "provider_url": "https://api.openai.com/v1/" "gpt-5.2-2025-12-11": "temperature": 1.0, "openai_reasoning_effort": "low", "provider_name": " openai", "provider_url": "https://api.openai.com/v1/" "openrouter:minimax/minimax-m2": "temperature": 1.0, "provider_name": "openrouter", " provider_url": "https://openrouter.ai/api/v1" "openrouter:qwen/qwen3-max": "temperature": 0.0, "provider_name": "openrouter", " provider_url": "https://openrouter.ai/api/v1" "claude-3-7-sonnet-20250219": "temperature": 1.0, "anthropic_thinking": "type": "enabled", " budget_tokens": 1024, "extra_headers": "anthropic-beta": "token-efficient-tools-2025-02-19", "provider_name": "anthropic", "provider_url": "https://api.anthropic.com" "claude-sonnet-4-5-20250929": "temperature": 0.0, "kind": "response", "provider_name": " anthropic", "provider_url": "https://api.anthropic.com" 30 B.2 User prompts Prompts were minimally revised to remove ORCA-specific data and ensure an unbiased comparison with the original El Agente (5) benchmark questions; no additional instructions were given. Functionals and basis sets were adjusted specifically for PySCF compatibility. PromptOrganic compounds level 1 Perform in parallel geometry optimization of the [compounds below] with the Hartree-Fock (HF) method and def2-SVP basis set in the gas phase. Once the calculations have been successfully completed, please generate individual reports for each of the molecules listed below, one at a time. Each report should include the final Cartesian coordinates (in Å), total energy (in Hartrees), point group symmetry, dipole moment (in Debye), molecular orbital analysis (including an MO energy table and the HOMO-LUMO gap), atomic charge analysis (Mulliken, Löwdin, and IAO). Organic Compounds: 1. caffeine (SMILES: CN1C=NC2=C1C(=O)N(C(=O)N2C)C) 2. theobromine (SMILES: CN1C=NC2=C1C(=O)NC(=O)N2C) 3. acetylsalicylic_acid (SMILES: C(=O)OC1=C=C=C1C(=O)O) PromptOrganic compounds level 2 Perform in parallel geometry optimization using the xyz files listed below from the default working directory with the Hartree-Fock (HF) method and def2-SVP basis set in the gas phase. Once the calculations have been successfully completed, please generate individual reports for each of the molecules listed below, one at a time. Each report should include the final Cartesian coordinates (in Å), total energy (in Hartrees), point group symmetry, dipole moment (in Debye), molecular orbital analysis (including an MO energy table and the HOMO-LUMO gap), atomic charge analysis (Mulliken, Löwdin, and Hirshfeld). Organic Compounds: 1. caffeine_openbabel.xyz (charge = 0; multiplicity = 1) 2. theobromine_openbabel.xyz (charge = 0; multiplicity = 1) 3. aspirin_openbabel.xyz (charge = 0; multiplicity = 1) 4. methyl_salicylate_openbabel.xyz (charge = 0; multiplicity = 1) 5. acetaminophen_openbabel.xyz (charge = 0; multiplicity = 1) 6. triazaadamantane_openbabel.xyz (charge = 0; multiplicity = 1) 7. limonene_openbabel.xyz (charge = 0; multiplicity = 1) 8. D-glucose_openbabel.xyz (charge = 0; multiplicity = 1) 9. creatinine_amine_tautomer_openbabel.xyz (charge = 0; multiplicity = 1) 10. creatinine_imine_tautomer_openbabel.xyz (charge = 0; multiplicity = 1) 11. L-phenylalanine_zwitterion_openbabel.xyz (charge = 0; multiplicity = 1) 12. 2-chloronitrobenzene_openbabel.xyz (charge = 0; multiplicity = 1) 13. cis-1_2-cyclohexanediol_openbabel.xyz (charge = 0; multiplicity = 1) 14. L-histidine_non_zwitterion_openbabel.xyz (charge = 0; multiplicity = 1) 15. 2_2-biphenol_openbabel.xyz (charge = 0; multiplicity = 1) 16. S-2-ethyl-2-fluoropentan-1-ol_openbabel.xyz (charge = 0; multiplicity = 1) 17. R-3-hydroxycyclopentan-1-one_openbabel.xyz (charge = 0; multiplicity = 1) 18. 3-methylbutanoate_anion_openbabel.xyz (charge = -1; multiplicity = 1) 19. diisopropylamide_anion_openbabel.xyz (charge = -1; multiplicity = 1) 20. diisopropylammonium_cation_openbabel.xyz (charge = +1; multiplicity = 1) PromptInorganic compounds level 1 Plan and act directly. Do not ask for my confirmation this time. Complete the following request: Perform in parallel geometry optimization of the [compounds below] with the Hartree-Fock (HF) method and def2-SVP basis set in the gas phase. Once the calculations have been successfully completed, please generate individual reports for each of the molecules listed below, one at a time. Each report should include the final Cartesian coordinates (in Å), total energy (in Hartrees), point group symmetry, dipole moment (in Debye), molecular orbital analysis (including an MO energy table and the HOMO-LUMO gap), atomic charge analysis (Mulliken, Löwdin, and IAO). Inorganic Compounds: 1. Chromium(0) hexacarbonyl (low spin) – SMILES: [Cr](=C=O)(=C=O)(=C=O)(=C=O)(=C=O)(=C=O) 2. Chlorine trifluoride – SMILES: FCl(F)F 3. Fluorophosphoric acid (singly deprotonated form) – SMILES: [O-]P(F)(O)=O 31 PromptInorganic compounds level 2 Plan and act directly. Do not ask my confirmation this time. Complete the following request: Perform in parallel geometry optimization using the xyz files listed below with the Hartree-Fock (HF) method and def2-SVP basis set in the gas phase. Once the calculations have been successfully completed, please generate individual reports for each of the molecules listed below, one at a time. Each report should include the final Cartesian coordinates (in Å), total energy (in Hartrees), point group symmetry, dipole moment (in Debye), molecular orbital analysis (including an MO energy table and the HOMO-LUMO gap), atomic charge analysis (Mulliken, Löwdin, and Hirshfeld). List of Inorganic Compounds: 1. chromium_hexacarbonyl.xyz (charge = 0; multiplicity = 1) 2. chlorine_trifluoride.xyz (charge = 0; multiplicity = 1) 3. fluorophosphoric_acid_singly_deprotonated_form.xyz (charge = -1; multiplicity = 1) 4. trifluoromethane_sulfonate.xyz (charge = -1; multiplicity = 1) 5. cyclohexyldimethylphosphine.xyz (charge = 0; multiplicity = 1) 6. t-butylisothiocyanate.xyz (charge = 0; multiplicity = 1) 7. chromic_acid.xyz (charge = 0; multiplicity = 1) 8. permanganic_acid.xyz (charge = 0; multiplicity = 1) 9. perchlorate.xyz (charge = -1; multiplicity = 1) 10. hexafluorophosphate.xyz (charge = -1; multiplicity = 1) 11. tetrafluoroborate.xyz (charge = -1; multiplicity = 1) 12. dicyanoaurate.xyz (charge = -1; multiplicity = 1) 13. nitrogen_trifluoride.xyz (charge = 0; multiplicity = 1) 14. sulfur_hexafluoride.xyz (charge = 0; multiplicity = 1) 15. sulfur_tetrafluoride.xyz (charge = 0; multiplicity = 1) 16. xenon_tetrafluoride.xyz (charge = 0; multiplicity = 1) PromptCarbocations compounds level 1 A carbocation formation reaction is given by R-H -> R+ + H-. Your task is to calculate the carbocation formation enthalpies and Gibbs free energies for R-H = methane, ethane, propane, 2-methylpropane, toluene, benzene, dimethyl ether, trimethylamine, and propene. In your working directory, you can find: carbo_ch4.xyz, carbo_C2H6.xyz, carbo_C3H8.xyz, carbo_2-methylpropane.xyz, carbo_toluene.xyz, carbo_benzene.xyz, carbo_et2o.xyz, carbo_et3n.xyz, carbo_propene.xyz, and carbo_h-.xyz. You will also find carbo_ch3+.xyz, carbo_C2H5+.xyz, carbo_C3H7+.xyz, carbo_2-methylpropyl+.xyz, carbo_toluene+.xyz, carbo_benzene+.xyz, carbo_et2o+.xyz, carbo_et3n+.xyz, and carbo_propene+.xyz for the cations. Please optimize these structures (except the hydride) using DFT with the B3LYP functional and def2-SVP basis set, and from the outputs, extract the relevant information to calculate the carbocation formation enthalpies and Gibbs free energies of each R-H. Report the results (in kcal/mol) in a table. For charge and multiplicity, for molecules charge 0, multiplicity 1; carbocations charge 1, multiplicity 1; hydride charge -1, multiplicity 1. PromptCarbocations compounds level 2 A carbocation formation reaction is given by R-H -> R+ + H-. Your task is to calculate the carbocation formation enthalpies and Gibbs free energies for R-H = methane, ethane, propane, 2-methylpropane, toluene, benzene, dimethyl ether, trimethylamine, and propene. The SMILES of each R-H are as follows: C, C, C, C(C)C, Cc1c1, c1c1, COC, CN(C)C, C=C. The SMILES of each R+ is given by [CH3+], [CH2+]C, C[CH+]C, C[C+](C)C, [CH2+]c1c(c1), c1[c+]c1, CO[CH2+], CN(C)[CH2+], [CH2+]C=C. Please use the SMILES strings in the table to generate the appropriate geometries, optimize them using DFT with the B3LYP functional and def2-SVP basis set, and from the outputs, extract the relevant information to calculate the carbocation formation enthalpies and Gibbs free energies of each R-H. Report the results (in kcal/mol) in a table. PromptRing Strain compounds level 1 Compute the values of∆H and∆G for the following reactions: cyclo(CnH2n)→ cyclo(Cn-1H2n-3)-CH3 Perform these calculations using B3LYP/def2-svp for values of n from 4 to 8 and use them to approximate the relative ring strain energies of cycloalkanes of size 3 to 8. Hint: The first reaction (n = 4) is cyclobutane (SMILES string C1C1) converting into methylcyclopropane (SMILES string C1C1). Each structure needs to be optimized and frequencies must be calculated to get the enthalpy and Gibbs free energies. You will need to pick a reference point to use as the “zero ring strain” point and compare the others relative to that. Report a table of ring size vs. ring strain enthalpy and free energy. To calculate the ring strain energy, start by assuming cyclooctane (n = 8) is the reference point, and that its ring strain is zero. Then, the ring strain of cycloheptane (n = 7) is determined by the enthalpy or Gibbs free energy of the reaction cyclooctane→ methylcycloheptane (n = 8 to n = 7), and the ring strain energy of cyclooctane (n = 8). Obtain this for n = 8 to n = 3. Finally, use cyclohexane (n = 6) as the reference point of zero ring strain. 32 PromptRing Strain compounds level 2 Compute the values of∆H and∆G for the following reactions: cyclo(CnH2n)→ cyclo(Cn-1H2n-3)-CH3 Perform these calculations using B3LYP/def2-svp for values of n from 4 to 8 and use them to approximate the relative ring strain energies of cycloalkanes of size 3 to 8. Hint: You will need to pick a reference point to use as the “zero ring strain” point and compare the others relative to that. Report a table of ring size vs. ring strain enthalpy and free energy. The ring strain of cyclo(CnH2n) is determined by the reaction energy of cyclo(CnH2n)→ cyclo(Cn-1H2n-3)-CH3 and the ring strain energy of cyclo(CnH2n). PromptpKa Prediction compounds level 1 Plan and act directly. Do not ask for my confirmation this time. Complete the following request: Calculate the pKa of acetic acid in water using two calculations at the B3LYP/def2-SVP level of theory with the CPCM implicit solvation model. PromptpKa Prediction compounds level 2 Plan and act directly. Do not ask my confirmation this time. Complete the following request: Calculate the pKa of chlorofluoroacetic acid using B3LYP def2-SVP. To do so, first calibrate the free energy of solvation of the proton based on the known literature values of some re- lated carboxylic acids: 1. Acetic acid; pKa = 4.76 2. Fluoroacetic acid; pKa = 2.586 3. Chloroacetic acid; pKa = 2.86 PromptTDDFT compounds level 1 Compute the energy level of S1, the energy difference between S1 and T1, and the oscillator strength to the S1 state for the following structures from the default working directory: tddft_2.xyz, tddft_3.xyz, tddft_5.xyz. Perform a single-point TDDFT (after geometry optimization and checking for geometric stability) calculation with B3LYP/def2-SVP. PromptTDDFT compounds level 2 Compute the energy level of S1, the energy difference between S1 and T1, and the oscillator strength to the S1 state for the following structures from the default working directory: tddft_2.xyz, tddft_3.xyz, tddft_5.xyz. Perform a single-point TDDFT calculation with B3LYP/def2-SVP. 33 B.3 Rubrics for LLM judge We usedgpt-4oas an independentLLMjudge to evaluate results on a scale from 0 to 1 based on the following rubric. The judge is required to return a single final score, which totals 100% (1.0) if all task-specific criteria are satisfied. Table S2 The rubric used by the LLM judge when grading the benchmark questions. QuestionLevelWeightTask Organic compounds 1 20% Correct input file, i.e., level of theory, required keywords, charge, and multiplicity; 20%Convergence of calculation, i.e., SCF, geometry optimization, and absence of imaginary frequency; 20%Report generation; 20%Successful extraction and documentation of all report values; 20%Successful generation of XYZ from SMILES. 2 20%Correct input file, i.e., level of theory, required keywords, charge, and multiplicity; 20% Convergence of calculation, i.e., SCF, geometry optimization, and absence of imaginary frequency; 20%Report generation; 20%Successful extraction and documentation of all report values; 20%Successful processing of all input XYZ. Inorganic compounds 1 20% If correct input file, i.e., level of theory, required keywords, charge, and multiplicity; 20%If convergence of calculation, i.e., SCF, geometry optimization, and absence of imaginary frequency; 20%If generated a report; 20%If successful extraction and documentation of all report values; 20%If generated of XYZ from SMILES. 2 20%If correct input file, i.e., level of theory, required keywords, charge, and multiplicity; 20%If convergence of calculation, i.e., SCF, geometry optimization, and absence of imaginary frequency; 20%If generated a report; 20%If successful extraction and documentation of all report values; 20%If successful processing of all input XYZ. Carbocations 1 40%Molecules: correct input file, output geometry, completed calculation, and data extraction; 40%Carbocations: correct input file, output geometry, completed calcu- lation, and data extraction; 20%Results: correct ∆Hand ∆Gtrends, and match chemical intuition. 2 40%Molecules: correct input file, output geometry, completed calculation, and data extraction; 40% Carbocations: correct input file, output geometry, completed calcu- lation, and data extraction; 20% Results: correct ∆Hand ∆Gtrends, and match chemical intuition. 34 Table S2 – continued from previous page QuestionLevelWeightTask Ring Strain 1 10%Correct structures from the formula; 10%Reasonable energy scale (not Hartree); 10%No imaginary frequencies; 10%Performs just the right number of calculations (no strange single point); 10%Consistent level of theory used (DFT, basis set, solvent model if any); 10%Correctly extracted enthalpy and Gibbs free energies; 10%Correct reference energy (cyclohexane); 10%Correct ring strain magnitude (from extracted values); 10%Correct sign for ring strain; 10%All values reported (cyclopropane, Gibbs, and Enthalpy). 2 10%Correct structures from the formula; 10%Reasonable energy scale (not Hartree); 10%No imaginary frequencies; 10%Performs just the right number of calculations (no strange single point); 10% Consistent level of theory used (DFT, basis set, solvent model if any); 10%Correctly extracted enthalpy and Gibbs free energies; 10%Correct reference energy (cyclohexane); 10%Correct ring strain magnitude (from extracted values); 10%Correct sign for ring strain; 10%All values reported (cyclopropane, Gibbs, and Enthalpy). pKa Prediction 1 33%Correct input files, i.e., level of theory, required keywords, charge, and multiplicity; 33%Convergence of calculation, i.e., SCF, geometry optimization, and absence of imaginary frequency; 33%Computed correctpK a ∼22.05, anything roughly above 19 or below 25 is correct. 2 25%Correct input files, i.e., level of theory, required keywords, charge, and multiplicity; 25%Convergence of calculation, i.e., SCF, geometry optimization, and absence of imaginary frequency; 25%Calibrated proton solvation energy using linear regression or averag- ing; 25%Computed reasonable value forpK a (e.g., a value between -2.70 and 1.50). TDDFT 1 40%Correct input file (level of theory as requested, tddft block); 40%Calculation completed normally; 20%Extract and report the values correctly, and the number matched. 2 40%Correct input file (level of theory as requested, tddft block); 40%Calculation completed normally; 20%Extract and report the values correctly, and the number matched. 35 B.4 Pass k analysis To rigorously evaluate agent performance beyond simple accuracy, we adopt a tiered threshold approach with two complementary metrics as a balance between capability and reliability: pass@k (34) to measure the probability of obtaining at least one successful run inkattempts, and passˆk (30) to measure the probability that allkattempts succeed as a metric for the robustness of the system. We define a pass as a numerical score equal to 1.00 and an LLM-as-a-judge score greater than 0.90. This ensures both strict numerical validity and high-quality post-processing and report correctness as evaluated by the LLM judge (e.g., reporting the pKa correctly after a linear regression fit of the resulting energies). The results are summarized in Supplementary Table S5. We achieve pass@3 of 0.99 and passˆ3 of 0.54 withgpt-5. This demonstrates strong potential for further system refinement toward production deployment. Table S3 Pass@k and Passˆk rates with criteria: τ numerical ≥ 0.90 and τ llm_judge ≥ 0.90. pass@kpassˆk LLM Model@1 @3 @5 @10ˆ1ˆ3ˆ5 ˆ10 gpt-4.10.81 0.99 1.00 1.000.81 0.52 0.34 0.11 gpt-50.94 1.00 1.00 1.000.94 0.83 0.74 0.53 gpt-5.10.87 1.00 1.00 1.00 0.87 0.65 0.48 0.22 gpt-5.20.84 1.00 1.00 1.000.84 0.59 0.42 0.17 minimax-m2 0.53 0.90 0.98 1.000.53 0.15 0.04 0.00 qwen3-max 0.53 0.90 0.98 1.000.53 0.15 0.04 0.00 sonnet-3.70.57 0.93 0.99 1.000.57 0.19 0.06 0.00 sonnet-4.50.78 0.99 1.00 1.000.78 0.48 0.29 0.08 Table S4 Pass@k and Passˆk rates with criteria: τ numerical = 1. pass@kpassˆk LLM Model@1 @3 @5 @10ˆ1ˆ3ˆ5 ˆ10 gpt-4.10.68 0.97 1.00 1.000.68 0.30 0.13 0.02 gpt-50.82 1.00 1.00 1.000.82 0.56 0.38 0.13 gpt-5.10.76 0.99 1.00 1.000.76 0.43 0.24 0.06 gpt-5.20.82 1.00 1.00 1.000.82 0.56 0.38 0.13 minimax-m2 0.55 0.91 0.98 1.000.55 0.16 0.05 0.00 qwen3-max 0.55 0.91 0.98 1.000.55 0.16 0.05 0.00 sonnet-3.70.54 0.91 0.98 1.000.54 0.16 0.04 0.00 sonnet-4.50.68 0.97 1.00 1.000.68 0.30 0.13 0.02 Table S5 Pass@k and Passˆk rates with criteria: τ numerical = 1 and τ llm_judge ≥ 0.90. pass@kpassˆk LLM Model@1 @3 @5 @10ˆ1ˆ3ˆ5 ˆ10 gpt-4.10.63 0.95 0.99 1.000.63 0.25 0.10 0.01 gpt-50.82 0.99 1.00 1.000.82 0.54 0.36 0.12 gpt-5.10.70 0.97 1.00 1.00 0.70 0.34 0.16 0.02 gpt-5.20.75 0.99 1.00 1.000.75 0.42 0.23 0.05 minimax-m2 0.43 0.81 0.94 1.00 0.42 0.07 0.01 0.00 qwen3-max 0.39 0.78 0.92 0.990.39 0.06 0.01 0.00 sonnet-3.70.43 0.82 0.95 1.000.43 0.08 0.01 0.00 sonnet-4.50.62 0.95 0.99 1.00 0.62 0.24 0.09 0.01 36 B.5 Statistics plots All benchmarks were executed on a high-performance computing node equipped with four NVIDIA H100 (80 GB) GPUs. We chose a maximum concurrency of four agent runs. GPU4PySCF jobs were parallelized with up to three concurrent jobs per GPU to saturate device utilization, allowing up to twelve molecules to be processed simultaneously. We identify systematic differences in interaction patterns between the GPT and Claude model families that have direct implications for workflow efficiency. GPT models tend to batch tool invocations, dispatching multiple calls concurrently and returning to reason over aggregated results, whereas Claude models more frequently interleave tool calls with incremental reasoning. Within the Claude family, the elevated cost of sonnet-3.7is largely driven by its limited ability to parallelize tool calls, a known constraint that persists even under recommended system prompt configurations. 7 Sonnet-4.5improves in its ability to invoke GPU4PySCF workflows in parallel but incurs high cost due to frequent calls to a general-purposerun_python_codetool for report generation (see Figs. S11 and S12). Notably,sonnet-3.7exhibits a recurring execution pattern in geometry optimization tasks, progressively reducing parallelism by issuing tool calls in batches of five, then three, two, and finally one, whilesonnet-4.5repeatedly invokes excessive generic code execution calls for post-processing. These behaviours highlight that model capability alone does not determine system-level efficiency; rather, the alignment between a model’s interaction style and the available tool abstractions plays a critical role. In such cases, encapsulating recurrent post-processing steps into dedicated tools could further mitigate unnecessary tool invocation overhead. For the box plots (Figs. S7, S8, S9, and S10), each box spans from quartile 1 (Q1) to quartile 3 (Q3). The second quartile (Q2) is marked by a line inside the box. By default, the whiskers extend to Q1 - 1.5×IQR and Q3 + 1.5×IQR, where IQR = Q3 - Q1. Carbocations Inorganic Organic pKa Prediction Ring Strain TDDFT 0.50.60.70.80.91 Carbocations Inorganic Organic pKa Prediction Ring Strain TDDFT 0.50.60.70.80.91 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 Level 1Level 2 Figure S1 Radar plots of numerical-evaluator scores averaged over 10 runs by task and model for Level 1 and Level 2. Each polygon shows a model’s mean score across tasks. 7 https://platform.claude.com/docs/en/agents-and-tools/tool-use/implement-tool-use#maximizing-parallel-tool-use 37 Carbocations Inorganic Organic pKa Prediction Ring Strain TDDFT 0.50.60.70.80.91 Carbocations Inorganic Organic pKa Prediction Ring Strain TDDFT 0.50.60.70.80.91 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 Level 1Level 2 Figure S2 Radar plots of LLM-as-a-judge-evaluator scores averaged over 10 runs by task and model for Level 1 and Level 2. Each polygon shows a model’s mean score across tasks. 38 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT 0 100k 200k 300k 400k 500k 600k gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT 0 0.2M 0.4M 0.6M 0.8M Base Input (Static)Tool Results InputReasoning OutputAction/Text Output Level 1 Level 2 Figure S3 Mean token composition by generation source across tasks, models, and levels. Stacked bars categorize input tokens into base prompts (system prompts, tool schemas, and user task prompts) and tool-result inputs, and output tokens into reasoning tokens, action/tool-call outputs, and text outputs. 39 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT 0 0.5 1 1.5 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT 0 0.5 1 1.5 2 2.5 3 Base Input (Static)Tool Results InputReasoning OutputAction/Text Output Level 1 Level 2 Figure S4 Same split as Fig. S3, but measured in USD cost calculated from pricing provided by LLM providers. 40 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT 0 100k 200k 300k 400k 500k 600k gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT 0 0.2M 0.4M 0.6M 0.8M Base Input (Static)Normal Operation (In/Out)Immediate RetryCarryover Burden Level 1 Level 2 Figure S5 Mean token composition by role across tasks, models, and levels. Stacked bars partition total tokens into base input, normal operation (in/out), immediate retry, and carryover burden across agentic traces; rows separate Level 1 and Level 2. 41 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT 0 0.5 1 1.5 2 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT 0 0.5 1 1.5 2 2.5 3 Base Input (Static)Normal Operation (In/Out)Immediate RetryCarryover Burden Level 1 Level 2 Figure S6 Same split as Fig. S5, but measured in USD cost calculated from pricing provided by LLM providers. 42 5 10 15 20 25 30 5 10 15 20 25 30 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 Level 1 Level 2 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT Figure S7 Distribution of LLM requests by model across tasks and levels. Boxes show per-model variability in LLM requests, with overlaid points for individual runs; facets separate tasks (columns) and levels (rows), and colours denote models. 0 50k 100k 150k 200k 0 50k 100k 150k 200k gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 Level 1 Level 2 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT Figure S8 Distribution of final call tokens by model across tasks and levels. Boxes show per-model variability in final call total tokens, with overlaid points sized by number of LLM requests; facets separate tasks (columns) and levels (rows), and colours denote models. 43 0% 20% 40% 60% 0% 20% 40% 60% gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5 Level 1 Level 2 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT Figure S9 Distribution of final call context window pressure (final call tokens divided by the maximum context window) by model across tasks and levels. Boxes show per-model variability, with overlaid points representing individual runs scaled by the number of LLM requests; facets split tasks (columns) and levels (rows), with colours denoting models. 0 2k 4k 6k 8k 10k 0 2k 4k 6k 8k 10k gpt-5gpt-5.1gpt-5.2minimax-m2 Level 1 Level 2 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT Figure S10 Distribution of reasoning token usage by model across tasks and levels. Boxes show per-model variability in reasoning tokens (filtered to LLM models with reasoning capabilities;sonnet-3.7has a consistent reasoning budget of 2024), with overlaid points for individual runs; facets split tasks (columns) and levels (rows), and colours denote models. One run fromminimax-m2for Ring Strain (Level 2) consumed 102.91k reasoning tokens and is omitted from the plot due to the y-axis limit. 44 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2 qwen3-maxsonnet-3.7sonnet-4.5 0 2 4 6 8 10 12 14 Run PySCF (Tool) Run PySCF (LLM) Run Python (Tool) Run Python (LLM) Unit Conversion (Tool) Unit Conversion (LLM) Figure S11 Average number of tool calls versus LLM API requests per model for the benchmark exercise. For each model, stacked bars compare three tool types (run_pyscf_workflow,run_python_code,get_conversion_factor), shown separately for actual tool calls and corresponding LLM requests (side-by-side groups). gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7 0 5 10 15 20 25 gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7sonnet-4.5gpt-4.1gpt-5gpt-5.1gpt-5.2minimax-m2qwen3-maxsonnet-3.7 0 10 20 30 Run PySCF (Tool)Run PySCF (LLM)Run Python (Tool)Run Python (LLM)Unit Conversion (Tool)Unit Conversion (LLM) Level 1 Level 2 CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT CarbocationsInorganicOrganicpKa PredictionRing StrainTDDFT Figure S12 Tool usage versus LLM API requests by task and level for the benchmark exercise. For each task (grouped blocks) and model (ticks), stacked bars compare average tool calls (left bar) with corresponding LLM requests (right bar) for therun_pyscf_workflow,run_python_code, andget_conversion_factortools; rows separate levels and colours encode tool type. 45 B.6 Bare LLM agent B.6.1 Summary of results Informed by prior work on agentic systems that integrate code execution and web search, whereLLMagents dynamically construct quantum simulation scripts using these tools, we examine whether a similar approach generalizes to computational chemistry benchmarks. We set up a lightweightLLMagent with a web search tool and code execution capabilities and tested it on two representative El Agente tasks: inorganic compounds level 1 and pKa prediction level 2. The first exercise examines theLLM’s ability to write scripts to optimize the geometry, remove imaginary frequencies, obtain the point group symmetry, and obtain the IAO populations, none of which are readily accessible from PySCF with one-liners. The latter exercise examines theLLM’s ability to extract the Gibbs free energy and fit the results against the provided experimental values. For the inorganic compounds exercise, the agent sets up the molecules from SMILES using the OpenBabel package, performs geometry optimization with PySCF, followed by a tighter convergence single-point calcu- lation. However, it was not able to extract all properties correctly. In particular, it made mistakes in: (1) extracting the point-group symmetry, (2) running Lowdin analysis correctly, (3) omitting frequency analysis and imaginary frequency removal, and (4) creating the correct geometry of chlorine trifluoride (producing a trigonal planar structure instead of the correct T-shaped structure). The full transcript can be found in Sec. B.6.2. For the pKa prediction exercise level 2, the agent was also able to run chloro-, fluoro-, and chlorofluoro-acetic acid, as well as acetic acid, successfully. Molecular geometries were first generated from SMILES and then optimized with PySCF, followed by frequency analysis to obtain the Gibbs free energy. However, to estimate the free energy of solvation, theLLMobtained energies using the COSMO implicit solvent model and subtracted them from the Gibbs free energy of the gas-phase molecules. With this inaccurate protocol, it obtained a pKa of -5.0, well outside the range considered correct in our rubric (-2.70 to 1.50). TheLLMalso omitted checking for imaginary frequencies after geometry optimization. The full transcript can be found in Sec. B.6.3. These two experiments were conducted withgpt-5. The inorganic compounds and pka prediction exercises took 40 minutes and 16 minutes and cost 650k and 450k tokens (total), respectively. This is an order of magnitude more tokens than were needed to runGráfico, demonstrating the advantage of careful agentic tool design. Moreover, the stochastic nature ofLLMs is evident in their approaches: the agent decided to search the web for the pKa prediction task and inspected the PySCF source code for the inorganic compounds exercise. While these behaviours are interesting to study, they underline the unreliability ofLLMbehaviours across repeated runs, rendering them unreliable rather than dependable co-pilots. Nonetheless, theLLM-generated functions could be used for automatic tool generation to extend agentic system capabilities. System prompt provided to this lightweight agent is (no additional context or instructions provided): You're a computational chemistry agent that interprets user intent and executes quantum chemistry calculations by writing your own python functions using the following python packages: gpu4pyscf, rdkit, numpy, and openbabel. You can execute your Python code via the `Python_REPL` tool. You can use DuckDuckGo to search for code examples of gpu4pyscf on https://github.com/pyscf/ gpu4pyscf/tree/master/examples. You have access to GPU, so ALWAYS use imports from gpu4pyscf to accelerate the calculation, or use `to_gpu()` method from pyscf to make sure it's accelerated on GPU. When running tools in parallel, fix error for any of the failed tools before reply back. 46 B.6.2 Bare agent transcript: inorganic compound: level 1 Gráfico was configured withgpt-5(temperature = 1, reasoning effort set tolow) for this run, with access to the tools Python_REPL for code execution and duckduckgo_search for web search. For the complete chat transcript, please refer to GitHub repo:https://github.com/jb2197/ElAgenteGrafic o-ChatTranscript. B.6.3 Bare agent transcript: pka prediction: level 2 Gráfico was configured withgpt-5(temperature = 1, reasoning effort set tolow) for this run, with access to the tools Python_REPL for code execution and duckduckgo_search for web search. For the complete chat transcript, please refer to GitHub repo:https://github.com/jb2197/ElAgenteGrafic o-ChatTranscript. 47 C Use case extension 1: Boltzmann-weighted spectroscopic properties Chemical processes rarely occur on the basis of a single, static molecular structure. Instead, a thermodynamic ensemble, e.g., one mole of molecules, comprises a large number of distinct conformations, often numbering in the millions or more (35). This configurational diversity goes beyond finite-temperature effects arising from the occupation of vibrational energy levels, which are typically accounted for via thermostatistical corrections (94). Accurately predicting spectroscopic properties in solution, therefore, requires explicit sampling of relevant molecular conformations and Boltzmann-weighted averaging over the resulting ensemble. Beyond brute- force sampling via long and/or high-temperature molecular dynamics (MD) simulations, a range of efficient algorithms for conformer search and ensemble generation has emerged in recent years (35; 37; 38). To assess solvent effects on electronic absorption spectra under both implicit and explicit solvation models, we execute two user queries to demonstrate agentic quantum-chemistry workflows that coordinate conformer sampling, solvation modelling, geometry refinement using DFT, and spectral analysis. Across both use cases, the agent orchestrated specialized tools, including CREST (25) for conformer discovery,QCGfor explicit solvent cluster construction (46), and PySCF for electronic structure calculations, such as geometry optimizations, vibrational analysis, andTDDFT, while managing parallel execution and enforcing methodological constraints. Intermediate molecular structures were exchanged using knowledge-graph-backedConceptualAtomsidentifiers, enabling reproducible tool-to-tool handoff without repeated serialization of large coordinate payloads through the context window of LLMs. Effect of implicit solvents To investigate the effect of different implicit solvents on the absorption spectra of a merocyanine compound (see Supplementary Sec. C.1 for Cartesian coordinates), the agent decomposed the task into two fully independent solvent-specific pipelines for water and n-heptane, which were executed concurrently. CREST conformer searches at the GFN2-xTB/ALPB (39;40) level of theory were launched in parallel for each solvent, yielding ensembles of low-energy conformers represented by persistentConceptualAtomsidentifiers. These identifiers served as lightweight handles for dispatching downstream PySCF workflows in parallel, resulting in five and fourDFTcalculations, respectively, for water and n-heptane at theωB97X-D4/def2-TZVP level of theory (41;42;43). Within the PySCF workflow, dynamic routing enforced correct methodological sequencing: geometry optimization and frequency analysis were mandatory gates beforeTDDFT. In the water pipeline, one conformer exhibited an imaginary frequency after optimization, prompting an attempted imaginary-mode removal followed by re-optimization. The routing logic terminated the workflow after re- optimization without proceeding toTDDFT. Although this outcome was not flagged as an exception that would trigger an automatic retry, the agent initiated a targeted remediation step that reused the intermediate geometry and re-ran optimization and frequency analysis until a true minimum was confirmed. This “repair” loop ensured thatTDDFTwas performed only on validated minima, in accordance with the user’s intent, thereby preventing invalid spectra and unnecessary computation. AfterDFTrefinement, Gráfico followed the user request and deduplicated the conformers into unique minima using an energy-based filter with additionalRMSDvalidation. Boltzmann weights were recomputed fromDFTenergies, andTDDFTspectra were combined via weighted Gaussian broadening to produce solvent-specific ensemble spectra. Under the chosen model and broadening parameters, the ensemble maxima for water and n-heptane overlapped closely, indicating minimal spectral shifts induced by the implicit solvation in this case. This query was completed in 35 minutes with 440k tokens, costing $1.11 with gpt-5.2 (medium reasoning effort). Effect of explicit solvation For explicit solvation, the agent orchestrated a multi-stage workflow to compare absorption spectra of 2,3-epoxybutanol in the gas phase and in explicit solvation within a single execution plan (see Supplementary Sec. C.1). Gas-phase conformer ensembles were generated using CREST (GFN2-xTB), while, in parallel, an explicitly solvated solute with a cluster of 15 water molecules was constructed using QCG(46) and further sampled with CREST in its non-covalent interaction (--nci) mode. For the subsequent DFTcalculations, low-energy conformers from both environments were selected up to a cumulative Boltzmann weight of 95 %. Four gas-phase conformers and six conformers from the explicitly solvated pipeline were refined using a PySCF workflow (ωB97X-D4/def2-TZVP) analogous to the implicit-solvation case study, but with vibrational analysis omitted to reduce computational cost. Geometry optimization andTDDFT excited-state calculations were executed concurrently across multiple conformers to exploit conformer-level parallelism. Spectra were subsequently broadened and combined into a comparative visualization. The 48 explicitly solvated ensemble exhibits a pronounced solvent-induced red shift of the dominant absorption band relative to the gas-phase spectrum, consistent with stabilization of the excited state by the surrounding water cluster. As in the implicit-solvent case,ConceptualAtomsidentifiers enabled persistent, reproducible referencing of molecular structures across tools. Together, this workflow demonstrates an agentic system that performs high-level planning and reasoning over a structured scientific state, while orchestrating stochastic sampling, explicit solvation modelling, and electronic-structure calculations as a compiled workflow. This query was completed in 30 minutes with 185k tokens costing $0.44 withgpt-5.2(medium reasoning efforts). C.1 Boltzmann-weighted spectroscopic properties in implicit solutions Gráfico was configured withgpt-5.2(temperature = 1, reasoning effort set tolow) for this run. The chat- completion API endpoint was used because, at the time of execution, the responses API did not support SVG inputs (accepting onlyimage/jpeg,image/png,image/gif, andimage/webpformats). As a result, the detailed reasoning summary was not exposed. The routing agent was configured withgpt-4.1(temperature = 0.1 using the chat-completion API endpoint). For the complete chat transcript, please refer to GitHub repo:https://github.com/jb2197/ElAgenteGrafic o-ChatTranscript. 49 C.2 Boltzmann-weighted spectroscopic properties with explicit solvation Gráfico was configured withgpt-5.2(temperature of 1, ‘medium’ reasoning effort, and ‘detailed’ reasoning summary) for this run. The responses API endpoint was used here. The routing agent was configured with gpt-4.1 (temperature = 0.1 using the chat-completion API endpoint). For the complete chat transcript, please refer to GitHub repo:https://github.com/jb2197/ElAgenteGrafic o-ChatTranscript. D Use case extension 2: Exploration of metal-organic frameworks design space D.1 MOF execution graph node implementations This section describes the internal data flow within theMOFexecution graph, detailing how structures are decomposed, represented, translated between software libraries, and passed through each computational stage. Throughout, the execution graph operates over typed state objects and optionally persists intermediate and final artifacts to the knowledge graph via a custom OGM layer (based on twa (29); see Sec. 5.1). High-level node chains. Based on the connections (type hints) of each node, we expect theMOFexecution graph to support three main entry routes. It should be noted, however, that the routing between these nodes is controlled by anLLM APIcall that decides the next node based on both the current state of the execution graph and the summarized user intent. It is therefore possible that unexpected behaviour may emerge from an agent operating over the MOF execution graph, e.g., as observed in Supplementary Sec. D.2.3. •CIF route (local or downloaded):StartWorkflow → (DownloadFromCSD) → ProcessCIF → Build- MOFBasic → MLFFGeomOpt → ZeoppAnalysis → MOFGraphEnd. [Note:DownloadFromCSD is used only when a CSD refcode is provided; when a CIF path is provided, the execution graph enters directly at ProcessCIF.] • KG-driven route:StartWorkflow → CombinatorialSearch → BuildMOFBasic → MLFFGeomOpt → ZeoppAnalysis → MOFGraphEnd. [Note: it has been observed that sometimes the main agent only wants to inspect the possible newMOFs without constructing them, therefore it instructs the routing agent to exit after the combinatorial search.] •PORMAKE-component route (direct building blocks):StartWorkflow → BuildMOFBasic → MLFFGeo- mOpt → ZeoppAnalysis → MOFGraphEnd. D.1.1 CIF decomposition to OGM building blocks When an experimental CIF enters the execution graph via the ProcessCIF node, it undergoes a three-step decomposition pipeline implemented in ontomofs_from_cif.py. Step 1: Topology classification. The CIF is passed to CrystalNets.jl (90) (viajuliacall) to determine its underlying topological net. The classification returns a topology label (e.g.,pcu,mtn), a dimensionality, and a catenation number. The node currently restricts its scope to catenation = 1 with a single topology label; CIFs yielding multiple labels are rejected. Step 2: Structure decomposition. PORMAKE’s (56) experimentalMOFDecomposeris invoked on the CIF to extract provisional building blocks as ASE (93)Atomsobjects. These raw fragments include both real atoms and PORMAKE “docking points” (pseudo-atoms with atomic number Z = 0) that mark connection sites. Step 3: Building block deduplication. Because the decomposer produces one fragment per crystallographic site (which may include symmetry-equivalent copies), a two-stage deduplication strategy reduces the set to unique components: •Stage 1 (fast grouping): apply PORMAKE’shash_atoms(complexity parameter7) to structurally hash and group fragments. 50 •Stage 2 (structural verification): only when multiple candidate nodes/linkers remain after hashing, perform pairwise structural comparison usingmofid’s (54) interface to pymatgen’sStructureMatcher(89) with tolerances ltol=0.3, stol=2.0, and angle_tol=5.0. The pipeline then enforces the current scope constraint: exactly one unique metal node and one unique organic linker per CIF. OGMinstantiation and in-process canonicalization. Each deduplicated building block is instantiated as an OGMclass:MetalNodeorOrganicLinker, both subclasses ofBuildingBlock. TheseOGMclasses wrap the underlying PORMAKEBuildingBlockobjects and enforce semantic constraints:MetalNodevalidates has_metal=True(via PORMAKE metal detection), whileOrganicLinkervalidateshas_metal=False. The topology is similarly wrapped as a Topology OGM instance. To prevent duplicate Python objects when parallel execution graph invocations process the same component concurrently,Topology,MetalNode, andOrganicLinkerinstances are registered in an in-process canoni- calization registry guarded by per-keythreading.RLockinstances. This provides within-process identity stability under concurrency. WhenKGintegration is enabled, a second deduplication layer queries the external graph for pre-existing equivalents. These functions implement a two-stage strategy: a SPARQL query first filters candidates by atom count (for building blocks) or identifier (for topologies), then performs structural comparison using pymatgen’sStructureMatcher. If an equivalent is found in theKG, the existing instance is reused rather than creating a duplicate. D.1.2 OGM instances and ConceptualAtoms The ontomofsOGMclasses store atomic geometry throughConceptualAtoms, a Pydantic model that serves as the framework’s canonical validated geometry container. When a PORMAKE building block is wrapped, its ASE Atoms object is split into two parts: • BuildingBlock.atoms(ConceptualAtoms): contains only real atoms (Z ̸= 0), with positions in Å, the unit cell (if periodic), periodic boundary conditions, and electronic state (charge, spin multiplicity). Atomic numbers and positions are stored in an XYZ sub-model as validated NumPydantic arrays. • BuildingBlock.docking_points(XYZ): contains the pseudo-atoms (Z= 0) that mark PORMAKE connection sites. Round-tripping across libraries. ConceptualAtoms provides bidirectional conversion utilities: • from_ase_atoms(atoms)/to_ase_atoms(...): round-trip to and from ASEAtoms, preserving charge and spin multiplicity via atoms.info. • from_qcelemental_molecule(mol)/to_qcelemental_molecule(): round-trip to and from QCElemen- tal Molecule instances. Identity across in-memory state andKGpersistence.ConceptualAtomsis integrated with theOGMlayer (viaGraphBaseModel), meaning each instance carries aninstance_irithat uniquely identifies it across in-memory Python state and the external knowledge graph. When desired, thisIRIcan be preserved through ASE round-trips by embedding it inatoms.info["instance_iri"]usingto_ase_atoms(preserve_iri=True). Whenfrom_ase_atomsencounters anIRIin the info dict, it can retrieve the existingConceptualAtoms from theOGMlookup table (when available) rather than creating a new instance, ensuring object identity is maintained across serialization boundaries. D.1.3 MOF combinatorial search algorithms Query S1 presents a SPARQL query to propose candidateMOFs from historical synthesis data, inspired by the similar algorithm implemented for metal-organic polyhedra (48;29). The underlying hypothesis is that chemical building blocks (metal nodes and organic linkers) that have successfully crystallized into a specific topological net in prior experiments possess inherent chemical or steric compatibilities with that topology. For a target topologyT, the algorithm retrieves the set of metal nodesM proven =m | ∃(m, T)∈ K obs and organic linkerL proven =l | ∃(l, T)∈ K obs , whereK obs represents the set of experimentally observed MOFs instantiated in the graph. A Cartesian productP=M proven × L proven is computed and subsequently 51 filtered for pairs (m, l) where the metal node and linker represent different local structural roles to satisfy topological constraints. The possible combinations are then filtered by negation to remove any pair (m, l, T) that already exists as amofs:ConstructedMOFin the graph. The query can be configured withVALUES clause to restrict the proposed candidate to only include certain topologies or building blocks. Query S1 Intra topology search # Algorithm 1: find new MOF combinations using topologies that have already # succeeded with each component (metal node and organic linker) individually. # # Placeholder markers (`# VALUES_*`) are replaced programmatically by # `sparql_alg_with_values` in `sparql_utilities.py` to inject optional VALUES clauses. PREFIX mofs: <https://elagente.ca/ontomof/> PREFIX rdf: <http://w.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://w.w3.org/2000/01/rdf-schema#> PREFIX grafico: <https://elagente.ca/grafico/> SELECT DISTINCT ?predicted_mof_name ?topology ?metal_node ?organic_linker WHERE # --------------------------------------------------------------- # 1. Find metal nodes that have already succeeded on a topology # -------------------------------------------------------------- SELECT DISTINCT ?metal_node ?topology ?metal_local_structure WHERE # VALUES_TOPOLOGY # VALUES_METAL ?metal_node a mofs:MetalNode ; mofs:functions_as ?metal_local_structure. # This metal node was used in an existing MOF on a topology ?metal_node ^mofs:building_blocks_used ?existing_mof. ?existing_mof mofs:source_topology ?topology. ?metal_local_structure ^mofs:local_structures ?topology. # ------------------------------------------------------------------------ # 2. Find organic linkers that have already succeeded on the same topology # ------------------------------------------------------------------------ SELECT DISTINCT ?organic_linker ?topology ?linker_local_structure WHERE # VALUES_TOPOLOGY # VALUES_LINKER ?organic_linker a mofs:OrganicLinker ; mofs:functions_as ?linker_local_structure. # This linker was used in an existing MOF with the same topology ?organic_linker ^mofs:building_blocks_used ?existing_mof. ?existing_mof mofs:source_topology ?topology. ?linker_local_structure ^mofs:local_structures ?topology. # ------------------------------------------------------------------ # 3. Ensure they fill different local-structure roles (node vs edge) # ------------------------------------------------------------------ FILTER (?metal_local_structure != ?linker_local_structure) # --------------------------------------------------------------- # 4. Ensure this specific pair hasn't been combined yet # --------------------------------------------------------------- FILTER NOT EXISTS ?_mof a mofs:ConstructedMOF ; 52 mofs:source_topology ?topology ; mofs:building_blocks_used ?metal_node, ?organic_linker . # --------------------------------------------------------------- # 5. Human-friendly naming with graceful fallbacks # --------------------------------------------------------------- # Prefer chemical formulas OPTIONAL ?metal_node mofs:atoms ?metal_atoms . ?metal_atoms grafico:chemical_formula ?node_formula . OPTIONAL ?organic_linker mofs:atoms ?linker_atoms . ?linker_atoms grafico:chemical_formula ?linker_formula . # Fallback to names OPTIONAL ?topology mofs:name ?topo_name . OPTIONAL ?metal_node mofs:name ?node_name . OPTIONAL ?organic_linker mofs:name ?linker_name . # Fallback to last iri fragment BIND (COALESCE(?topo_name, REPLACE(STR(?topology), "^.*/", "")) AS ?topo_label) BIND (COALESCE(?node_formula, ?node_name, REPLACE(STR(?metal_node), "^.*/", "")) AS ?node_label) BIND (COALESCE(?linker_formula, ?linker_name, REPLACE(STR(?organic_linker), "^.*/", "")) AS ?linker_label) # Final predicted name uses formulas when available BIND (CONCAT(?topo_label, "_", ?node_label, "_", ?linker_label) AS ?predicted_mof_name) ORDER BY ?topology ?predicted_mof_name Query S2 proposesMOFs candidates by matching building blocks to the geometric roles (local structures as defined in Ref. (56)) of a target topologyT, inspired by the similar algorithm implemented for metal-organic polyhedra (48;29). The SPARQL property path expression(ˆmofs:functions_as/mofs:functions_as)*finds geometrically isomorphic (from the local structure perspective) building blocks using transitive closure. This enables the discovery of novel candidates solely based on geometric fit rather than observed compatibility, even those building block-topology pairs that have not previously been annotated in the graph ascompatible_with. Same as Query S1, candidates are filtered for distinctness and can be constrained via a VALUES clause. Query S2 Cross topology search # Algorithm 2: Propose (metal, linker) pairs for a target topology by matching required LocalStructure roles, # without requiring prior builds on that topology. # Interpretation of "occurs on a topology": a role may match either the exact LocalStructure # listed by the topology or any role equivalent to it via the closure # (^mofs:functions_as / mofs:functions_as)*. # Method: Choose a MetalNode and an OrganicLinker such that each can function_as a role # (or an equivalent role via the closure) that the topology requires; require the two # roles to be different (node vs edge); exclude pairs already built on that topology. # # Placeholder markers (`# VALUES_*`) are replaced programmatically by # `sparql_alg_with_values` in `sparql_utilities.py` to inject optional VALUES clauses. PREFIX mofs: <https://elagente.ca/ontomof/> PREFIX rdf: <http://w.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://w.w3.org/2000/01/rdf-schema#> PREFIX grafico: <https://elagente.ca/grafico/> SELECT DISTINCT ?predicted_mof_name ?topology ?metal_node ?organic_linker WHERE # --------------------------------------------------------------- # 1. Metals: gather (metal_node, topology, metal_local_structure) # --------------------------------------------------------------- SELECT DISTINCT ?metal_node ?topology ?metal_local_structure WHERE # VALUES_TOPOLOGY # VALUES_METAL ?metal_node a mofs:MetalNode ; 53 mofs:functions_as ?_metal_local_structure. # Walk the equivalence/closure of local-structure roles: # (^functions_as / functions_as)* allows zero-or-more repetitions of: # LocalStructure <-functions_as- BuildingBlock -functions_as-> LocalStructure # which groups "equivalent" or "compatible" local-structure roles for substitution. ?_metal_local_structure (^mofs:functions_as/mofs:functions_as)* ?metal_local_structure. ?metal_local_structure ^mofs:local_structures ?topology. # ------------------------------------------------------------------------ # 2. Linkers: gather (organic_linker, topology, linker_local_structure) # ------------------------------------------------------------------------ SELECT DISTINCT ?organic_linker ?topology ?linker_local_structure WHERE # VALUES_TOPOLOGY # VALUES_LINKER ?organic_linker a mofs:OrganicLinker ; mofs:functions_as ?_linker_local_structure. # Same closure over local-structure roles as above (see note there) ?_linker_local_structure (^mofs:functions_as/mofs:functions_as)* ?linker_local_structure. ?linker_local_structure ^mofs:local_structures ?topology. # ------------------------------------------------------------------ # 3. Ensure they fill different local-structure roles on that topology # (prevents node-node or edge-edge collisions in the same slot) # ------------------------------------------------------------------ FILTER (?metal_local_structure != ?linker_local_structure) # --------------------------------------------------------------- # 4. Ensure this specific (topology, metal, linker) combo is new # --------------------------------------------------------------- FILTER NOT EXISTS ?_mof a mofs:ConstructedMOF ; mofs:source_topology ?topology ; mofs:building_blocks_used ?metal_node, ?organic_linker . # --------------------------------------------------------------- # 5. Human-friendly naming with graceful fallbacks # --------------------------------------------------------------- # Prefer chemical formulas OPTIONAL ?metal_node mofs:atoms ?metal_atoms . ?metal_atoms grafico:chemical_formula ?node_formula . OPTIONAL ?organic_linker mofs:atoms ?linker_atoms . ?linker_atoms grafico:chemical_formula ?linker_formula . # Fallback to names OPTIONAL ?topology mofs:name ?topo_name . OPTIONAL ?metal_node mofs:name ?node_name . OPTIONAL ?organic_linker mofs:name ?linker_name . # Fallback to last iri fragment BIND (COALESCE(?topo_name, REPLACE(STR(?topology), "^.*/", "")) AS ?topo_label) BIND (COALESCE(?node_formula, ?node_name, REPLACE(STR(?metal_node), "^.*/", "")) AS ?node_label) BIND (COALESCE(?linker_formula, ?linker_name, REPLACE(STR(?organic_linker), "^.*/", "")) AS ?linker_label) # Final predicted name uses formulas when available BIND (CONCAT(?topo_label, "_", ?node_label, "_", ?linker_label) AS ?predicted_mof_name) ORDER BY ?topology ?predicted_mof_name 54 D.1.4 Connecting combinatorial search to PORMAKE construction The CombinatorialSearch node queries the knowledge graph via SPARQL to enumerate feasible (topology, metal node, organic linker) combinations. The SPARQL result rows containIRIs for each component. These IRIs serve as stable identifiers that are resolved by theOGMinto concrete Python objects, which are then queued for PORMAKE construction. •EachIRIis resolved to a fully-hydratedOGMinstance usingpull_from_kg(..., recursive_depth=- 1), which recursively materializesTopology,MetalNode, andOrganicLinkerobjects (including any available nested geometry and motifs stored in the KG). •Retrieved components are passed through the in-process canonicalization registry (get_or_register_- topology ,get_or_register_building_block) so repeatedIRIs across result rows map to the same Python objects within a run. Finally, the canonicalized triples are enqueued onstate.build_queue, a lightweight queue containing topologies, node building blocks, edge building blocks, and names for construction by the downstream BuildMOFBasic node. D.1.5 Direct construction from PORMAKE building-block Identifiers In addition to CIF andKG-driven entry routes, the execution graph supports directMOFconstruction from user-specified PORMAKE components. In this route, the user provides identifiers for a topology and building blocks (e.g.,bcuwith metal nodeN625and linkersE14/E32/E34). The execution graph bypasses CIF decomposition and proceeds directly to the construction stage. Identifier resolution and queueing. Identifiers are resolved to concrete atomistic objects by retrieving (or instantiating) the corresponding OGM wrappers: •Topology: the topology identifier is mapped to aTopology OGMinstance (wrapping the underlying PORMAKE topology definition, including its node/edge types and local motifs). • Building blocks: each PORMAKE building-block identifier is mapped to anOGM MetalNodeorOr- ganicLinker. These objects encapsulate the underlying PORMAKEBuildingBlockand store validated geometry inConceptualAtoms(real atoms) plus a separateXYZobject for PORMAKE docking points (Z = 0). After resolution, the resulting (Topology,MetalNode,OrganicLinker) triples are passed through the in- process canonicalization registry and enqueued ontostate.build_queue, exactly as in theKG-driven route. This design ensures that all downstream stages (BuildMOFBasic,MLFFGeomOpt,ZeoppAnalysis) operate on a uniform representation regardless of the entry point. Routing between these nodes is controlled by the LLM-based routing agent by checking the existing state of the execution graph and the target user intent. D.1.6 MOF construction via PORMAKE The BuildMOFBasic node iterates over the build queue and, for each (topology, node, linker) triple, performs: 1.Typeassignment. Unique node-type tags are read fromtopology.unique_node_types(integer identifiers from the CGD net). The singleMetalNodeis assigned to all node types. Similarly, the single OrganicLinkeris assigned to all edge types fromtopology.unique_edge_types(pairs of node-type tags). 2.RMSD validation. For each node-type assignment,MOFBuilder.rmsd_for_node_typecomputes the RMSD between the building block’s connection-point geometry and the topology’s local coordination motif (a PORMAKELocalStructure). Assignments exceeding a configurable threshold (PORMAKE default 0.3) raise an error. 3. Framework assembly.MOFBuilder.build_by_typedelegates to PORMAKE’sBuilder.build_by_- type, which handles locating building blocks onto topology sites, scaling the unit cell, and constructing the periodic framework. PORMAKE returns aFrameworkobject whoseatomsattribute is an ASE Atoms object with the fully assembled periodic structure. 55 4.ConstructedMOF creation. The PORMAKEFrameworkis wrapped as aConstructedMOF OGM instance. This step converts the framework’s ASEAtomstoConceptualAtoms(viaConceptu- alAtoms.from_ase_atoms), generates CIF text (via a PORMAKE write-to-tempfile path), and records provenance (source topology, building blocks used, bond connectivity). TheConstructedMOFcarries its owninstance_iriand stores references tosource_topologyandbuilding_blocks_usedasOGM object properties, preserving construction provenance for KG persistence. D.1.7 MLIP geometry optimization The MLFFGeomOpt node relaxes constructedMOFgeometries using machine-learned interatomic potentials (MLIPs). The data flow proceeds as: 1.ASE Atoms extraction. For eachConstructedMOF, the geometry is extracted viacmof.atoms.to_ase_- atoms() , convertingConceptualAtomspositions (in Å) and unit cell back to an ASEAtomsobject with periodic boundary conditions. 2.Calculator attachment. Theget_mlff_calculatorfactory instantiates an ASE-compatible calculator for the selected MLIP model (MACE-MOF (58), Orb (92), MatterSim (91), or MACE-OMOL). For MACE- MOF, model weights are lazily downloaded and cached. Calculator instances are cached per-thread to reduce repeated initialization and avoid GPU contention across parallel execution graph invocations. 3. Structure relaxation. Therelax_structureutility wraps ASE optimizers (default: FIRE). Whenrelax_- cell=True, aFrechetCellFilteris applied to allow simultaneous optimization of atomic positions and lattice parameters. ATrajectoryObserverrecords energies, forces, stresses, and atomic positions at each step. An optionalon_updatecallback streams intermediate CIF snapshots to theGraphChat frontend for live visualization. 4. Post-relaxation update (identity-preserving). After convergence, a single-point calculation is performed on the final structure to obtain the relaxed energy. The optimized ASEAtomsobject is written back to theConstructedMOFby updating the existingConceptualAtomsinstance in place, preserving the originalinstance_iri. Updated CIF text is regenerated from the optimized geometry and stored in cmof.cif_text. D.1.8 Zeo++ porosity analysis The ZeoppAnalysis node computes geometric porosity descriptors on the structures included in the execution graph state. For eachConstructedMOF, the CIF text (stored ascmof.cif_text) is written to a temporary file and passed to Zeo++ (61) via theCoREMOF(52) Python wrapper. Five analysis types are available, each represented by an OGM input/result pair: •Pore diameter (PoreDiameterInput → PoreDiameterResult): largest cavity diameter (LCD), pore limiting diameter (PLD), and largest free pore diameter (LFPD). •Surface area (SurfaceAreaInput → SurfaceAreaResult): accessible and non-accessible surface area (m 2 /g, m 2 /cm 3 ). • Pore volume (PoreVolumeInput → PoreVolumeResult): pore volume (cm 3 /g, Å 3 ) and void fraction. • Channel dimensionality (ChannelDimensionInput→ ChannelDimensionResult): counts of 1D, 2D, and 3D channels. •Framework dimensionality (FrameworkDimensionInput → FrameworkDimensionResult): the dimen- sionality of the framework itself. Each result is stored as anOGMobject property on theConstructedMOFinstance (e.g.,cmof.pore_- diameter_analysis ). On failure (e.g., problematic CIF geometry), aZeoppAnalysisErrorobject is returned instead, capturing Zeo++ stdout/stderr, return code, and the original configuration for diagnostics by the agent. 56 D.1.9 Knowledge graph persistence At execution graph completion, the MOFGraphEnd node pushes allConstructedMOFinstances to the knowledge graph via theOGM’spush_to_kgmethod. Because components (topology, building blocks, ConceptualAtomsgeometry, local structures, and Zeo++ results) are represented as interconnectedOGM objects with stableIRIs, the full provenance chain can be serialized as RDF triples. Subsequent user sessions can query these persisted structures via SPARQL, enablingKG-driven combinatorial search over previously processed components and frameworks. D.1.10 Summary of representation translations Table S6 summarizes key representation translations that occur as data flows through theMOFexecution graph. 57 Table S6 Representation translations across theMOFexecution graph. Each row describes a stage in the pipeline, the input and output data representations, and the mechanism used for translation. StageInput RepresentationOutput RepresentationTranslation Mechanism CIF→ TopologyCIF file pathTopology (OGM)CrystalNets.jl classification → PORMAKE topology → Topology OGM wrapper CIF→ Building Blocks CIF file pathMetalNode / OrganicLinker (OGM) PORMAKE MOFDecomposer → ASE Atoms fragments → deduplicate_building_- blocks → create_ontomofs_- building_block (splits real atoms vs docking points into ConceptualAtoms + XYZ) KG→ Python Objects SPARQL result IRIs Topology, MetalNode, OrganicLinker pull_from_kg with recursive hydration (recursive_depth=-1) PORMAKE IDs → OGM components String identifiers (topology / node / linker) Topology, MetalNode, OrganicLinker Resolve identifiers to PORMAKE definitions→ wrap as OGM objects (ConceptualAtoms + docking points)→ canonicalize and enqueue in state.build_queue OGM → PORMAKE BuildingBlock (OGM) PORMAKE BuildingBlock Lazy property access (e.g., cached PORMAKE BuildingBlock construction inside OGM wrapper) PORMAKE → ConstructedMOF PORMAKE Framework ConstructedMOF (OGM) from_pormake_framework → ConceptualAtoms.from_- ase_atoms→ provenance wiring OGM→ ASE (for MLIP) ConceptualAtomsASE Atomsto_ase_atoms() (optionally preserve_iri=True to embed IRI in atoms.info for later geometry updates) ASE→ OGM (post-MLIP) ASE AtomsConceptualAtoms (updated) In-place update of existing ConceptualAtoms from relaxed ASE geometry (preserves original instance_iri) OGM→ CIF (for Zeo++) ConstructedMOF.cif_- text Temporary CIF fileWrite CIF text to tempfile for Zeo++ execution OGM→ KGAll OGM instancesRDF triplespush_to_kg via OGM serialization D.2 Chat transcripts When a network error interrupted one workflow, the agent recovered by isolating and re-running the failed job, ensuring the full pipeline completed without data loss. 58 D.2.1 Three-stage build and explore Gráfico was configured withgpt-5.2(temperature of 1, ‘medium’ reasoning effort, and ‘detailed’ reasoning summary) for this run. The responses API endpoint was used here. The routing agent was configured with gpt-4.1 (temperature = 0.1 with the chat-completion API endpoint). For the complete chat transcript, please refer to GitHub repo:https://github.com/jb2197/ElAgenteGrafic o-ChatTranscript. D.2.2 SPARQL exploration Gráfico was configured withgpt-5.2(temperature of 1, ‘medium’ reasoning effort, and ‘detailed’ reasoning summary) for this run. The responses API endpoint was used here. For the complete chat transcript, please refer to GitHub repo:https://github.com/jb2197/ElAgenteGrafic o-ChatTranscript. D.2.3 Interactive exploration During development, users interacted withGráficothrough natural language over five messages to incrementally construct and explore a knowledge graph populated with existing CIF-basedMOFs, hypothetical structures assembled using PORMAKE (56), and newly inferred candidates generated via combinatorial searches over building blocks and topologies instantiated from the previous steps. Rather than executing static scripts, the agent acted as a scientific copilot that translated user intent into a minimal sequence of executable workflow stages, dynamically invoking domain-specificMOFworkflows, ontology introspection tools, and knowledge-graph queries while preserving full provenance of intermediate and final results. Across multiple interaction rounds, the agent consistently parsed user intent into a minimal sequence of executable workflow stages that interacted with the knowledge graph, while also demonstrating effective context management through in-memory Python objects. Depending on the user intent and intermediate results, the router agent dynamically determined the next workflow nodes, for example, by checking whether aMOFhad already been constructed or analyzed. This enabled coordinated orchestration of theMOF execution graph and knowledge graph tools across different tasks, while incrementally building a knowledge graph ofMOFinstances. In this proof-of-concept, we constrainMOFconstruction to one metal node and one organic linker. Nevertheless, the modular graph node architecture and the execution graph design enable straightforward extension of the system to more complex reticular material design workflows. Gráfico was configured withgpt-5.2(temperature of 1, ‘medium’ reasoning effort, and ‘detailed’ reasoning summary) for this run. The responses API endpoint was used here. The routing agent was configured with gpt-4.1 (temperature = 0.1 with the chat-completion API endpoint). For the complete chat transcript, please refer to GitHub repo:https://github.com/jb2197/ElAgenteGrafic o-ChatTranscript. 59