Getting the Flywheel to Turn
Why the research flywheel never really turned, and how an agentic layer could give compounding work somewhere to live.
A collaborative piece by Rishi Jain and Cypher AI ·
Scientific research is amorphous. It branches and sprawls unpredictably, like some great filamentous creature pushing through space. Big questions are rarely small or linear, so two experiments turn into five, five into ten, each new finding spawning the next question. To outsiders, this is the romance of the work, and research organizations have built a compelling narrative around it: as scientists do more, they accumulate more: datasets, protocols, physical assets, intuitions. This connective tissue, the story goes, holds richer long-term value than any single patent, because it compounds. Every experiment becomes raw material for the next, and sophistication builds on sophistication. Pitch decks, grant applications, and investor memos lean on this flywheel.
The problem is that the flywheel rarely turns. Look closely at most research programs and the legacy of past experiments shows up as fingerprints, not infrastructure: a positive control here, a protocol optimization there, scattered across what is otherwise a bespoke harness built to test a new question. Small tweaks to an experimental goal ripple outward and create entirely new experimental designs, which is part of why this happens. But it is also an admission that nothing about our current physical, digital, or managerial traditions allows scientists to fully extract the insight latent in their own work.
Much of the leakage happens in software. To understand how scientific tools end up hindering science, it helps to look at how they come into being. Internal tools in research organizations almost always emerge from one of three origin stories. Each is reasonable on its own terms. Each contributes to the mess.
BUILDING THE PLANE AS YOU FLY IT
Behind every brilliant scientific question lies an unglamorous infrastructure requirement: somewhere to put your thoughts, your plans, your data. This minimum set of assets differs from experiment to experiment, and rebuilding it from scratch each time scales poorly. Before long, a single project sprawls across a Google Drive folder of literature, a slide deck of high-level plans, a protocol document, Excel sheets mapping out input samples, a paper notebook full of calculations and improvisations, photos of colonies and gel bands, downloaded instrument data, more spreadsheets for first-pass cleaning, and a Python notebook for the deeper analysis. Managing this menagerie becomes a job in itself. Version control spirals. Data formats fail to align and must be coerced through refactoring scripts so that one tool's output can become another's input.
At organizational scale, the gaps multiply. Teams accumulate dozens of single-function third-party tools to fill them. The dependence on these widgets keeps data and documentation moving, but the cognitive overhead of orchestrating them quietly siphons off processing power that should be spent on the science itself. "Every time you have your PhD-level scientist thinking about something that isn't science, there's an opportunity cost," says Ramya Prathuri, a senior scientist who has spent years watching the pattern repeat across teams. "The ecosystem of one million .ly softwares makes twenty percent of your brain useless."
The best case here is a team where every scientist runs an efficient, self-contained operation. Over time, though, these sovereign research nations develop their own customs, and the customs become decreasingly transferable. One symptom is what Prathuri calls spoofing: documentation or software shortcuts that unlock individual efficiency by quietly divorcing the protocol from what actually happened at the bench. A serial dilution done by hand gets logged as a uniform robotic stamp because doing so generates the run file faster, with the deviation buried in a footnote or a faraway slide. "Software asks you to specify your intent before you do something," she says. "Specify your intent, do the thing, re-enter what you did, and do this over and over. The more you have to do this repeatedly, the more you look for ways to simplify it." Over time, these shortcuts become an encrypted private language, and the explicit experimental process grows less and less explicit.
The worst case is mental overload outpacing the maintenance of the infrastructure entirely. Upkeep tasks crowd out higher-level thinking; team members either burn out on the work that matters or stop maintaining the parts of the system that made it reusable in the first place, or both. Files take on non-uniform formats and inconsistent names. Data scatters across .csv files in local folders instead of converging in a searchable, sample-linked database. Some protocols go missing. One-off scripts never harden into pipelines. Proprietary data gets pasted into whatever browser-based data cleaner happens to top a Google search, with no one quite sure where it lives afterward.
The two endpoints look surprisingly similar. Completed work fails to resemble the digital fingerprint it leaves behind. Insights are lost. Global process improvements get traded for local ones. And because no one is sure who did what or whether it worked, the wheel gets reinvented again and again under a slowly thickening fog of widgets, apps, and half-finished pipelines.
THE CRAFTY POLYMATH
Sometimes a team gets lucky. Someone in the group is deeply scientific and has dabbled in enough software to automate part of a workflow themselves. This person whips together a small tool flexible enough to handle a handful of related use cases, documented just well enough for colleagues to fumble through using it. For months, sometimes years, this lonely script gets bent and stretched to fit purposes it was never quite designed for.
The risk here is silent, and that is what makes it dangerous. A pipeline applies a statistical test that was valid for the original data distribution but is wrong for the new one, and the resulting insight is plausible enough to act on. A genome assembly method gets reused on sequencing data that is just different enough in quality or format to produce a subtly incorrect output but not different enough to flag an issue. These failures rarely announce themselves. They surface months later, when a downstream experiment doesn't produce the expected result and no one can trace the rot back to the moment the tool was misapplied.
Even setting aside the silent failures, the original builder is condemned to a particular kind of purgatory: running the tool on behalf of colleagues who can't figure it out, patching breakages, migrating it to new IT systems. If they were clever enough to build one useful thing, they have usually built many, and the cumulative maintenance burden bifurcates their written role from their actual one. The scientists most capable of automating their own work end up so consumed by automation that their original science begins to atrophy. "Some of these are difficult analytical pipelines that one guy wrote and now they need to work forever," Prathuri says. "You've introduced a bottleneck that is both unnecessary and also necessary. Necessary because they needed to exist. Unnecessary because they didn't all need to be run and maintained by one person."
THE FORMAL BUILD
Finally, there is the version that looks proper on paper: a mature team commissions a tool from a dedicated software developer, internal or external. From day one the developer thinks about long-term stability, breadth of use cases, user testing. They interview future power users. They iterate. The final product is, in theory, calibrated to the problem.
In practice, the interface between builder and user leaks badly. Adam Ferguson has spent the last decade building software and automation for bench scientists, translating their needs into hands-off tools, and he describes the gap candidly. "It's really challenging that one person can't hold all the expectations for what the user needs in their heads, and the translation is lossy. You always have to slim down the full capabilities for the thing you're building." In a previous role converting hand-pipetted workflows into robotic ones, Ferguson found that every visit to the lab generated a new feature he hadn't known was needed. "As the builder, you have more expertise in how to build, and someone else has more expertise in how to use it. That mismatch creates an implementation gap."
Hiring more scientifically literate builders is the obvious fix, but it doesn't solve the problem. Yaoyu Yang, who trained as a bench scientist before moving into tool development, recalls being considered one of the best translators between the two worlds at a previous company. "It would still take me weeks," he says, "and even then [the scientists would] come back and articulate things the software product didn't do." The lossy translation is not a skill gap. It is a structural feature of one person trying to encode another person's evolving, branching work into a fixed interface.
The implementation gap appears on the other side of the interaction as well. Training users how to use a feature correctly is a challenge, and there just isn’t a way to cleanly communicate the optimized use cases or limitations to every person. “The canonical example is people using a robotic liquid handler to transfer volumes below what we’ve QC’d,” recounts Ferguson, thinking about ways in which unmet needs and hidden constraints created silent failures. “I think agentic error prediction and flagging could prevent some of these failures,” he continued. “People are attacking it from this direction now. They’re starting by writing firmware commands for every [liquid handler] capability in Python. Once you do this you can have Claude write something for you.”
IN PURSUIT OF THE BUILDER-USER
The common thread across all three origin stories is that the person building the tool either lacks the scientific context to build it well or lacks the bandwidth to maintain it. Tooling does not scale with the science it is meant to serve. Each new thing built makes the next thing harder.
What would it take for scientists to become their own builders without inheriting the maintenance burden? Yang envisions an agentic platform built on the premise that the scientist and the builder should be the same person, and that the friction preventing this today is a tooling problem rather than a skill one. His company, Cypher AI, lets researchers spin up their own widgets and analyses by describing what they want in natural language, grounded in the context of their own experiments. As a scientist builds more, the system constructs a schema underneath their work, with vocabulary specific to their lab. It notices similarities and differences across experiments, groups related workflows, and, operating from the first principle that every sample comes from somewhere and goes somewhere, assembles complete lineages that connect workflows and outcomes to one another.
Picture for a moment a scientist using a classical set of tools to perform a flow cytometry experiment. Their workflow, with some deviations, might include planning a plate layout and test conditions in a slide deck, calculating reagent preparation steps in a spreadsheet, arranging a liquid transfer step to create the virtual sample plate in a disconnected LIMS system, writing notes in a physical lab notebook related to specific day-of protocol details, transferring the output .fcs files into an analysis software like FlowJo, exporting the output statistics into a new .csv file, and writing a Python script for secondary analysis. This relatively linear experiment requires seven different software touchpoints, and an eighth if there’s a high level organization system where all the relevant links to these assets are stored. Every subsequent experiment restarts the cycle.
With Cypher AI, the same experimenter could describe their intent to the built-in chat and add a paper with a protocol they wish to replicate and tell Cypher AI they need a layout, protocol, and virtual plate with specific samples and conditions they wish to test. Upon generating these assets, they can use natural language to prompt detail tweaks and enter notes into Cypher AI directly. After the experiment is done, they can use the analysis modules in Cypher AI to tabulate stats from their .fcs files and prompt the creation of a widget that will follow a custom format for graphing these stats. One of the most intriguing parts is the attachment of this data to the parent samples, and the preservation of the lineage if any child samples are promoted for further experimentation.
Beyond the workflow itself, compliance is the quiet payoff. The steps that would otherwise be spoofed (the dozen sub-actions inside a transformation, the manual dilution masquerading as a robotic stamp) get represented at a higher level of abstraction, which means scientists can record what actually happened without drowning in form fields. Sample lineages stay unbroken through the inclusion of steps that happened off the record. The experimental ledger begins to look more like the experiment.
The widgets themselves act as force multipliers. Scientists prompt them into existence: tools that compile literature, build protocols, scrape DNA sequences, codon-optimize designs, handle stubborn formats like the .fcs files spat out by flow cytometers. They are shareable across teams and modifiable by prompt, which sidesteps the brittleness of the hero-built tool of the past, frozen in static code and maintained by a single overburdened author. Life science offers unlimited opportunities for micro-optimization of tedious repetitive steps, and Cypher AI users have have demonstrated this through prolific widget creation: over 1000 scientists have built hundreds of widgets and run them close to 100,000 times on Cypher AI so far, none of them requiring a new UI to learn or a forgotten interface to relearn.
Experimental branches of the past were wild and sprawling, but the overgrowth wasn’t the actual problem. The real issue was that key nodes went missing, like an evolutionary tree full of broken branches, leaving no way to tell how closely related two experiments were, or to learn from work you were not actively conducting. The promise of an agentic layer is not to linearize the tree’s growth but to keep the branches intact: to give scientists tighter control over their work on the front end while quietly capturing structure on the back end. If it works, the compounding that the research narrative has always promised—the flywheel of accumulated insight and the assets that become the raw material for the next experiment—finally has somewhere to live. The filamentous creature keeps growing and digging. It just stops losing pieces of itself along the way.