Knowing what you want to measure is only the beginning of an experiment. Someone still has to find the right data, identify the controls, write the code, and check that the procedure makes sense.
At a particle accelerator, that preparation involves a machine shared by many people doing demanding science. A faster route from question to measurement is useful only if the people responsible for the facility can understand and control what happens along the way.
That is what interests me about the Accelerator Assistant at Lawrence Berkeley National Laboratory’s Advanced Light Source.
The ALS generates extremely bright light, including X-rays, for studying materials, biological systems, and chemical processes. Electrons circulate through a storage ring, and researchers use the resulting light at experimental stations called beamlines. The facility serves a broad scientific community. Keeping it useful means supporting both the experiments and the people who operate the machine.
The assistant gives accelerator physicists a way to describe a task in ordinary language. It can locate relevant machine signals, retrieve archived data, generate analysis code, and organize a procedure. Berkeley Lab describes a control system with more than 230,000 process variables, the signals and settings through which staff observe and control the facility. Finding the right ones is part of the work.
Consider the experiment in the research paper. A physicist asks the system to examine recent settings for adjustable magnet gaps, move those gaps through a specified range and back, measure the vertical beam size, and plot the relationship.
The request includes 30 sampling points and five repeated measurements per point. The assistant turns it into a sequence of data retrieval, code generation, controlled machine interaction, and analysis.
For this representative task, the authors report preparation shrinking from several hours of manual scripting and debugging to a few minutes. They describe the improvement as roughly two orders of magnitude. The physical measurement sequence still takes about an hour. This is a reported preparation-time comparison, not an independently measured hundredfold increase in research output.
The important handoff comes before the machine changes. In the ALS deployment described in the paper, all write access to the control system requires operator approval. Reading a stored measurement and changing a machine setting carry different responsibilities, and the implementation makes that distinction explicit.
Underneath the assistant is a framework called Osprey. It creates an inspectable plan before execution, selects the tools relevant to the task, and preserves records of the work. Its architecture supports checkpoints and human review. Those features make it possible to examine how a request becomes a sequence of actions. They do not establish that every generated plan is correct.
I find that division of responsibility more interesting than the speed figure.
The physicist still has to ask a useful question and specify the measurement. The operator still has authority over changes to the machine. The resulting plot still needs scientific interpretation. Software takes on some of the preparation and coordination that sits between those decisions.
That is a practical place to look for value. An expert’s time can disappear into the mechanics of getting a task ready, even when the scientific objective is already clear.
There are limits to what this example tells us. The paper, published January 16, 2026, demonstrates a workflow on an operating scientific facility. It does not give us a facility-wide estimate of downtime avoided, costs saved, or additional discoveries. Nor does one successful procedure tell us how reliably the system handles every unusual request.
The next questions are operational: how often do plans need correction, how much review do they require, and which tasks remain easier to do directly? Those measures would help distinguish a useful demonstration from a broadly dependable service.
For now, the contribution is concrete. A scientist can describe a demanding measurement, and software can help assemble the work needed to carry it out, with operator approval built into machine changes.
The opportunity is to make expert judgment easier to act on.
Subscribe to Where AI Actually Works for one carefully researched story each week about humans and AI solving real problems.
This article was researched and written in partnership with AI. Every load-bearing figure traced back to the primary source and verified by a human before publication. The judgment about what to include, and what to leave out, is my own. Writing a series about humans and machines working together, it would be a little strange to pretend otherwise.
Sources:
- Hellert and colleagues, Physical Review Research 8, L012017, published January 16, 2026. The primary research paper describes the Accelerator Assistant and the representative experiment. https://doi.org/10.1103/jtqy-9jz1
- Accessible author version, including the experiment and operator-approval details: https://arxiv.org/html/2509.17255v2
- Berkeley Lab’s account explains the operational setting and how the assistant connects requests, data, code, and machine controls.
https://atap.lbl.gov/news/agentic-ai-enables-advanced-light-source-experiments/ - The Osprey framework paper explains planning, tool selection, checkpoints, and records of execution. This is related technical work from the same research group, not independent validation. https://arxiv.org/abs/2508.15066
A distinction worth keeping: the reported speed improvement concerns preparing a representative experiment. The measurement itself still takes about an hour. It is not evidence of a hundredfold increase in scientific output.
Leave a Reply