The lab notebook is naturally one of the first decisions new labs need to make. When I started as an undergraduate, everything went into paper notebooks. I color-coded by hand and taped experiment printouts onto the pages.

I generated a few linear feet of notebooks as a PhD student, but they stayed with the lab when I graduated. That made sense: research is collaborative, and my notes were part of a larger investigative program. Other researchers could continue using my data when relevant to their own projects.

Our requirements

In Kupalab, we’re planning to host our electronic notebook on a local lab server, with encrypted cloud backups. Researchers will be able to search across experiments, add results directly from the instruments and follow how a project develops. We want to make it easier to find old experiments and trace the genealogy of new observations back to their source.

We also want to use AI to help search and compare experiments as the lab grows. That takes more than adding a chatbot later: our data needs to be structured in formats we can export and use with other tools, and our electronic lab notebook needs to connect to those tools.

One connection we cared about is MCP, an emerging standard for AI assistants to communicate with software tools. We wanted to choose the LLM ourselves, including the option to run one locally. We also want to keep our data close, in systems we can control, and retain practical freedom to move it if our needs change. Exports and an API can help keep our records portable.

Our options

We looked at Benchling, Scispot, SciSure/eLabNext, LabArchives, SciNote, RSpace and eLabFTW. Each offered a different balance of features, hosting, cost and openness to the kind of AI connection we wanted.

Benchling was an attractive name to investigate. But during our evaluation, its MCP server was not available with Benchling for Academics. Benchling’s documentation described the MCP option for Enterprise users, and setting it up required Benchling Chat to be enabled. That put the route we wanted behind a commercial offering, beyond what made sense for a small academic lab starting from scratch. We set it aside.

Scispot’s hosted approach seemed less suited to our preference for keeping control of where the main records live. For LabArchives and SciNote, we could not confirm a clear, supported route to the AI connection we wanted. Our shortlist narrowed to open-source RSpace and eLabFTW, both of which we could host ourselves and build on. SciSure/eLabNext remains a commercial alternative if a managed service proves the better fit.

Cost matters when a lab is just getting started. We’re stretching departmental research funds and asking colleagues with resources to spare to help equip the lab. eLabFTW’s software has no license fee; the server, backups and maintenance still take resources, but skipping a commercial subscription is a very attractive price point for us. The API gives us a starting point to build or adapt an AI connection, though that work is still ahead of us. With eLabFTW’s large community of engaged users, we expect the ecosystem’s AI integrations to evolve rapidly.

We’re excited to have made this choice, and a little trepidatious too. Choosing a lab notebook is a serious commitment: it shapes our daily work, preserves our findings and affects how future members of the lab shape their contributions.

Fortunately, eLabFTW offers exports in several formats and a public API. We hope these options will make it easier to take our records with us if our needs change or we decide to move in a different direction. That gives us room to start, learn from experience and adapt as the lab grows.

Are you integrating AI with your electronic lab notebook? I’d love to hear what criteria shaped your choice and how the integration is going. We’re early in building Kupalab and would especially welcome input from current eLabFTW users: how have you found the development community, and what efforts to connect eLabFTW with AI are you following or trying? Your experience could help us make better decisions as we build. Comment below:

I was fascinated by Google’s recent publication, which incorporates AI into the aptamer discovery workflow. I explored this area as a PhD student and the field has advanced significantly during my subsequent years of medical training. Google’s new paper is a remarkable example of how far it has come.

An aptamer is a short snippet of DNA or RNA that attaches to a target like a protein.

Aptamers look like this:

☝🏾 That is a 15-nucleotide sequence of single-stranded DNA.¹ I drew it squiggly because aptamers fold in interesting ways, which is what allows them to stick to things. I discovered that the above 15-nucleotide aptamer strongly binds simple sugars, including glucose.

I wasn’t intending to find sugar-binding aptamers, however!

My PhD research was actually looking for aptamers that bind Cryptosporidium parvum, a waterborne pathogen that can spread through contaminated water, including public pools. If your local waterpark gets shut down, Cryptosporidium could likely be the culprit. The thinking was this: maybe we could design a way to detect Cryptosporidium in water by finding an aptamer that binds it strongly and then attaching that aptamer to something that gives off a signal when it latches on, a colour change or a flash of fluorescence, so a sample could be checked on the spot instead of sent away to a lab.

I was also trying to discover aptamers that bind human α-thrombin, a protein involved in blood clotting (Google’s new study also used thrombin as one of its targets). One aptamer that binds thrombin has been known for decades and is thoroughly characterised, so the field uses it to test new discovery methods. That is why thrombin shows up in both my work and Google’s: new methods should be able to find aptamers that are already known.

One sequence confused us for weeks

In our 2011 study, we started with a DNA library, basically a tube holding every possible 15-letter sequence at once, around a billion of them with about 56,000 copies of each. We used deep sequencing to find thrombin aptamers after a single selection step, rather than the usual repeated cycles of selection and amplification.²

At the time, combining an over-represented library with deep sequencing in this way was a novel approach, part of a broader effort to make discovery faster. We found the well-known thrombin aptamer, which proved the viability of our method. We also found a family of previously-undescribed variants, whose abundance tracked how tightly they bound.

Surprisingly, we found one sequence, the GCTATCATCGCAACG sequence drawn above, which was the most abundant sequence in the whole experiment behind only the thrombin aptamer itself.

Was this a new thrombin-binding aptamer?

Answering that took weeks at the bench. First we asked if the sequence was an artifact rather than a binder at all.³ Nope. Then we measured how tightly it actually held thrombin. Not very well at all.

So what was it binding to!?

We went back through everything the DNA had touched. The answer turned out to be sitting in the buffers, the salt solutions a protein is stored and washed in. Ours carried simple sugars, glucose and α-methyl mannoside, left behind by the way the thrombin had been prepared. GCTATCATCGCAACG was binding those sugars!

The signal was real, but did not belong to the thrombin target we were selecting for.

AI comes for aptamer discovery

In the years after I graduated and completed my medical training, researchers began using machine learning to help choose which sequences to test. Google’s 2021 study combined experiments with neural-network predictions. Now its recent paper takes another step: AI agents propose sequences, a human team tests them, and the results help guide the next round of experiments.

The new study, which went up on 17 October, reports that by the third round, roughly four in ten newly-designed thrombin candidates and one in three myoglobin candidates counted as on-target hits: they showed evidence of binding the intended protein under the study’s screening criteria. That is promising because researchers can focus follow-up work on candidates that pass this initial test.⁴

What struck me is how the role of computation changed. When I was grinding away at my PhD in 2011, sequencing made it possible to peer deeper into a selection experiment. Now in 2026, machine learning and automation can use experimental results to iteratively improve subsequent rounds.

Google runs into a familiar frustration

Google’s team hit the same kind of trouble with myoglobin as I did with thrombin. In their protocol, they attached each target protein to tiny magnetic beads, and then tested which DNA sequences bound them. Some promising candidates bound strongly but it turned out that they were “sticky.” That is, they tended to cling to things generally, not the intended target (myoglobin). It turned out that Google’s sticky sequences were binding to the bare magnetic beads or other proteins in the experiment.

That is the same trap my sugar-binding sequence set for us fifteen years earlier. A strong signal tells you that something bound but it does not tell you what it bound to. Both cases show why you run controls and follow-up tests before calling a sequence a success.

The remarkable part of Google’s project is that the detection of nonspecific binding was directly AI-related. The AI agents recognized the myoglobin cross-reactivity from the Round 2 sequencing and counter-screen results, and revised their design rules for Round 3 themselves, reducing overrepresented sticky structures and exploring other DNA shapes.⁵

Human researchers still prepared and ran the experiments. AI’s role was to interpret the readout and guide the next candidate pool. However, even as I write this, numerous teams are racing towards the next step: removing human scientists from the bench and allowing AIs to both plan and execute experiments with autonomous “self-driving labs.”

I’m curious: have you seen AI-driven developments reshape a field you studied earlier in your career?

Sources

• Kupakuwana, G. V. et al. (2011). Acyclic Identification of Aptamers for Human alpha-Thrombin Using Over-Represented Libraries and Deep Sequencing. PLOS ONE.
• Kupakuwana, G. V. (2011). High Throughput Screening of Aptamers. Syracuse University dissertation record and abstract.
• Bashir, A. et al. (2021). Machine learning guided aptamer refinement and discovery. Nature Communications.
• Cutts, Z. et al. (2026). Aptamers as a sandbox for lab-in-the-loop agentic molecular discovery. Google Research paper.

The awards come at an important stage in building a research program focused on myeloid cancers, including acute myeloid leukemia and myelodysplastic syndromes. Early support helps create room to develop questions, methods, and collaborations that can move a new research program forward.

We’re grateful to the Department of Medicine and the Upstate Cancer Center for investing in this work, and to the wider Upstate community whose support is helping the program take shape, including colleagues in the Division of Hematology and Oncology and the Upstate Foundation, through colleague gifts and the Beers Fund. Together, this support will allow us to hire our first postdoc, equip the lab and generate pilot data for our first external funding applications.