Pith. sign in

REVIEW 3 major objections 5 minor 32 references

PUDA: An AI-Native Hardware Harness for Self-Driving Laboratories

T0 review · 3 major / 5 minor · reviewed 2026-08-01 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read PUDA proposes that the bottleneck in autonomous experimentation is the laboratory's interface, and answers it with a headless CLI runtime that AI agents can operate while hardware remains deterministic and auditable.

desk verdict Sensible, well-scoped architecture for an agent-facing SDL runtime, but it is a design document: the central determinism/auditability claims are asserted, not demonstrated, and the paper never specifies how concurrent or retried commands are serialized at the edge. read the letter →

arxiv 2607.26464 v1 pith:H7ZLTUQB submitted 2026-07-29 cond-mat.mtrl-sci cs.AI

Zekun Ren , Hongzhao Tan , Jiaen Yee , Kedar Hippalgaonkar This is my paper · ORCID
classification cond-mat.mtrl-scics.AI
keywords self-drivinglaboratorieslabautomationagentruntimecommand-lineinterfaceprovenancephysicalAIedgedriversdistributedmessaging
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper proposes PUDA, a headless command-line runtime that turns a self-driving laboratory into a stable, inspectable interface for AI agents. The central claim is that the bottleneck in autonomous experimentation is no longer whether a workflow can be automated, but whether a laboratory can expose a runtime environment that agents can operate, observe, and recover from. PUDA separates scientific reasoning from physical actuation: agents compose protocols, while reviewed driver methods own hardware control. The paper argues this design makes hardware execution deterministic, atomic, and auditable, and preserves provenance from submitted protocol through machine response to data products. A sympathetic reader would care because it offers a concrete way to make AI-driven closed-loop experiments practical without building yet another optimizer or workflow GUI.

What carries the argument

The carrying mechanism is the edge-driver command contract: each instrument is wrapped by a small driver whose public methods become the command catalog an agent can call. Around this contract PUDA builds a headless CLI for progressive discovery, a distributed publish/subscribe transport with durable streams and key-value state, and a local structured database (optionally mirrored to a central one) that stores projects, protocols, runs, samples, measurements, and command logs. The driver boundary does the safety work: agents can request named commands but cannot rewrite device-control code mid-run, and validation checks command names, input types, and value ranges before dispatch.

What would settle it

A concrete test: connect a representative instrument to PUDA, give a state-of-the-art coding agent a task that requires discovering the machine, writing a valid multi-step JSON protocol, running it, and recovering from an injected device error, and measure completion without human help. If no current agent can close this loop reliably, PUDA's value proposition depends on future agents rather than on the runtime itself.

Watch

Extended reading notes

Core claim

PUDA's central discovery is a design pattern: expose the laboratory as an AI-native command environment rather than a human GUI. Devices appear through discoverable command-line commands generated from reviewed driver methods; JSON protocols are validated before dispatch and routed through a distributed messaging layer with durable streams; every command, response, telemetry event, and data product is captured in a structured record linked by run IDs and timestamps. The paper claims this arrangement lets an AI agent complete an Observe-Orient-Decide-Act loop over physical hardware while the hardware boundary remains deterministic and auditable. The contribution is deliberately not an optimiz

Load-bearing premise

The design assumes that current LLM-based coding agents can reliably operate a real laboratory through a text command line, discovering commands, writing valid JSON protocols, and recovering from errors without human help.

Editorial extensions

If this is right

  • If PUDA works as claimed, self-driving laboratories can be operated by any CLI-capable agent or script, without GUI automation.
  • Provenance becomes machine-readable: every run has a UUID, timestamped command log, and a reproducible hash that changes if records change.
  • Multiple agents and instruments can coordinate concurrently over the same messaging backbone without a fixed workflow graph.
  • Human-in-the-loop operation remains possible: agents draft protocols and wait for approval before risky hardware actions, preserving the same audit trail as full autonomy.
  • Accumulated command histories, observations, and recoveries become structured training data for future models that operate physical laboratories.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the agent-capability premise holds, PUDA's command surface could become a de facto standard interface for physical AI systems, letting the same agent logic drive different laboratories without per-lab integrations.
  • The paper's own examples suggest a testable extension: a PUDA simulator or digital twin could let agents practice error recovery before touching hardware, decoupling agent development from scarce laboratory time.
  • The safety model shifts risk onto the driver-review process; a practical corollary is that labs adopting PUDA need a governance procedure for reviewing and versioning driver code as rigorously as they review experimental protocols.
  • Because the paper reports no agent benchmark, a natural next step is measuring token efficiency and error-recovery success against GUI-based orchestration baselines to test the assumption that agents can actually operate this surface.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper introduces PUDA, a command-line runtime and data layer intended to let AI agents operate self-driving laboratories. The architecture separates an agent-facing CLI from hardware-facing edge services, uses NATS/JetStream for transport and durable messaging, validates JSON protocols before dispatch, and records protocol, run, sample, measurement, and command_log records in a local SQLite database. The authors explicitly state that PUDA is not an optimizer, orchestrator, or recipe language, but rather a stable, inspectable execution and provenance substrate. The central claims are that hardware execution remains deterministic, atomic, and auditable, and that the CLI enables agents to perform an OODA loop through progressive discovery. The paper provides no end-to-end experiments, agent benchmarks, error-recovery statistics, or performance measurements; the only deployment evidence is a single sentence in §4.4. The contribution is therefore a proposed system architecture with asserted, rather than demonstrated, practical properties.

Significance. If PUDA's claims were substantiated, the paper would offer a useful architectural template for agent-facing laboratory automation: separating scientific orchestration from physical actuation, exposing reviewed driver methods, and linking provenance from protocol through command response to data products. The paper is honest about its non-goals and places appropriate responsibilities on drivers, validators, and human review. It does not introduce a new optimization algorithm or a fitted model, so the usual concerns about circularity or overfitting do not apply. However, the paper's significance is currently limited by the absence of any evaluation: there is no benchmark, case study, deployment data, or reproducibility artifact. The central terms 'deterministic,' 'atomic,' and 'auditable' are used in a strong sense, but the manuscript does not give enough semantic or implementation detail to verify them. The paper is best read as a systems design position, and its value will depend on future evidence that the proposed runtime behaves as claimed under realistic concurrency, retry, and failure conditions.

major comments (3)
  1. [§2.4, §3.3, Abstract] The stress-test concern about concurrency is well founded and lands directly on the central claim. The paper says multiple agents and devices operate concurrently over NATS/JetStream, and that hardware execution is deterministic, atomic, and auditable. Yet it never specifies whether commands addressed to the same edge service are serialized (per-device queue, mutex, single consumer, or other mechanism), nor how JetStream's at-least-once delivery interacts with retries and timeouts. Without such semantics, two concurrent protocols can interleave physical actions, a timed-out command can be retried and double-executed (e.g., double-dispensing), and command_log order can diverge from the actual physical execution order. Auditability then records requests, not the true execution sequence. The paper should define the delivery and concurrency model, including idempotency and deduplication, and
  2. [§3, §4.4, §6] The paper's practical value rests on the premise that AI agents can operate a physical laboratory through a text CLI with progressive discovery and error recovery. This premise is asserted in §3 ('A CLI is compact, explicit, and naturally suited to agentic operations') but never tested. There is no agent benchmark, no end-to-end autonomy experiment, no error-recovery statistics, and no deployment details. The single sentence in §4.4 stating that PUDA 'has been deployed across multiple AI4Science laboratory contexts' is unverifiable and too vague to support the central claim. Moreover, §6 lists a simulator as future work, indicating that even simulated validation is absent. The authors should either provide concrete evaluation data (agent success rates, command failure/recovery traces, concurrency tests, or a documented production deployment) or explicitly reclassify the contribution as a
  3. [§2.1, §2.3] The definitions of 'atomic' and 'deterministic' are too weak to carry the paper's claims. §2.1 defines atomic only as 'each command asks the device to do one clearly defined thing.' This semantic definition does not guarantee that two commands are not interleaved, that a command's effects are all-or-nothing, or that a timeout does not leave the device in an ambiguous state. Similarly, §2.3 says drivers execute 'deterministic hardware operations,' but no mechanism is given to ensure deterministic behavior in the presence of hardware variability, concurrent calls, or retried messages. The authors should provide precise definitions and, ideally, the runtime mechanisms (e.g., per-device locks, idempotent command keys, and transactional command/response logging) that implement these properties. Without that, the abstract's conjunction 'deterministic, atomic, and auditable' is not supported.
minor comments (5)
  1. [§1, line 1] There are typographical defects such as 'withexplicitemphasis' and 'safety' in Section 1 near the FAIR discussion; please copyedit the manuscript.
  2. [§2.3] The claim that the command catalog is 'generated from the driver itself' should state the actual mechanism (reflection, annotations, a separate schema file, or code generation). This is needed for implementers and for assessing whether the catalog is always in sync with the executable driver.
  3. [§3.3] The relationship among the local SQLite database, the optional PostgreSQL logger, and NATS/JetStream retention is unclear. Which record is authoritative in the presence of partial logging failure? This matters for the auditability claim.
  4. [Listing 2] The 'puda login --username <username>' command implies an authentication model but no details are given. Specify whether there is a password, token, or external auth; otherwise the security discussion in §3.3 is incomplete.
  5. [§4.4] The sentence 'PUDA, so far, has been deployed across multiple AI4Science laboratory contexts' should either be replaced with a concrete, verifiable description of those deployments or removed. As written it is an unsupported assertion that does not help the reader evaluate the system.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: PUDA is an architecture/design paper with no fitted predictions or derived quantities; its claims are implementation claims, not reduction chains.

full rationale

The paper does not contain a derivation chain of the kind that can be circular. It fits no parameters, predicts no numerical outcome, and invokes no uniqueness or consistency theorem to force a conclusion. Its central claims — a headless CLI, NATS/JetStream transport, reviewed edge drivers, and SQLite provenance records — are architectural design statements about the PUDA runtime. The only passage that superficially resembles a definition-to-claim step is the definition of 'atomic' in §2.1 ('Here, atomic means that each command asks the device to do one clearly defined thing'), which later appears in the contributions list as an 'atomic hardware action.' However, the paper never uses that definition to derive the safety property; it asserts the design and argues that reviewed driver methods are the safety boundary. Whether concurrent or retried commands are actually serialized at the edge is an unverified engineering claim and a real correctness gap, but it is not circularity: the conclusion is not identical to the premise by construction. References [17] and [19] may include authors' own prior work and project documentation, but they are used for design context and pointers to the artifact, not as a self-referential proof that makes the central claim true by fiat. The assumption that LLM agents can operate the laboratory through a CLI is an external capability assumption, not an input that is renamed as a prediction. Accordingly, no specific circular step can be exhibited, and the honest finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

PUDA introduces no numeric free parameters in the analysis sense; the design choices (CLI, NATS, SQLite) are architectural commitments, not fitted values. It also introduces no new physical entities such as particles or forces. The four axioms above are domain assumptions about agent capability, driver safety, messaging reliability, and provenance adequacy that the central claim depends on but that are asserted rather than demonstrated.

assumptions (4)
  • domain assumption CLI-based progressive discovery is a practical and token-efficient interface for current AI agents operating physical labs.
    §3 asserts a CLI is 'compact, explicit, and naturally suited to agentic operations' and 'token-efficient for language models,' but no agent benchmark or end-to-end demonstration is provided.
  • domain assumption Reviewed driver methods and protocol validation make hardware execution deterministic and atomic at the boundary.
    §2.1 defines atomic as 'each command asks the device to do one clearly defined thing' and §3.2 states the safety boundary; this is a design assertion with no formal verification or empirical safety case.
  • domain assumption NATS/JetStream provides sufficiently reliable, durable, and timely transport for physical lab command dispatch and telemetry.
    §2.4 selects NATS/JetStream as the communication layer, but the paper gives no latency, durability, ordering, or failure-mode characterization relevant to physical control.
  • domain assumption SQLite tables with UUIDs and timestamps are sufficient to support FAIR provenance and auditability.
    §3.3 claims that UUIDs and timestamps make experimental history traceable and support FAIR objectives, but no FAIR evaluation or schema validation is given.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PUDA: An AI-Native Hardware Harness for Self-Driving Laboratories." pith.science (2026). https://pith.science/paper/H7ZLTUQB

@misc{pith2026260726464,
  author       = {Pith},
  title        = {Pith review of: PUDA: An AI-Native Hardware Harness for Self-Driving Laboratories},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/H7ZLTUQB}},
  note         = {Machine review of arXiv:2607.26464}
}
read the original abstract

Physical Unified Device Architecture (PUDA) is an AI-native hardware harness for self-driving laboratories (SDLs). Rather than building a human-centered graphical user interface (GUI) orchestration layer, PUDA creates a command-line runtime environment that lets agents observe, orient, decide, and act over experiments while hardware execution remains deterministic, atomic, and auditable. Headless by design, devices appear through discoverable command-line interfaces, JSON protocols are routed through a distributed messaging system, and command responses, data products, and reports are preserved as structured records. PUDA organizes protocols, runs, samples, measurements, and command logs into an AI-native data structure linked by run identifiers and timestamps, preserving provenance from submitted protocol through hardware response to resulting data products. PUDA separates scientific orchestration from physical operation and data telemetry: agents choose experiments, while PUDA executes validated commands and captures provenance-linked state, responses, and data. The contribution is not another optimizer, orchestrator, or recipe language. It is a practical execution and data environment for agentic SDLs; the broader physical AI implication is that PUDA provides an AI-native hardware harness for AI systems to interact with physical tools.

Figures

Figures reproduced from arXiv: 2607.26464 by the authors.

Figure 1
Figure 1. PUDA changes where orchestration lives. Human-first automation fixes workflows before a run; PUDA keeps the lab interface stable while an agent revises protocols between runs. More complex procedures are built by placing these small commands in sequence within a protocol. PUDA can therefore check and record each step separately, making it clear which action was requested, whether it completed, and where a failure oc… view at source ↗
Figure 2
Figure 2. PUDA separates the agent, command-line interface, distributed messaging layer, and edge services. Solid arrows show action flow from agent to hardware; dashed arrows show feedback returning as context for the next agent step [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Commands move from the CLI through NATS to an edge service, which invokes reviewed hardware operations. Telemetry returns through publish/subscribe for live observation, while JetStream retains selected events and data and KV exposes current machine state. 2.4 Edge Services and NATS Transport An edge service is the device-local bridge between NATS and a reviewed driver. It runs near the instrument, receives commands… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: CLI interaction as an agent loop: discover commands, inspect contracts, act, and use output or errors to revise the next call. 3.2 Safety Boundary and Recoverable Operation Recent work argues that self-driving laboratories need an autonomy safety harness connecting AI-…
Figure 5
Figure 5. Figure 5: PUDA’s safety boundary is conventional: agents compose named commands; validation checks protocol structure; predefined driver methods own hardware semantics. For provenance and security, PUDA keeps experimental records on premises. Each project uses a local SQLite dat…
Figure 6
Figure 6. Figure 6: PUDA closes the experimental loop without placing workflow logic in the driver: an agent composes the protocol, the CLI validates it, NATS dispatches commands, reviewed drivers execute the physical step, and structured data and provenance inform the next protocol. elec…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 9 canonical work pages

  1. [1]

    Self-driving laboratories for chemistry and materials science.Chemical Reviews, 2024

    Gary Tom et al. Self-driving laboratories for chemistry and materials science.Chemical Reviews, 2024. https://doi.org/10.1021/acs.chemrev.4c00055

    doi:10.1021/acs.chemrev.4c00055 2024

  2. [2]

    The rise of self-driving labs in chemical and materials sciences

    Milad Abolhasani and Eugenia Kumacheva. The rise of self-driving labs in chemical and materials sciences. Nature Synthesis, 2023.https://doi.org/10.1038/s44160-022-00231-0

    doi:10.1038/s44160-022-00231-0 2023

  3. [3]

    Roch, and Alán Aspuru-Guzik

    Florian Hase, Loic M. Roch, and Alán Aspuru-Guzik. Next-generation experimentation with self-driving laboratories.Trends in Chemistry, 2019.https://doi.org/10.1016/j.trechm.2019.02.007. 11

    work page doi:10.1016/j.trechm.2019.02.007 2019

  4. [4]

    A mobile robotic chemist.Nature, 2020.https://doi.org/10.1038/s41586-020-2 442-2

    Benjamin Burger et al. A mobile robotic chemist.Nature, 2020.https://doi.org/10.1038/s41586-020-2 442-2

    doi:10.1038/s41586-020-2 2020

  5. [5]

    MacLeod et al

    Benjamin P. MacLeod et al. Self-driving laboratory for accelerated discovery of thin-film materials.Science Advances, 2020.https://doi.org/10.1126/sciadv.aaz8867

    doi:10.1126/sciadv.aaz8867 2020

  6. [6]

    Szymanski et al

    Nathan J. Szymanski et al. An autonomous laboratory for the accelerated synthesis of novel materials.Nature, 2023.https://doi.org/10.1038/s41586-023-06734-w

    doi:10.1038/s41586-023-06734-w 2023

  7. [7]

    Autonomous platforms for data-driven organic synthesis.Nature Communications, 2024

    Chengzhi Dai et al. Autonomous platforms for data-driven organic synthesis.Nature Communications, 2024. https://doi.org/10.1038/s41467-024-46292-x

    work page doi:10.1038/s41467-024-46292-x 2024

  8. [8]

    Volk, Jalen S

    Austin A. Volk, Jalen S. Masters, and Milad Abolhasani. Performance metrics to unleash the power of self- driving labs in chemistry and materials science.Nature Communications, 2024.https://doi.org/10.1038/ s41467-024-45569-5

    2024

Show all 32 references
  1. [9]

    ChemOS 2.0: An orchestration architecture for chemical self-driving laboratories.Matter, 2024.https://doi.org/10.1016/j.matt.2024.04.021

    Malcolm Sim et al. ChemOS 2.0: An orchestration architecture for chemical self-driving laboratories.Matter, 2024.https://doi.org/10.1016/j.matt.2024.04.021

    2024 doi

  2. [10]

    Enabling modular autonomous feedback-loops in materials science through hi- erarchical experimental laboratory automation and orchestration.Advanced Materials Interfaces, 2022

    Fuzhan Rahmanian et al. Enabling modular autonomous feedback-loops in materials science through hi- erarchical experimental laboratory automation and orchestration.Advanced Materials Interfaces, 2022. https://doi.org/10.1002/admi.202101987

    2022 doi

  3. [11]

    AlabOS: A Python-based reconfigurable workflow management framework for autonomous laboratories.Digital Discovery, 2024.https://doi.org/10.1039/D4DD00129J

    Yuxing Fei et al. AlabOS: A Python-based reconfigurable workflow management framework for autonomous laboratories.Digital Discovery, 2024.https://doi.org/10.1039/D4DD00129J

    2024 doi

  4. [12]

    IvoryOS: An interoperable web interface for orchestrating Python-based self-driving lab workflows.Nature Communications, 2025.https://doi.org/10.1038/s41467-025-60514-w

    Wenyu Zhang et al. IvoryOS: An interoperable web interface for orchestrating Python-based self-driving lab workflows.Nature Communications, 2025.https://doi.org/10.1038/s41467-025-60514-w

    2025 doi

  5. [13]

    Daniel Allan et al. Bluesky’s ahead: a multi-facility collaboration for an a la carte software project for data acquisition and management.Synchrotron Radiation News, 2019.https://doi.org/10.1080/08940886.201 9.1608121

    2019 doi

  6. [14]

    Hessam M

    S. Hessam M. Mehr et al. A universal system for digitization and automatic execution of the chemical synthesis literature.Science, 2020.https://doi.org/10.1126/science.abc2986

    2020 doi

  7. [15]

    Ryo Tamura, Koji Tsuda, and Shoichi Matsuda. NIMS-OS: An automation software to implement a closed loop between artificial intelligence and robotic experiments in materials science.STAM Methods, 2023.https: //doi.org/10.1080/27660400.2023.2232297

    2023

  8. [16]

    Wilkinson et al

    Mark D. Wilkinson et al. The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3:160018, 2016.https://doi.org/10.1038/sdata.2016.18

    2016 doi

  9. [17]

    C. J. Leong et al. An object-oriented framework to enable workflow evolution across materials acceleration platforms.Matter, 5(10):3124–3134, 2022.https://doi.org/10.1016/j.matt.2022.08.017

    2022 doi

  10. [18]

    Model Context Protocol (MCP): Landscape, security threats, and future research directions

    Xinyi Hou et al. Model Context Protocol (MCP): Landscape, security threats, and future research directions. arXiv:2503.23278, 2025.https://arxiv.org/abs/2503.23278

    2025 arXiv

  11. [19]

    PUDA documentation and source repositories: architecture, CLI, communication, setup, under-the- hood execution flow, and runtime implementation

    PUDAP. PUDA documentation and source repositories: architecture, CLI, communication, setup, under-the- hood execution flow, and runtime implementation. 2026.https://docs.puda.co/docs/category/overview; source repositories:https://github.com/PUDAP/pudaandhttps://github.com/PUDA...

    2026

  12. [20]

    NATS documentation, JetStream concepts, and nats bench examples.https://docs.nat s.io/;https://docs.nats.io/using-nats/nats-tools/nats_cli/natsbench

    Synadia / CNCF. NATS documentation, JetStream concepts, and nats bench examples.https://docs.nat s.io/;https://docs.nats.io/using-nats/nats-tools/nats_cli/natsbench

  13. [21]

    SiLA 2 laboratory automation standard.https://sila-standard.com/

    SiLA Consortium. SiLA 2 laboratory automation standard.https://sila-standard.com/

  14. [22]

    OpenClaw agent framework documentation and source repository.https://docs.openclaw.ai/; source repository:https://github.com/openclaw/openclaw

    OpenClaw. OpenClaw agent framework documentation and source repository.https://docs.openclaw.ai/; source repository:https://github.com/openclaw/openclaw

  15. [23]

    Hermes Agent documentation and source repository.https://hermes-agent.nousresearc h.com/docs/; source repository:https://github.com/NousResearch/hermes-agent

    Nous Research. Hermes Agent documentation and source repository.https://hermes-agent.nousresearc h.com/docs/; source repository:https://github.com/NousResearch/hermes-agent. 12

  16. [24]

    Accelerating scientific discovery with Co-Scientist.Nature, 655:487–496, 2026.https: //doi.org/10.1038/s41586-026-10644-y

    Juraj Gottweis et al. Accelerating scientific discovery with Co-Scientist.Nature, 655:487–496, 2026.https: //doi.org/10.1038/s41586-026-10644-y

    2026 doi

  17. [25]

    Ghareeb et al

    Ali E. Ghareeb et al. A multi-agent system for automating scientific discovery.Nature, 655:497–505, 2026. https://doi.org/10.1038/s41586-026-10652-y

    2026 doi

  18. [26]

    Self-driving laboratories need an autonomy safety harness

    Linjiang Chen, Xiaobo Li, Quan Lin, and Jun Jiang. Self-driving laboratories need an autonomy safety harness. Nature Synthesis, 2026.https://doi.org/10.1038/s44160-026-01120-6

    2026 doi

  19. [27]

    HELIOS: Holistic Experiment Learning Intelligent Orchestration System

    Sissi Feng, Yuchen Han, and Yang Bai. HELIOS: Holistic Experiment Learning Intelligent Orchestration System. OpenReview, AI4X-AC 2026, 2026.https://openreview.net/forum?id=1kfeGE39Dj

    2026

  20. [28]

    La Agente Optima – orchestrated Bayesian optimization and active learning for accel- erated in-silico compound discovery

    Marcel Mueller et al. La Agente Optima – orchestrated Bayesian optimization and active learning for accel- erated in-silico compound discovery. OpenReview, AI4X-AC 2026, 2026.https://openreview.net/forum?i d=fVnYXtbkou

    2026

  21. [29]

    Boiko, Robert MacKnight, Ben Kline, and Gabe Gomes

    Daniil A. Boiko, Robert MacKnight, Ben Kline, and Gabe Gomes. Autonomous chemical research with large language models.Nature, 624(7992):570–578, 2023.https://doi.org/10.1038/s41586-023-06792-0

    2023 doi

  22. [30]

    Arthur W. N. Sloan et al. ARES OS 2.0: An orchestration software suite for autonomous experimentation systems and self-driving labs. arXiv:2604.03440, 2026.https://arxiv.org/abs/2604.03440

    2026 arXiv

  23. [31]

    Pendleton et al

    Ian M. Pendleton et al. Experiment Specification, Capture and Laboratory Automation Technology (ESCA- LATE): A software pipeline for automated chemical experimentation and data management.MRS Communi- cations, 9(3):846–859, 2019.https://doi.org/10.1557/mrc.2019.72

    2019 doi

  24. [32]

    MATTERIX: Toward a digital twin for robotics-assisted chemistry laboratory automa- tion.Nature Computational Science, 2026.https://doi.org/10.1038/s43588-025-00924-4

    Kourosh Darvish et al. MATTERIX: Toward a digital twin for robotics-assisted chemistry laboratory automa- tion.Nature Computational Science, 2026.https://doi.org/10.1038/s43588-025-00924-4. 13

    2026 doi

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.