Exploring the Genesis Platform Capabilities to Accelerate Scientific Discovery in OPAL Daniel Rosendo Frédéric Suter
Renan Souza Shelaine L. Curd
Kelsey Carter David Weston
John Lagergren Rafael Ferreira da Silva
arXiv:2609.08844v1 [cs.DC] 8 Sep 2026
Oak Ridge National Laboratory, Oak Ridge, TN, USA {rosendod, souzar, carterkr, lagergrenjh, suterf, curdsl, westondj, silvarf}@ornl.gov
Abstract—Autonomous, cross-facility science requires capabilities that no individual project should have to build for itself: managed execution for long-lived services, versioned distribution of models to remote compute systems, governed access to large language models, a shared substrate for experimental data, and end-to-end provenance. The U.S. Department of Energy Genesis Mission platform, delivered through the American Science Cloud, provides these as reusable services. This paper reports how the Genesis platform enables cross-facility experiments and accelerates scientific discovery. We explore the plant phenotyping workflow of the Orchestrated Platform for Autonomous Laboratories as the exemplar: it couples Oak Ridge National Laboratory’s Advanced Plant Phenotyping Laboratory with the Frontier supercomputer. In a 40-day nickel-treatment campaign, the resulting workflow replaced roughly twelve hours of manual analysis with interactive queries returning in seconds to minutes. Index Terms—Science platforms, cross-facility workflows, agentic workflows, provenance, model catalogs, plant phenotyping, high performance computing.
I. I NTRODUCTION Scientific workflows increasingly span facilities. An experiment begins at an instrument, its data are analyzed on a leadership-class supercomputer, and the results are interpreted through services running in the cloud [1], [2], [3]. Building such a workflow has historically meant assembling its supporting infrastructure from scratch: somewhere to run longlived services, a way to get a trained model onto the compute system, credentials and quota for language model access, a place to publish derived data, and some means of recording what happened. Each project solves these problems separately, and each solution is difficult to reuse. The U.S. Department of Energy (DOE) Genesis Mission addresses this by treating these concerns as platform capabilities. Delivered through the American Science Cloud Notice: This manuscript has been authored in part by UT-Battelle, LLC under Contract No. DE-AC05-00OR22725 with the U.S. Department of Energy. The United States Government retains and the publisher, by accepting the article for publication, acknowledges that the United States Government retains a non-exclusive, paid-up, irrevocable, world-wide license to publish or reproduce the published form of this manuscript, or allow others to do so, for United States Government purposes. The Department of Energy will provide public access to these results of federally sponsored research in accordance with the DOE Public Access Plan (http://energy.gov/downloads/doe-publicaccess-plan).
(AmSC), they are operated as shared services with stable interfaces, so that a project integrates against a capability rather than reimplementing it. This paper presents what that shift makes possible in practice. We report on five capabilities, namely a managed cloud Kubernetes execution environment, an MLflow model catalog, the Model Access Gateway (MAG) LLM inference service, a data lakehouse, and the Flowcept provenance service, and show that together they supply most of the non-domain-specific machinery a cross-facility agentic experiment requires. Our exemplar is the plant phenotyping workflow of the Orchestrated Platform for Autonomous Laboratories (OPAL). It is a demanding use case because it exercises every capability at once and spans three environments: Oak Ridge National Laboratory (ORNL)’s Advanced Plant Phenotyping Laboratory (APPL) acquires imagery continuously, the Frontier supercomputer performs Vision Transformer (ViT) inference and trait extraction, and AI agents hosted on the platform hold a natural language conversation with biologists. We stress at the outset that OPAL is a use case, not the contribution. The capabilities described here are domain-agnostic, and Section VI separates what OPAL inherited from the Genesis platform from what it had to build itself. Equally important is what the platform does not provide yet. Bulk data movement, secure cross-facility messaging, and agent hosting on HPC systems. This division is deliberate, and getting it right is part of the design: a platform that absorbs these would duplicate mature software and would have to follow each facility’s operational policy. Specifically, this paper makes the following contributions: 1) We characterize the requirements that cross-facility autonomous experiments impose on a science platform, and distinguish platform concerns from facility and domain concerns (Section II). 2) We describe five Genesis Platform capabilities and the interface each exposes to a use case (Section III). Additionally, we show how they compose with external services the platform does not subsume, and give the resulting division of responsibility. 3) We demonstrate the composition end to end through the OPAL workflows and a production deployment over a 40-
day campaign, reporting latency and provenance overhead (Sections IV and V). 4) We generalize from the OPAL integration, stating what new use cases inherit and what they must supply (Section VI). II. BACKGROUND AND R EQUIREMENTS The plant phenotyping use case. APPL is a DOE facility at ORNL that exploits natural genetic diversity to improve plant resilience. Its conveyor moves up to 520 trays along a 700-foot track through five aboveground imaging stations, operating 24 hours a day and imaging as many as 10,400 plants over a multi-week campaign across eight modality groups: RGB, hyperspectral, thermal, multispectral, chlorophyll fluorescence, 3D laser, and below-ground RGB and near-infrared. The facility generates on the order of hundreds of gigabytes per day. While acquisition is fully automated, converting imagery into biologically meaningful traits was not. In a representative 40-day campaign that step consumed roughly two hours of a scientist’s time per day across six days of analysis, and results arrived only after the campaign had ended. This is the phenotyping bottleneck [4] in modern form: the constraint has migrated from the instrument to the analyst. Why this is a platform problem. Closing that gap requires more than a better script. The trained segmentation model lives where it was trained but must execute on Frontier. Imagery must move from the greenhouse to an analysis server and then to the supercomputer’s file system. Derived traits must be published somewhere the interpretation layer can reach. A language model must be reachable under institutional policy. And because non-deterministic model participate in the analysis, the system must record what was asked, what was decided, what code ran, on which hardware, and over which inputs, in a form that can be queried after the fact. None of these are plant phenotyping problems. They recur in any workflow that couples an instrument, an HPC system, and an interpretation layer, which is precisely the argument for solving them once at the platform level. Requirements. From this we expose five requirements on a science platform. First, managed execution: use cases need somewhere to run long-lived, networked services without operating infrastructure themselves. Second, model portability: a model trained or registered in one environment must be retrievable, by version, from a compute system elsewhere. Third, governed model access: language model inference must be available through a single controlled endpoint rather than through per-project credentials. Fourth, a shared data substrate: experimental metadata and derived products must be publishable and queryable across facility boundaries. Fifth, provenance: agent decisions, model exchanges, and computational steps must be captured in a queryable form. Two further requirements, namely bulk data movement and secure crossfacility messaging, are real but are met by external services rather than by the platform itself.
III. G ENESIS P LATFORM & FACILITY- OPERATED C APABILITIES E XPLORED IN OPAL Table I shows the division of service responsibility across a typical OPAL workflow while Fig. 1 shows the composition of these services. The shape of the workflow derives from the capabilities. Globus moves imagery data from the greenhouse to the APPL analysis server, where it is preprocessed into AIready arrays, and then to Frontier’s Orion file system. On Frontier, a compute agent hosted by Academy dispatches vision transformer inference through Parsl, retrieving the model from the platform’s MLflow catalog when no local checkpoint is present. Derived products are published to the data lakehouse. On the platform side, a conversational agent runs in the cloud Kubernetes cluster, queries the lakehouse, and reaches language models through MAG. The two agents exchange control messages over the S3M Redis service. Throughout, Flowcept records what happened. TABLE I: Division of responsibility across the workflow Genesis platform capabilities Cloud Kubernetes Hosts the OPAL chat UI and the Co-Scientist cluster agent Model catalog MLflow; stores versioned ViT weights, pulled by the compute agent on Frontier MAG LiteLLM Model Access Gateway; serves all LLM inference for the agent Data lakehouse Stores experiment metadata and AI-ready data: thumbnails, masks, feature files Flowcept Captures and serves provenance across both facilities External services and frameworks Globus Moves imagery greenhouse → analysis server → Frontier S3M Redis Secure cross-facility agent-to-agent messaging Academy Deploys agents across federated resources (e.g., Kubernetes cluster and Frontier) Parsl Scales ViT inference across Frontier GPUs Supplied by the use case OPAL components APPL analysis server, Co-Scientist agent, compute agent logic, ViT model, trait extraction
A. Genesis Platform Capabilities Managed execution environment. The platform operates a cloud-hosted Kubernetes cluster on which use cases deploy their services. OPAL runs its conversational agent there. The Genesis platform added value is not that Kubernetes is novel but that the cluster is operated, authenticated, and networkconnected by the platform: a use case obtains a place for long-lived, externally reachable services without negotiating hosting, and services deployed there sit inside the same trust boundary as the other capabilities, so reaching the model catalog, gateway, or data lakehouse does not require separate credentials for each. Model catalog. The catalog is an MLflow deployment that holds versioned model artifacts. Its role is to decouple where a model is produced from where it executes. OPAL uploads its fine-tuned vision transformer weights to the catalog; when
Plant biologist
ORNL’s APPL
Genesis Platform
OLCF Frontier
Greenhouse (imaging)
Chat UI
S3M Redis
EKS cluster
Co-Scientist Agent (Academy)
Globus
Compute Agent (Academy)
ViT inference (GPU nodes)
Parsl
Analysis Server ViT checkpoint
Data lakehouse
MAG LLM inference
Model catalog
Orion file system
Globus transfer: AI-ready arrays
Flowcept provenance service — agent decisions, dialog interactions, LLM exchanges, data products, and HPC job metadata
Fig. 1: The OPAL workflow composed from Genesis platform capabilities and external services. The biologist interacts with OPAL through the chat UI, which serves as the human-facing entry point to the Co-Scientist Agent. Blue boxes are Genesis platform capabilities; white boxes with dashed borders are external services the platform does not subsume; amber boxes with thick borders are OPAL use case components. Only the amber boxes are specific to plant phenotyping.
the compute agent runs on Frontier it first looks for a local checkpoint and, finding none, downloads the model from the catalog. This cache-with-fallback pattern is worth noting because it is the common case for HPC inference: the catalog is consulted rarely, on a cold node or after a model update, while steady-state execution reads from the file system. It also makes the model version an explicit, recorded property of a run rather than an implicit property of whatever file happened to be on disk, which is what allows provenance to answer which weights produced a given result. Model Access Gateway. MAG [5] is a LiteLLM-based inference service that exposes language models through a single endpoint. The OPAL Co-Scientist agent performs all of its inference through it, whether classifying intent, generating analysis code, or writing a report. The gateway centralizes credentials and quota, lets the underlying model be changed without touching agent code, and provides one place where prompts and responses can be observed for provenance. That last property matters more than it first appears: because every model invocation crosses a single boundary, provenance coverage of the reasoning layer is a property of the architecture rather than of programmer discipline. Data lakehouse. The lakehouse is the shared substrate between the facility side and the interpretation side of the workflow. OPAL uploads experiment metadata together with AIready data, including plant thumbnails, segmentation masks, and feature files, and the Co-Scientist agent queries it. This is what allows the conversational layer to be hosted on the platform while the data are produced on a supercomputer: publication to the lakehouse is the interface between them, so the agent does not need an account, a file system mount, or a scheduler allocation on Frontier in order to answer a question about the experiment. Provenance service. Flowcept [6] captures fine-grained provenance across distributed components and curates it into a
graph aligned with the W3C PROV model [7] and its agentic extension [8]. It records agent decisions, dialog interactions, LLM exchanges, generated code and its execution outcome, data transformations, and HPC job metadata including node and GPU allocation and queue wait. Because the records are aligned to one model, agentic and conventional steps compose into a single queryable graph spanning both facilities, and because they persist independently of any model’s context window, they provide a definitive history rather than a recollection. Users query this history in natural language through a provenance agent that translates questions into queries over the records and summarizes the results, an approach evaluated in prior work [9]. Flowcept is used by OPAL today and is being integrated as the provenance service for the Genesis platform, so that provenance becomes a property use cases inherit rather than one each must deploy for itself. B. Facility-operated Capabilities S3M Redis for cross-facility messaging. Agents deployed on the Genesis platform Kubernetes cluster and on Frontier cannot interact directly. The Secure Scientific Service Mesh (S3M) [10] provides a token-authenticated Redis service spanning ORNL’s administrative and network boundaries, which both sides reach outbound, so neither facility exposes a new inbound service. This is necessarily a facility-operated capability. It derives its security posture from the facility whose perimeter it crosses, and a platform-operated substitute would have to re-establish that posture from outside. Globus Transfer for data movement. Globus [11] moves imagery data from the APPL greenhouse to the APPL analysis server and from there to Frontier. Bulk transfer between facility endpoints is a solved problem with mature, widely deployed tooling and facility-specific endpoint configuration; a platform that reimplemented it would duplicate that software and inherit the obligation to track every facility’s transfer
policy. The platform’s concern begins once data are ready to be published, which is where the lakehouse takes over. C. DOE Community Software Academy for remote agent deployment. The compute agent runs on a Frontier login node under Academy [12], a framework for deploying agents across federated research infrastructure. Its actor model, in which agents encapsulate local state and coordinate by message passing, fits a topology in which the APPL Co-Scientist agent runs in the Genesis Platform Kubernetes cluster and the Compute agent on Frontier, and its exchange abstraction let us adopt S3M Redis service as the transport without changing agent code. Frameworks designed for cloud-hosted assistants generally assume a central orchestrator and a cloud-bound message bus, neither of which holds here. No single orchestrator can span both facilities. Parsl for scaling on HPC. Heavy computation is isolated into functions annotated as Parsl apps [13], which separates interactive agent code from batch execution and delegates scheduler interaction. Two main properties of Parsl fit this setting. First, its task graph is constructed at runtime and returns futures, which suits work whose extent is not known until a plan is confirmed, since the plants, images, and modalities named there determine how many inferences are issued, and which lets the agent remain responsive while they run. And its blockbased provisioning packs the many short inference tasks of a targeted job into a single allocation, which matters because cold path latency is dominated by queue wait rather than by inference (Section V). Second, its executor configuration further isolates what is machine specific, so targeting a system other than Frontier is a change of configuration rather than of agent code. The resulting principle is that the Genesis platform supplies what is common across use cases and stable across facilities, while facilityoperated and DOE community software supplies what is specific to a machine, a perimeter, or a scheduler. Where the two meet, the interface is a published artifact: a model version in the catalog, a dataset in the lakehouse, a message on the exchange, a provenance record.
IV. T HE OPAL W ORKFLOWS OPAL contributes three components of its own: a conversational Co-Scientist agent, the logic of a compute agent, and the domain models and algorithms, namely the fine-tuned vision transformer and the trait extraction routines. These are composed into two main workflows (offline and online), shown in Fig. 2, which meet at the data lakehouse. Offline workflow. Every hour, newly captured images are preprocessed on the APPL analysis server into AI-ready arrays and transferred by Globus to Frontier. A job runs segmentation inference over the new arrays, using a checkpoint pulled from the model catalog if none is cached locally, and trait extraction combines images and masks into per-plant trait profiles. Across a full campaign this amounts to roughly 2,000 inferences per day and hundreds of terabytes of masks, traits, and metadata retained on the parallel file system. Derived
products, namely thumbnails, masks, feature files, and harmonized experiment metadata, are published to the lakehouse. The purpose of this pipeline is to make the common case fast: by the time a scientist asks about yesterday’s imagery, the traits exist. Online workflow. The Co-Scientist agent classifies each message in three stages. An explicit prefix allows the agent to select a mode directly. Otherwise, it applies deterministic keyword rules and only if both fail, it consults a model through the Genesis platform’s MAG. The chat interface exposes four modes: 1) Greetings return in under a second with zero or one model calls; 2) Knowledge base questions retrieve from a curated index of prior findings and synthesize a cited answer in two calls; 3) Tabular and plot queries translate a question into executable code against lakehouse data, taking two to four calls and three to ten seconds, and 4) Plan mode conducts a dialogue and executes on HPC. Answering from published data. The tabular and plot modes generate code against harmonized feature data. The prompt is enriched with a schema, experiment-specific facts, and trait synonyms, because biologists would reasonably write “greenness” rather than “normalized ratio of color channel medians”. Generated code runs in a constrained environment, and failures enter a repair loop in which the error and offending code are returned to the model for correction. A validation stage then checks that genotype names resolve to real accessions and that rankings are well formed, with failures triggering the same repair path. The executed code is returned alongside the answer, so the analysis can be inspected and reproduced. Plan path and availability check. Questions that cannot be answered from published data enter the plan path. The agent conducts a requirements dialogue until the plan is complete and asks for confirmation, which keeps a human in the loop. On confirmation the plan crosses S3M Redis to the compute agent, which resolves the plants and images involved and checks whether the required masks exist. When they do, which is the common case, analysis proceeds immediately; when they do not, on-demand inference is scheduled for a targeted subset. Results are persisted, so the next request for the same traits finds them published. Report validation. A generated report is an interpretation, and the system provides a way to check it against the execution record rather than against the model’s recollection. When a scientist asks for a report to be validated, the agent retrieves the provenance card for the workflow that produced it and asks the model to assess whether the conclusions are supported by the recorded inputs, parameters, and outputs. Because the card is assembled from provenance rather than conversation history, the check is grounded in what actually executed. It does not remove the need for domain review, and a model critiquing output from the same model has well-understood blind spots; what it does is convert an unverifiable narrative into one whose claims can be traced to specific execution steps.
Scientist
APPL
Compute Agent
Co-Scientist
Frontier Compute node
Offline workflow — hourly, 24/7 capture and preprocess Globus: AI-ready arrays
publish to lakehouse
pull ViT from catalog, infer, extract traits
Online workflow — lakehouse query, seconds question classify via MAG, generate and run code table / chart / insight Online workflow — plan path, minutes confirmed plan run plan (S3M Redis) only if masks absent ranked plants, figures report + provenance link
Fig. 2: Simplified sequence diagram of the OPAL workflows. The offline pipeline keeps the lakehouse current; most questions are then answered from it in seconds, and only confirmed plans requiring missing masks reach the GPU inference stage.
V. D EPLOYMENT AND E VALUATION
Rank Plant ID Genotype
A. Setup We report on a production deployment supporting a 40day APPL campaign studying genotypic variation in response to nickel treatment, a question relevant to DOE interests in critical minerals and in plant resilience on marginal soils. The chat interface and the Co-Scientist agent ran in the Genesis platform’s Kubernetes cluster, reaching MAG for inference and the lakehouse for data. The compute agent ran on a Frontier login node under Academy, with Parsl dispatching inference to GPU nodes and model weights pulled from the MLflow catalog on cache miss. Globus moved imagery in two hops from the greenhouse to Frontier, and the S3M Redis service carried agent control messages. Trait extraction covered the RGB, infrared, and fluorescence modalities. Flowcept captured provenance throughout. B. A Representative Session The following exchanges illustrate the interaction styles the system supports, including experimental steering. They are representative of production sessions rather than a verbatim transcript of a single one. Questions requiring computation over imagery enter the plan path, where the agent first establishes what is being asked before consuming HPC resources. Biologist: From April 8, 2026 to May 2, 2026, what are the 5 plants with greatest leaf area?
Co-Scientist: Top-5 plants by leaf area (rgb2_area_mm2).
1 2 3 4 5
29038 28891 29079 29073 29041
9 RIL 407 Ecm29 ISU 210 RIL 407
Ni treatment Leaf area (mg kg−1 ) (mm2 ) 200 50 0 500 0
110.23 109.48 108.26 108.21 107.22
Biological interpretation • Leaf area is the primary “nickel tolerance” trait defined for this experiment (maintaining leaf area under high Ni stress). • The highest-area plant (29038, genotype 9) achieves approximately 110 mm2 at 200 mg Ni kg−1 , well above the control plants, indicating strong tolerance to moderate Ni levels. 2 • ISU 210 (plant 29073) retains a large leaf area (108 mm ) even at the highest tested dose (500 mg Ni kg−1 ), suggesting it may be the most Ni-resilient accession among the five. • RIL 407 shows the second-largest area but only at low-tomoderate Ni (0 and 50 mg kg−1 ); its performance at higher Ni is unknown and should be examined. • Ecm29 performs best at the control but lacks data at higher Ni, so its tolerance cannot be judged from this snapshot. Overall, data point to genotypes 9 and ISU 210 as promising candidates for breeding or further screening for Ni-rich soils, while RIL 407 warrants additional testing at higher concentrations.
Biologist: Now it’s end of business on May 3, 2026. Focus only on today’s measurements and on plants with leaf area greater than 40mm2. Then, for each plant, compare each measurement to the previous measurement on the same day. Keep only plants with at least one drop greater than 30% on the day. Finally, make a line plot of leaf area over time, one line per plant. Exclude QC-failed.
Co-Scientist:
Co-Scientist: The query asks for the phenotypes of the best plants selected in the last analysis run. The sample result shows BESC-856 as the phenotype. Biologist: Generate the provenance card. Co-Scientist: Provenance Card Summary • •
Campaign ID: 9178e5ed-8daf-d4b1487d1c4a Type: Pipeline, Workflow runs: 2, Total Elapsed (s): 157.982
Campaign-level Summary The May 3 plot reveals a systematic mid-day leaf-area collapse of greater than 30% in five plants, most plausibly caused by a temporary watering failure. This procedural stress overrides any Ni-tolerance signal, so the affected plants should be monitored, the watering system checked, and the experiment repeated under confirmed proper irrigation before using these data for genotype selection.
OPAL agents identified a sudden greater than 30% decrease in plant area and suggested that scientists check water status. After APPL technicians applied the intervention, OPAL agents confirmed plant recovery after rewatering.
• • •
– run_analysis_plan: 7.895s, trait_extraction: 2.054s – dialog_interaction: 1.705s, run_segmentation: 1.071s
Workflow Structure input→dialog_interaction→run_analysis_plan →run_segmentation→trait_extraction→output
Per-workflow Details Compute Agent Workflow • Workflow ID: d0d615f7-b457-8502, Elapsed: 7.895 s • Used: – metadata_file: /lustre/orion/.../metadata_file.csv – model: backbone: vit_small_patch8_224 checkpoint_path: /lustre/orion/... device: cuda id: opal_vit_small_patch8_224 model_type: vit repository: https://code.ornl.gov/opal/ai sha: 1d1cff06d84973c48e4d859932ac174 tile_size: 448 trained_on: Frontier training_date: 2025-08-16
Biologist: Now it’s 11:15am on May 4th, 2026. Yesterday we found that the plants 28801, 28976, 29019, 29070, and 29097 got strong declines in their leaf area caused by bad watering. We watered them as soon as we found this out. Please check their leaf area now. Plot a line plot from yesterday to now with the leaf area of these plants.
Co-Scientist:
Total Workflows: 2, Total Activities: 4, Total Tasks: 24 Status Counts: {’FINISHED’: 24}, Total Elapsed (s): 157.982 Top Slowest Activities:
•
trait extraction package: modified_on: 2026-02-03T21:02:03 repository: https://code.ornl.gov/opal/ai sha: 1d1cff06d84973c48e4d859932ac174
Per-activity Details Compute Agent Workflow run_analysis_plan • Used: – experiment_id: 41, modality: RGB1 – performance.formula: 1.0*height_mm – plants.selection: top_and_worst
The plot confirms that the abrupt leaf-area drops on May 3 were caused by the watering failure, and that four of the five plants have already recovered by now, while plant 28801 continues to decline and should be watched closely.
•
– best_plants: [21982] – generated_masks_paths: ["41__21982__1966.0_mok.npy", ...] – selected_plant_ids: [21982, 21981] – worst_plants: [21981] •
Because every step was recorded, the scientist can interrogate how a result was produced, across both the platform and facility sides of the workflow. Biologist: What are the phenotypes of the best plants selected in the last analysis run?
Generated:
Hosts (tasks per host): – 05.frontier.olcf.ornl.gov: 1 task
run_segmentation (n=15) • Used (aggregated): – image_path: type=scalar/categorical; top values=. . . (×15) •
Generated (aggregated):
•
Hosts (tasks per host):
– mask_path: type=scalar/categorical; top values=. . . (×15) – 05.frontier.olcf.ornl.gov: 15 tasks
TABLE II: Measured end-to-end latency by interaction class. Interaction Greeting / routing only Knowledge base question Query against lakehouse data Plan, masks already available Plan, on-demand inference (8 plants) Plan, on-demand inference, contended queue Provenance query
End-to-end latency <1 s 2–5 s 3–10 s <1 min ≈5 min 30 min–2 h 3–10 s
C. Performance Table II shows the end-to-end latency by interaction class. Two results are worth drawing out. First, the separation between the published and cold paths is large but the published path dominates in practice: because the offline pipeline runs hourly, a scientist asking about recent imagery normally finds the data already in the lakehouse, and the cold path is reached mainly for newly requested modalities or for plants imaged within the last hour. Second, cold path cost is dominated by scheduling rather than by inference. An individual inference takes on the order of ten seconds, and a targeted job of roughly a hundred inferences completes in minutes when GPUs are available; the variance comes from batch queue wait, which in the worst case we observed extends a cold query to tens of minutes or more. This is a property of sharing a leadershipclass machine, and it is the main argument for the offline pipeline: the system is fast because it does most of the work before the question is asked. Provenance overhead. Capturing provenance at the granularity described in Section III, covering every agent decision, dialog interaction, model exchange, code execution, and HPC job, added under 1% to end-to-end runtime. At this granularity and scale, this means that there is no need to trade auditability against performance. Provenance capture can be a default property of the platform rather than a debugging mode enabled after something has gone wrong. Comparison with the manual baseline. The campaign screened 360 pennycress plants for mineral uptake under nickel treatment. The workflow this system replaced consumed roughly two hours of a scientist’s time per day across six days of analysis, some twelve hours for the campaign, and it produced a hand-selected subset of traits only after the campaign had concluded. The agentic workflow extracts the full trait panel for every plant at every imaging round and completes within minutes of image acquisition. Measured against that baseline, the system yields on the order of 100× more traits per run and reduces analysis time by roughly 600×. The change in kind matters more than either figure. As answers now arrive while the experiment is still running, scientists can adjust the experiment in response to what the most recent data show. Participating biologists project that the agentic system will at least double their productivity on analysis-bound campaigns.
D. Limitations and Failure Modes Because the workflow spans a cloud platform, DOE facilities, and external services, its failure modes are distributed, and how it degrades matters as much as how it performs. The behavior is deliberately asymmetric. Failures in the interpretation layer are recoverable and visible. When generated analysis code fails to execute, the repair loop retries, and if the retry also fails the error and the generated code are returned to the scientist rather than silently swallowed. Failures that cross into HPC are reported with a provenance link, so a scientist can see how far a plan progressed before it stopped. Failures of the provenance service itself are the least graceful. A provenance question simply cannot be answered while the service is unavailable, which is an argument for treating provenance as platform infrastructure with a corresponding availability target rather than as a per-project addition. All model inference crosses MAG, so an outage of the gateway suspends the conversational layer. The offline pipeline involves no language model and continues unaffected, so the system degrades to a data-producing pipeline rather than failing outright. Similarly, the availability check depends on data published to the lakehouse: if publication lags, questions that would have been answered in seconds fall back to the cold path and take minutes. VI. G ENERALIZING TO OTHER U SE C ASES The point of describing OPAL in this detail is to make visible how little of it is about plants. Of the components in Fig. 1, only the thick-bordered boxes are use case specific: a conversational agent, the compute agent logic, the APPL analysis server, and the domain model and trait algorithms. Everything else was inherited. A use case adopting these capabilities inherits a place to run services, a versioned path for getting models onto remote compute, a governed inference endpoint, a substrate for publishing derived data, and provenance. It must supply three things. The first is a domain model and the code that derives quantities of interest from raw instrument data; in OPAL this is the segmentation transformer and trait extraction, and it is irreducibly domain specific. The second is a schema and vocabulary for its data, since the lakehouse stores what it is given and the agent’s ability to generate correct analysis code rests on knowing what the columns mean; the trait synonyms in Section IV are an instance of this. The third is the decision logic of its agents, namely what constitutes a complete analysis plan in the domain and when a computation is worth its cost. Two structural patterns transfer with the capabilities and are, in our experience, where most of the engineering benefit lies. One is the availability check: a use case that publishes derived products to the lakehouse can serve most requests from them and fall back to computation only when necessary, which is what produces the latency distribution in Table II. The other is cache-with-fallback model retrieval: consulting the catalog only on a cold node keeps the steady-state path local while making the model version an explicit property of each run.
VII. R ELATED W ORK Several projects treat shared infrastructure as the unit of reuse for cross-facility science. The Superfacility model [3] and work on cross-facility workflows [2], [14] establish the operational patterns for coupling instruments with HPC, and INTERSECT [15] pursues an ecosystem of loosely coupled facility services. Work on secure programmatic facility access [10], [16] provides the substrate that makes cloud-toHPC interaction tractable. Our contribution is complementary: rather than a facility integration framework, we report on a set of platform-operated capabilities and what a use case does and does not have to build on top of them. Among systems that place language model assistants in front of facilities, VISION [17] assembles models into taskspecific cognitive blocks for operating synchrotron beamlines, and CALMS [18] combines models with semantic search and tool execution to assist with experimental design and instrument operation, demonstrating that retrieval grounding materially reduces hallucination. Both target instrument operation; our use case begins after acquisition, where the bottleneck is interpretation, which shifts the emphasis toward HPC-scale analysis and its provenance. Our earlier work applied an agentic architecture to autonomous additive manufacturing at ORNL [19]; the present work differs in framing the reusable substrate as platform capabilities rather than as a per-project architecture. VIII. C ONCLUSION AND F UTURE W ORK We reported on five Genesis platform capabilities and showed how they enable a cross-facility autonomous experiment. The demonstration is the OPAL plant phenotyping workflow, which couples ORNL’s APPL facility with the Frontier supercomputer and lets biologists ask questions in natural language while a campaign is still running. We showed how the platform composes with external services it deliberately does not subsume and separated what the use case inherited from what it had to build: only the APPL analysis server, the conversational agent, the compute agent logic, and the domain model and trait algorithms were specific to plant science. In a 40-day nickel-treatment campaign the resulting workflow replaced roughly twelve hours of manual analysis with interactive queries returning in seconds to minutes, at under 1% provenance overhead. Two main directions follow. The first is completing the platform integration of the two capabilities that are still maturing. Flowcept is to become the Genesis platform provenance service, so that provenance is inherited by every use case rather than instrumented per project, with the resulting corpus curated as audit-grade training data for multimodal biology foundation models. The data lakehouse is in progress, and will require integration with the Genesis platform before other use cases can adopt it on the same terms that OPAL does today. The second is validating the capability boundaries against use cases with different shapes, particularly ones whose instrument produces streaming rather than batch data, and against deployments spanning multiple DOE laboratories.
ACKNOWLEDGMENT This material by the Orchestrated Platform for Autonomous Laboratories (OPAL) is based upon work supported by the U.S. Department of Energy, Office of Science, through the Office of Biological and Environmental Research Program, under contracts DE-AC02-06CH11357 (ANL); DE-AC0205CH11231 (LBNL); DE-AC05-00OR22725 (ORNL); and DE-AC05-76RL01830 (PNNL).This work supported by the U.S. Department of Energy, Office of Science, Office of Biological and Environmental Research under Award Number DE-SC-ERKPA89. This research used resources of the OLCF and the Advanced Plant Phenotyping Laboratory at ORNL, supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC05-00OR22725. R EFERENCES [1] R. Ferreira da Silva et al., “A grassroots network and community roadmap for interconnected autonomous science laboratories for accelerated discovery,” in Int. Conf. Parallel Processing Companion, 2025. [2] K. B. Antypas et al., “Enabling discovery data science through crossfacility workflows,” in IEEE Int. Conf. Big Data, 2021. [3] B. Enders et al., “Cross-facility science with the Superfacility Project at LBNL,” in IEEE/ACM Workshop on Extreme-scale Experiment-in-theLoop Computing (XLOOP), 2020. [4] R. T. Furbank and M. Tester, “Phenomics—technologies to relieve the phenotyping bottleneck,” Trends in Plant Science, vol. 16, no. 12, pp. 635–644, 2011. [5] American Science Cloud, “Model Access Gateway documentation,” [Online]. Available: https://amsc-docs-d762d2.gitlab.io/ model-access-gateway/, 2026, accessed: Aug. 14, 2026. [6] R. Souza et al., “Towards lightweight data integration using multiworkflow provenance and data observability,” in IEEE Int. Conf. eScience, 2023. [7] L. Moreau and P. Missier, “PROV-DM: The PROV data model,” W3C, W3C Recommendation, 2013. [8] R. Souza et al., “PROV-AGENT: unified provenance for tracking AI agent interactions in agentic workflows,” in IEEE Int. Conf. eScience, 2025, pp. 467–473. [9] ——, “LLM agents for interactive workflow provenance: reference architecture and evaluation methodology,” in Workshop on Workflows in Support of Large-Scale Science (WORKS), 2025. [10] T. J. Skluzacek et al., “Secure API-driven research automation to accelerate scientific discovery,” in Practice and Experience in Advanced Research Computing (PEARC), 2025. [11] K. Chard, S. Tuecke, and I. Foster, “Globus: recent enhancements and future plans,” in Extreme Science and Engineering Discovery Environment (XSEDE), 2016. [12] J. G. Pauloski et al., “Empowering scientific workflows with federated agents,” arXiv:2505.05428, 2025. [13] Y. Babuji et al., “Parsl: pervasive parallel programming in Python,” in ACM Int. Symp. High-Performance Parallel and Distributed Computing (HPDC), 2019. [14] N. Tyler et al., “Cross-facility workflows: case studies with active experiments,” in IEEE/ACM Workshop on Workflows in Support of Large-Scale Science (WORKS), 2022. [15] A. Malviya Thakur et al., “Towards a software development framework for interconnected science ecosystems,” in Smoky Mountains Computational Sciences and Engineering Conf. (SMC), 2023. [16] B. D. Etz et al., “Enabling seamless transitions from experimental to production HPC for interactive workflows,” arXiv:2506.01744, 2025. [17] S. Mathur et al., “VISION: a modular AI assistant for natural humaninstrument interaction at scientific user facilities,” Machine Learning: Science and Technology, 2025. [18] M. H. Prince et al., “Opportunities for retrieval and tool augmented large language models in scientific facilities,” npj Computational Materials, 2024. [19] D. Rosendo et al., “AI agents for enabling autonomous experiments at ORNL’s HPC and manufacturing user facilities,” in SC Workshops, 2025, pp. 2354–2361.