Scientific progress is often described through ideas: a new theory, a clever experiment, a surprising observation, a result that changes how we understand the world. That description is true, but from inside an experimental laboratory, research also has another face. It is operational. It is a long sequence of decisions, adjustments, measurements, failures, notes, scripts, calibrations, discussions, and attempts to understand what actually happened.
In that sense, research is a feedback loop. We form a hypothesis, design an experiment, build or modify an apparatus, collect data, analyze the result, and decide what to try next. Every iteration teaches us something. The faster and cleaner this loop runs, the faster research can move.
After several years working in university AMO physics laboratories, especially around quantum optics, I have become convinced that this loop is much slower than it needs to be. This is not because researchers are not working hard. If anything, it is the opposite. Experimental researchers spend enormous effort overcoming friction that is not fundamentally scientific.
Laboratories forget too much
Laboratory memory looks solid from the outside. There are notebooks, saved data, protocols, code, and folders full of traces and plots. But in practice, a lab remembers only what someone had the time and foresight to record. A real experiment contains far more context than formal notes can usually hold: a small alignment change, an instrument state, a calibration choice, a failed parameter range, a temporary workaround, or the reason one signal was trusted and another ignored. These details feel ordinary while the work is happening, but later they often become exactly the missing pieces.
A measurement is therefore more than the data file it leaves behind. It is a moment in a physical system, shaped by hardware, software, timing, environment, and human judgment. When that surrounding context is thin, the result becomes harder to interpret after time has passed. The lab may still have the number, the plot, or the note, but not the full chain of conditions that made the result meaningful. The computational part of the same measurement has the same structure: raw data, parameters, software versions, and processing steps need to remain connected if the result is going to be understood later[1].
Even when information is recorded, it is often scattered. Part of the story may be in a paper notebook, another part in electronic notes, another in a folder of data files, another in analysis scripts, and another in messages or informal conversations. Each fragment may be useful, but the fragments rarely meet in one place. The result is a strange kind of forgetting: the lab may possess the information, yet still fail to find it when it matters.
The loss becomes clearest when people leave. A student or postdoc often carries a quiet map of a setup: what tends to drift, which signal is suspicious, which adjustment is delicate, which old dataset is reliable, and which detail in the notes should be treated with care. Only part of that map is written down. When the person moves on, the laboratory loses more than a pair of hands. It loses a layer of accumulated experience.
This is how laboratories repeat themselves without noticing. They may revisit a measurement already tried, rediscover a failure mode already understood, or spend days reconstructing the logic behind an old result. The work was not necessarily lost, but it was not available at the moment of need. In a process driven by repeated learning, that kind of forgetting quietly slows everything down. The same fragility appears beyond one lab: research data availability has been shown to decline quickly with article age when preservation depends on individual researchers[2].
Knowledge transfer is inefficient
Knowledge in a lab is not only stored in documents. It is stored in people. A researcher who has lived with an experiment for a long time often carries a structured understanding of the system: how the apparatus behaves, which assumptions are safe, where the data can mislead, and how different pieces of the workflow fit together. This understanding may be clear inside one person's mind, but it does not automatically become clear to everyone else. The general point is old but still central: some useful knowledge is tacit, and experimental reproduction can fail when that tacit know-how does not travel[3][4]. Laboratory knowledge often behaves like craft knowledge: it is learned through practice and only partly captured by formal instruction[5].
The difficulty is not usually a lack of willingness. Researchers often help each other generously when a specific question appears. Someone can explain a procedure, debug a script, or point to an old dataset. But this kind of transfer is local and reactive. It answers the question that was asked, while the deeper structure behind the answer remains hard to pass on. A new member may collect many useful fragments and still lack the map that makes those fragments coherent.
This is closely tied to the weakness of laboratory memory. When context is scattered or missing, knowledge transfer depends more heavily on personal memory and repeated conversation. The same explanation must be given again, the same background must be reconstructed again, and the same hidden assumptions must be discovered again by each new person. The lab may contain enough experience to guide the work, but that experience is not in a form that moves easily from one researcher to another.
The consequence is a quiet duplication of effort. Labs often reproduce work they have already done, not because people are careless, but because the knowledge of that work did not travel well. A result may exist without its reasoning. A protocol may exist without its boundary conditions. A failed attempt may be remembered by one person but invisible to another. In this way, inefficient knowledge transfer turns individual learning into something that decays instead of accumulating.
Experimental research is interdisciplinary and complex in nature
Experimental research is slow also because the work is rarely contained inside one discipline. A researcher may enter a project through physics, chemistry, biology, or materials science, but the experiment soon reaches into engineering, electronics, mechanics, software, statistics, and data analysis. The real system does not respect the boundaries of training. It behaves as one coupled object, even when our expertise is divided into separate fields. This pressure has a broader pattern: as knowledge accumulates, innovators tend to train longer, specialize more narrowly, and work more through teams[6][7].
This creates a hard kind of learning. Researchers learn along the way, but often the first obstacle is not the answer. It is the question. When something fails, the cause may sit in a domain the researcher has not yet learned to see. A strange signal may be a physical effect, a control issue, a mechanical resonance, a software timing problem, or an artifact in the analysis. Before asking the right person or reading the right reference, the researcher may need to learn enough just to know what kind of problem it is.
The phrase "you don't know what you don't know" is especially true in experimental work. In a cavity QED experiment, for example, someone trained deeply in quantum dynamics may still need to reason about control theory or structural mechanics to understand why a cavity system is not behaving as expected. The difficulty is not that these fields are unrelated. The difficulty is that their connections only become visible when the apparatus fails in a specific way. By then, the researcher is already inside the problem and must build the missing language while trying to solve it.
The lack of a unified view makes this even harder. The optical setup, mechanical structure, control electronics, software, data pipeline, and theoretical model are often understood through separate mental pictures. Each picture may be correct locally, but the failure may live in the relation between them. A lab can spend a long time looking at one part of the system simply because the whole system is hard to hold in mind at once.
This complexity is not accidental or superficial. It is part of what makes experimental research powerful. But it also means that progress depends on repeatedly crossing boundaries of knowledge. Each crossing takes time, and many of them happen only after confusion has already appeared. In that sense, interdisciplinary complexity does not just make research intellectually demanding. It slows the feedback loop by making it hard to know, early enough, what question should be asked.
Automation overhead is high
Many laboratory operations sit in an uncomfortable middle ground. They are repetitive enough that automation seems natural, but not simple enough that automation is cheap. A measurement may require the same sequence of instrument settings, data movement, checks, and plots every day. In principle, much of this could be automated. In practice, writing reliable automation takes time, care, and a deep understanding of the experiment. The burden is especially visible because modern scientists increasingly depend on software as part of the scientific instrument itself[8]. More recent FAIR work also treats research software as a first-class object of scientific infrastructure, with its own discoverability, interoperability, reuse, and sustainability problems[9].
This cost changes the decision. A researcher may know that a task is repetitive and still choose to do it by hand, because the manual path is immediate. It does not require designing an interface, handling edge cases, debugging hardware behavior, or maintaining a script when the experiment changes. For one run, manual work is often faster. For a few runs, it remains tolerable. The problem appears only after the same small burden repeats across weeks, projects, and people.
The scale is easy to underestimate. Ten minutes of manual work does not feel like a serious friction. But if that ten minutes appears in every measurement, for every researcher, across many steps in the experiment, it becomes a large hidden cost. It also consumes attention in small pieces. The researcher must remember the right order, copy the right values, check the right files, and notice whether something unusual happened. These small acts do not look dramatic, but together they make the research loop heavier. Reproducible-computing guidance makes the same point in a different language: manual data manipulation is hard to audit and hard to replay[1].
Automation can also become its own burden when it is built under pressure. A quick script may save time for one person, but become hard for others to use. A workflow may work only under one set of assumptions. A piece of code may depend on an instrument state that was never written down. Then the lab has a new kind of overhead: not only manual repetition, but also fragile automation that must be understood, repaired, and worked around. Recent work on self-driving laboratory protocols points to the same difficulty from another angle: human-readable procedures often contain tacit, causal, and consistency assumptions that must be made explicit before they can become executable[10].
This is why automation overhead is a real friction rather than a simple absence of automation. Researchers are often choosing between two imperfect costs. Manual work wastes time slowly; automation can demand time upfront and create maintenance work later. When each decision is made locally, manual operation often wins. At the scale of the whole laboratory, however, those local choices accumulate into a large amount of effort spent on work that does not directly deepen the science.
Infrastructure is disconnected
Many laboratory frictions come from a simple fact: the pieces of the lab do not naturally live together. Instruments have their own interfaces. Data is saved in folders. Notes live in notebooks or documents. Code lives in repositories or local scripts. Discussions happen in messages, meetings, and memory. Each piece may be reasonable on its own, but the research process moves across all of them. This is why FAIR work emphasizes not only data, but also metadata, software, algorithms, tools, and workflows as research objects that need to be findable and reusable[11][9].
The difficulty appears in the gaps between these pieces. A dataset may not point clearly to the instrument state that produced it. A note may describe a measurement without linking to the code that analyzed it. A script may contain assumptions that are not written in the protocol. A calibration file may be stored separately from the result that depends on it. None of these breaks the experiment immediately, but each one weakens the chain of context.
Disconnected infrastructure also makes coordination harder. Researchers must constantly translate between tools, formats, and habits. They move information by hand, rename files, copy parameters, compare versions, and reconstruct relationships that the lab infrastructure does not preserve. This work is easy to dismiss because each action is small. But together, it creates a constant drag on the research loop. In materials research, this same point is often framed through FAIR and AI-ready data: data has little value if it is not well characterized and available for reuse[12].
The deeper problem is that the laboratory is a connected physical and intellectual system, while its infrastructure is often a collection of separate islands. The apparatus, data, analysis, documentation, and people are all part of one process, but they are not represented as one process. As a result, the true state of the research is distributed across many places, and no single place carries the whole picture.
This disconnection does not only waste time. It makes the lab harder to understand. It becomes harder to trace where a result came from, harder to compare one experiment with another, harder to know which version of a workflow produced a conclusion, and harder to see when two problems are actually related. The lab may be full of useful tools, yet still feel heavier than it should because the tools do not form a coherent whole.
Why I started building a lab environment
These frictions are the reason I started building a lab environment. They are not isolated annoyances. They point to a deeper pattern: the modern laboratory has become too complex for memory, coordination, and execution to depend so heavily on scattered tools and individual effort. If research is a feedback loop, then the lab environment is the medium through which that loop runs. A better medium can make the same researchers more effective.
LLMs and agentic AI make this moment especially interesting. They can reason over text, write code, call tools, summarize context, and help connect pieces of work that used to remain separate. But I do not think the important question is whether an AI can answer a single scientific question in isolation. The more important question is whether humans and intelligent agents can work inside the same laboratory context, with enough shared memory and enough connection to the real process of research. Recent work in autonomous chemical research shows that LLM-based systems can begin to connect planning, tool use, documentation, code, and experimental execution, even if the broader laboratory environment remains an open problem[13].
This is why I think the foundation is an environment, not just a collection of isolated assistants. What matters at the beginning is more basic: making it easier for people and agents to see the same context, act on the same work, and learn from the same history.
In the near term, the goal is modest but important: reduce friction. I want researchers to spend less time reconstructing context, repeating old effort, moving information by hand, or fighting the distance between tools. If the environment can make everyday research feel lighter and more cumulative, it is already valuable. Acceleration does not have to begin with a dramatic leap. It can begin with many small frictions being removed from the loop.
The longer vision is a laboratory that improves as research happens inside it. Each experiment would not only produce data, but also leave behind clearer context. Each workflow would not only finish a task, but also teach the environment how the lab works. Each failure would not simply disappear, but become part of the lab's future judgment. Over time, the laboratory could become more organized, more capable, and more responsive to the researchers who use it. Self-driving laboratory examples and recent perspectives already show pieces of this direction: closed loops where systems design, execute, and learn from experiments, and broader workflows where AI, computation, and robotics reinforce one another[14][15][16].
That is the direction I want to build toward: a path from reducing everyday friction toward laboratories that can continuously learn, automate, and accelerate discovery. The goal is not to remove the human researcher from science. It is to build an environment where human taste, judgment, and creativity are less buried by operational weight. Research will always require deep thinking, but the lab around that thinking can become much better.
References
- [1]Sandve, G. K., Nekrutenko, A., Taylor, J., and Hovig, E. Ten Simple Rules for Reproducible Computational Research. PLOS Computational Biology 9(10), e1003285 (2013).
- [2]Vines, T. H., Albert, A. Y. K., Andrew, R. L., DeBarre, F., Bock, D. G., Franklin, M. T., Gilbert, K. J., Moore, J.-S., Renaut, S., and Rennison, D. J. The Availability of Research Data Declines Rapidly with Article Age. Current Biology 24(1), 94-97 (2014).
- [3]Polanyi, M. The Tacit Dimension. Doubleday (1966).
- [4]Collins, H. M. Tacit Knowledge, Trust and the Q of Sapphire. Social Studies of Science 31(1), 71-85 (2001).
- [5]Delamont, S., and Atkinson, P. Doctoring Uncertainty: Mastering Craft Knowledge. Social Studies of Science 31(1), 87-107 (2001).
- [6]Jones, B. F. The Burden of Knowledge and the Death of the Renaissance Man: Is Innovation Getting Harder? The Review of Economic Studies 76(1), 283-317 (2009).
- [7]Wuchty, S., Jones, B. F., and Uzzi, B. The Increasing Dominance of Teams in the Production of Knowledge. Science 316(5827), 1036-1039 (2007).
- [8]Wilson, G., Aruliah, D. A., Brown, C. T., et al. Best Practices for Scientific Computing. PLOS Biology 12(1), e1001745 (2014).
- [9]Barker, M., Chue Hong, N. P., Katz, D. S., et al. Introducing the FAIR Principles for research software. Scientific Data 9, 622 (2022).
- [10]Shi, Y.-Z., Meng, F., Hou, H., Bi, Z., Xu, Q., Ruan, L., and Wang, Q. Expert-level protocol translation for self-driving labs. arXiv preprint (2024).
- [11]Wilkinson, M. D., Dumontier, M., Aalbersberg, I. J., et al. The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data 3, 160018 (2016).
- [12]Scheffler, M., Aeschlimann, M., Albrecht, M., et al. FAIR data enabling new horizons for materials research. Nature 604, 635-642 (2022).
- [13]Boiko, D. A., MacKnight, R., Kline, B., and Gomes, G. Autonomous chemical research with large language models. Nature 624, 570-578 (2023).
- [14]Burger, B., Maffettone, P. M., Gusev, V. V., et al. A mobile robotic chemist. Nature 583, 237-241 (2020).
- [15]MacLeod, B. P., Parlane, F. G. L., Morrissey, T. D., et al. Self-driving laboratory for accelerated discovery of thin-film materials. Science Advances 6(20), eaaz8867 (2020).
- [16]Pyzer-Knapp, E. O., Pitera, J. W., Staar, P. W. J., et al. Accelerating materials discovery using artificial intelligence, high performance computing and robotics. npj Computational Materials 8, 84 (2022).