There is a lot to say about our experience through this project. We still have a few months left, but with the volume of hype in the autonomous science right now – from the release of Anthropic’s Claude Science to the myriad startups around – we thought we would share some of these learnings now, to give you some insight on where we really are with these tools.

To do this, we gave the AI complete decision making power across the scientific process – from high level experimental prioritisation, all the way down to deciding which reagents should go in which well. We did this to better understand where the wrinkles really are.

As an ostensible “AI for Science” startup you’d imagine this is where the hyperbole would begin. But surely you’re bored of this by now. Instead we’ll focus here on where it’s inadequate and where – if implemented incorrectly – it could be genuinely dangerous and destructive to science. Oh yes, the good stuff. Today, we’ll start with skepticism.

Skepticism in science

If I had to characterise the best scientists I’ve ever worked with, I’d say they are deeply skeptical people. They greet every figure with a raised eyebrow. They explain all the ways the data could be lying to you. They’ll give you 5 orthogonal experiments to run before they’ll consider accepting your hypothesis.

This skepticism is bred from the gauntlet of doing the work of science. Life is unimaginably complex – there are hidden variables around every corner, ready to confound you. Skepticism is humanity’s answer. It is a finely tuned skill that keeps us on the path towards what is true – not what simply appears to be true.

AI... well, AI is not skeptical. In fact, I would go as far to say that AI is the opposite of skeptical. It is gullible. It is optimistic. It frequently squeezes the data to fit a chosen biological narrative. It cares about appearing to be right, not actually being right.

Let’s go through an example from our project. When analysing a fresh batch of data, the AI scientist presented us with a clear trend. As reporter agrobacterium OD increases, as does a normalised luminescence output. It described this data in terms of its medians. 0.78 → 0.81 → 0.88.

The AI used this trend to explain other interesting correlations it saw in the dataset. Then it committed these conclusions to a report, along with suggestions for the next experiment based on its findings. This report would then be picked up by a subsequent agent to kick off the next experimental iteration. At first glance, this is all as it should be.

The keen eyed amongst you may have noticed something missing. Error bars. Luckily, we noticed too. Here’s what the underlying data looked like.

Yeah. I don’t think you need a statistical test to tell you that this is... not proof of anything.

The AI didn’t eyeball the data, it didn’t run a statistical test, nor did it bother to show me this underlying data. It saw a positive correlation, got excited, and ran with it. I wish I could say this was a one-off, but it has happened regularly – regardless of which model we use or how we prompt it. We’ve even tried throwing our data at some of the fancier science-specific harnesses (Claude Science for example) and have had similar issues.

It was during these mishaps that I became worried, not just frustrated. As we increasingly delegate to AI, we leave more and more space for these mistakes to go unnoticed. Agentic systems do so much work, so quickly, it is becoming harder and harder to keep track of what exactly they have done. And when a mistake slips through, it forms inaccurate scientific foundations upon which future experiments are planned.

These systems have the potential to create a tonne of mess and confusion. If a mistake like this propagates through to the next experiment, how many subsequent failed experiments will it take to get back to the root issue? Having been through these kinds of troubleshooting episodes before, I can tell you, it is never just one. Science is messy.

So, let’s increase AI’s skepticism! Well, yes, let’s. But first, I want to us to take a step back, and look at a more fundamental change we should make that isn’t just about making the AIs (and their harnesses) better at science.

Transparency, always.

Science is not coding. You cannot ‘vibe science’. This is because you cannot objectively test whether science has been done ‘correctly’. As such, outputs of AIs used for science need to be clear and intelligible to human researchers so that they can remain in the loop – to question, to direct, or to dive deeper.

And no, a Jupyter notebook or a code block is not enough. Most scientists do not code, – burying all of AI’s actions in code is not intelligible to most of the people who must review its work.

The importance of transparency ratchets up a notch when you begin dealing with the physical world. The risk and impact of failure here can be enormous – failed experiments and broken equipment for now perhaps, but as automated labs become increasingly sophisticated and integrated, then genuine biosafety risks emerge.

We do not want to end up in a world where scientists cannot understand or inspect exactly what will happen in their autonomous lab. With all the talk of ‘rogue agents’ in the news at the moment, I hope you’ll understand that the biosafety risks are not just pie-in-the-sky.

As a company building AI-driven interfaces to lab automation, we operate with three core principles:

1. AI generated protocols must be both understandable and editable directly by scientists.

2. AI generated protocols must run the robot deterministically. The artefact that the human reviews is not an AI summary of code, it is the actual workflow itself. What you see is what you get.

3. A human must always be the one to initiate protocols on lab robots.

These three principals together mean that, when a protocol is run, the scientist always understands what will run, and can be accountable for it.

And in parallel, let’s keep improving the models and the harnesses. Foundation LLM providers can post-train their models specifically for science – reduce their focus on being ‘helpful’ and satisfying the user, and increase their attention on skepticism and rigour. Antagonistic agents can be integrated into harnesses to review the work of agents running the science. Skills and tools can be provided to agents to help them follow best practices. Where relevant, genuine constraints can be placed around agents to ensure they avoid common pitfalls.

But transparency to the scientist is the basis for all of this. If the scientist is to be ultimately responsible for the AI’s outputs, they need to know what it is doing. This sounds simple, but it is a long way from where these tools are today.

You may or may not be surprised to learn what happened next. Far from freeing scientists from their RSI, they mostly worked around the robots. They remained totems. Ironically, the robot even commanded a new hire of its own – my now cofounder Staffan – who pestered scientists to write up their protocols so he could automate them. By the time he’d got them working, they were working on something new.

While our automation efforts did end up valuable, one thing remained true – scientists never seemed to spend any less time in the lab. I think the reason why is actually the same one that plagued us from the very beginning: scientists always fill their time with something new. This work is the stuff that the automation platform never touched. New assays to develop, issues to troubleshoot, or processes to optimise. Their efforts became more efficient, yes. Their time wasn’t wasted on running the same NGS prep workflow 20 times a week. But now they were in the lab working on something weirder, and less well documented. For this, their hands were always faster – plan the experiment in the morning, then get into the lab and run it that afternoon. They weren’t going to go through the rigamarole of programming their liquid handing robot to help with this. They were going to get on and do it.

Now, in 2026, amidst the talk of autonomous science, this same bottleneck to the whole endeavour remains. We can build a system that autonomously improves antibody binding affinity, for instance. We’ve constrained and parameterised that particular workflow in such a way that it can be run and re-run, even including some changes and tweaks that an AI might suggest. And there’s clear value in that.

But this system cannot troubleshoot itself – it can’t run its own experiments to figure out that it has a dodgy lot of reagents. It can’t figure out that it needs a different expression system, plan the change, test and implement it in the real world. It can’t come up with a screening assay that increases throughput 10 fold. Autonomous systems are too constrained to one specific challenge. LLM-powered AI scientists too disconnected from the real world.

This more fundamental exploration and problem solving is still the work of the scientist. Spotting an unexplored path, wondering where it might lead, then following that path ‘til they hit a dead end. My issue is that the scientist’s hands are still the rate limiter in all this. They are at the bench, moving small amounts of liquids around. The PCR machine solves more problems for the average research scientist than liquid handler or a fancy robotic workcell. This is, frankly, ridiculous.

And the opportunity here is massive. Imagine if a scientist could run 10 different exploratory experiments at the same time, no longer constrained by what they can do with their hands, but just by the capacity of their lab and their imagination.

This is the bottleneck that Briefly wants to overcome. To make robots an extension of scientists. To make robots that experiment.

With all the buzz around LLMs, many have been trying to use them to open the floodgates to automated research. Agentic AI scientists that can come up with hypotheses, design experiments, program lab robots, and analyse the results.

I’m sceptical – at least in the short term. Not sceptical that LLMs can add tremendous value to the scientific process. There are tonnes of use-cases and companies building products to streamline science. Take a look at the newest literature search tools; smarter hypothesis generation; the application of language models to protein engineering… the list goes on.

What I’m sceptical of are the visions of a scientist deciding on an experiment they’d like to run, and pressing go. A cloud of agents descending on the problem. Picking it apart, researching it, designing the perfect experiment, programming the robots, analysing the data, and presenting the results back to the scientist.

Why am I sceptical? Although there’s plenty of evidence that AI can do a great job at a number of these tasks (certainly for simpler experiments), the trouble comes in stringing these tasks together.

Our own experience building an AI-driven product largely aligns with this excellent blog post by Utkarsh Kanwat. The crux of it comes down to compounding error. Even with error rates at 95%, agentic workflows with only 10 steps fail 41% of the time.

As long as AI continues to be prone to hallucination, these kinds of complex agentic workflows will have unacceptable failure rates. This is true even in domains where there are vast quantities of well written documentation for LLMs to learn from. It is even worse in the business of automating science, where the tiniest details matter, and these details may never have been published outside of a single scientist’s notebook.

And then there’s lab automation. Much development and maintenance is handled by the vendors themselves, with detailed, publicly available documentation taking a backseat in favour of a service call. And while there’s some growth in automation developer forums and peer-to-peer help, there are orders of magnitude less for LLMs to learn from than in software developer communities.

All of this taken together, means that successfully building useful, reliable products with AI requires us to build systems and interfaces around LLMs, to ensure errors are caught before a precious experiment is wasted. We cannot surrender to the swarm of agents just yet.

A Case Study in Lab Automation

Let’s look at this problem through the specific lens of automation so I can explain a little more in depth:

A fully integrated, agentic workflow for lab automation would likely look something like this:

1. A scientist describes the experimental question they would like to answer to the LLM through a prompt.

2. The intent is broken down into a concrete protocol, with all the implicit steps and parameters made explicit.

3. Laboratory workcells and equipment are selected that fit the protocol that has been designed.

4. The protocol is translated into appropriate code for the laboratory automation.

5. Instructions are generated for the operator to setup and run this particular experiment in the lab.

6. Automation code is sent to the robots, and instructions are sent to the operator to get started.

Tangled protocols

Imagine an error is introduced while the LLM is creating the protocol – perhaps the wrong amount of enzyme is added, or a control is forgotten (yes, AIs do this too!) – this error will propagate through to the robot, and the experiment is doomed.

The AI does not even need to ‘hallucinate’ to go astray. it may just lack the requisite context that it needs from the scientist to design the appropriate protocol.

To solve this, the scientist needs an opportunity to check the AI’s work. They need to ensure that the protocol matches their expectations. That means we need an interface here – a clear, unambiguous description of how the AI intends to test the hypothesis, with an easy way for the scientist to make changes if it has gone awry.

Translating to automation code

Errors or hallucinations introduced into the automation code are just as problematic. This might result in anything from a cryptic error message, to a full-on crash.

A solution here is a little more tricky. Let’s say we add another interface for the scientist to check. We could show the scientist the code before it is sent to the robot? Well this falls at the first hurdle. Most scientists don’t code, so spotting errors here is going to be a non-starter.

Our next option is a user interface. We could show the AI generated workflow in the vendor’s interface and have the scientist check it through there?

Well, this doesn’t really work either – for a couple of reasons.

The first is that most of these user interfaces are… challenging for a newcomer to use or interpret. Many require multiple day training courses to get to grips with, and a months or years of experience to become truly proficient. They were never designed for a scientist.

Secondly, in order to spot potential errors in automation code, being able to understand the workflow is only half the battle. the user also need a deep understanding of how the machine works – it’s constraints, it’s deck, it’s little quirks. In short, you need to understand the software and the hardware… In even shorter, you need to be an automation engineer.

This means that looping in the scientist with existing tooling alone won’t solve the problem here. We need a two-pronged approach.

First we need a clear view of precisely what the robot is going to do, expressed in terms that scientists can actually understand. We think this means introducing more abstraction. Clear actions that they recognise from their day job. Stuff like tip-tracking and deck definitions needs to be taken care of behind the scenes.

Here’s a look at Briefly’s protocol view to give you an idea of how we think these workflows should be visualised.

Critically, they need more layers of validation and simulation: Old fashioned, deterministic software that ensures the workflow can actually be run on the robot, and won’t cause any errors or crashes. Any issues need to be clearly conveyed to the scientist so they can understand the issue, and make adjustments to get around it. Whether that’s switching to a different piece of labware, or adjusting their pipetting volumes.

Heres’s our validation engine at work, pointing out issues to the user to be tweaked before it heads to the robot.

There is no shortcut

In fields like ours, there are few easy wins with AI. Getting value from LLMs means taking a step back, and thinking about the workflow and its users – how can we unlock automation for a whole new group of scientists, while mitigating the inherent risks and shortcomings of these models?

We’re tackling these problems from the ground up. If you’re interested in integrating Briefly’s software with your lab robots, let’s have a chat!

Contact us

Old hands of the molecular biology world will regale you with tales of the ‘good’ old days, when they had to manually dunk their samples in three water baths, set to three different temperatures; with an eye on a stopwatch to tell them when to move from one to the next.

The automated PCR machine replaced that, and delivered the holy trinity of lab automation, that is so often promised and yet rarely delivered:

1. They save the scientist time. Pop the samples in, program the thermocycling conditions, hit go. 2 minutes to set up, and a couple of hours tedious manual work avoided.

2. They’re more reliable. 20 or 30 cycles of carefully timed incubations is tough to do consistently.

3. End-to-end, they’re just as fast, if not faster than working manually. Especially if you forgot to pre-heat the water baths!

PCR machines are now completely ubiquitous. This is partly a reflection of the ubiquity of PCR as a technique – but it’s also a success story for lab automation. The first real pipetting robots were released at a similar time, and while humans are still doing most liquid handling in labs, precisely no one is running their PCRs manually.

I think the success of the PCR machine can tell us something about when and how to deploy lab automation today, and what it’ll take to move this field on to the next wave of adoption for lab automation.

PCR machines fit into a scientists workflow: Besides using the right tubes, scientists don’t need to adjust their experiment upstream or downstream of a PCR machine to get value out of it. It’s clear what goes in, and it’s clear what comes out.

They are simple to reprogram: Just punch in the new temperatures and times, and hit go. No training required.

They’re trustworthy: PCR machines very very rarely fail. And new ‘untested’ programs don’t require any testing before scientists can trust them with their precious samples. They can rely on the hardware being solid, while they’re trying to get their wetware working.

So how does this match up with liquid handling?

Well, if you take a standalone ‘naive’ liquid handler… it really doesn’t measure up well. Let’s go through each in turn:

Liquid handlers don’t slot into scientists’ workflows: they squash their users towards specific labware and tips. This might mean reformatting their samples specifically so they can be used on the robot. Worse, exactly what these constraints are is not obvious to a scientist who isn’t experienced with the system.

Liquid handlers are complex to reprogram: They require learning new, complicated, and often antiquated software. More than that though, they require a completely new way of thinking – describing their science in terms of a series aspirations and dispenses, liquid classes, and labware definitions, rather than describing it conceptually as they’re used to.

Liquid handlers are not trustworthy: at least not immediately. To get a new protocol working, most require testing on multiple levels – dry runs to check movements are correct, then more testing with water and the real reagents to check the liquid handling looks good – no dribbling or clogged tips with suspended material.

So what makes useful lab automation today?

Liquid handlers, and more integrated automation, have to be turned into boxes that function like PCR machines. Automation engineers must develop specific workflows on specific robots, perhaps with some known variables exposed to the user. When a scientist walks up with their samples, how to use and parameterise the system must be transparent, and they must trust it not to fail.

Just look at the plethora of ‘assay-ready’ ‘workstations’ that lab automation vendors sell. These are essentially pre-validated, pre-programmed versions of their naive robots, ready to do one thing, and one thing well. They’ve been PCR machine-ified.

We’re often asked for advice on how and when to start buying automation by startups who are getting their core processes up and running, and are thinking about scaling them up. I like to apply this PCR machine formula. Ask yourself honestly, which elements of your scientific workflow do you understand deeply enough that you can predict exactly how they will work, including all the flexibility you’ll need to build in?

This often requires patience – it means waiting for your scientists to validate and optimise their workflows, so you can be confident they know the different flavours and parameters they’ll need. And that a new project isn’t going to come along and completely derail it.

It also means, as a general rule, starting with individual liquid handlers is sensible, since it’s easier to find and automate smaller slices of your workflow, and build up your automation piece-by-piece, than it is taking longer, more complex ones, and trying to integrate steps together. There’s a good chance you’ll need to introduce changes which will mean going back into development and testing.

What about the future?

So that’s it, is it? Lab automation is forever confined to workflows that are very well understood, parameterised, and standardised? Well, honestly, if you’d asked me a few years ago, I’d have said yes. I’d caution most startups to think really hard before investing in any automation, because finding slices of their workflow that they deeply understand to this extent is hard when you’re still building your engine.

You could spend the same money on hiring a junior scientist for a year. A good one is guaranteed to actually pipette. Plus they problem solve, hypothesise, analyse data, and you can go get a pint with them after work. Without a solid idea of the application, liquid handlers aren’t even guaranteed to do a meaningful amount of pipetting for you.

But times are changin’ – I think there’s now a path to making lab automation as ubiquitous as the PCR machine.

This means solving the interface problem – allowing scientists to program robots in their language, not the robot’s. It means exposing the right level of flexibility to allow them to optimise and tweak. It also means rigorous validation and testing, before the scientist shows up, so that they can trust it’ll do what they ask of it.

Check out our demo of how Briefly tackles these issues below. If you’re interested in deploying this in your lab, get in touch!

Contact us

This is a question we get a fair bit. A common job for a scientist is reading a method documented in a paper, or a protocol in their ELN, and trying to get it to run for real.

With the advent of LLMs, we’ve had questions from folks wondering whether we could take these methods and translate them directly to robots to run. To cut out the tedious manual translation and wet lab validation that scientists must do during development, and get to an automated system that at least performs the correct actions, even if some of the specifics of the science need ironing out.

We’re not there yet, but thinking through why we aren’t can actually tell us a lot about what makes automating science hard, and more broadly, why reproducing science is a struggle. Let’s dig into it.

The moving target of protocol detail

A problem that every scientist is familiar with. Protocols are often insufficiently detailed to be run in precisely the way that was intended. This sounds like a simple problem with a simple solution – scientists should just include more detail when they document their experiments.

The trouble is that for manual science the ‘correct’ amount of detail is actually a moving target. Tell an experienced cell biologist to ‘Gently wash the HEK cells with PBS’, and that may well be all they need to know. They’ve handled mammalian cells before, so including more detail than this would seem redundant.

A molecular biologist who’s only worked with E. coli might need to know how much buffer, whether to gently aspirate, and how long to leave the buffer before removing it. A fresh graduate would need even more – perhaps a gentle reminder of their sterile technique!

And what does the robot need to know? Well, everything. It has no understanding of the science – it’s programmed purely mechanistically. It doesn’t understand how to handle mammalian cells, it doesn’t even understand the concept of gently. It needs a step-by-step guide with each and every variable spelled out.

When a scientist asks an automation engineer to automate their protocol, part of the job is extracting all of these details. Not just ‘which buffer do I use’, but also ‘what does gently really mean’? This requires conversations with the scientist – in order to bring together the scientist’s understanding of their process, with the engineer’s mechanistic knowledge of the automated system.

An AI can’t directly automate a paper for the same reason that scientists struggle to reproduce them – all the details compressed into “Gently wash the HEK cells” have to be unpacked. Even experts in cell biology will bring different context and assumptions to unpacking those details. An AI will do the same. It can take educated guesses at these specifics, but without an interface with the scientist, it’s very unlikely to be correct.

Onto another problem…

What can your equipment actually do?

Automated labs usually do not contain all of the equipment and capabilities of a manual lab. Without access to the same equipment, workflows need to be adapted to this equipment.

This happens in manual reproduction too – the reproducing lab often has different equipment than what was used in the original experiment. Changes range from simple tweaks, like matching the G-force on centrifuges with different rotors, all the way to developing an entirely different assay to overcome a missing channel on a plate reader.

When automating, adapting the protocol to the equipment is a huge part of the job. Moving from tubes to plates, switching from spin columns to mag-beads – these are concrete changes to protocols that scientists often wouldn’t consider when manually replicating someone else’s experiment.

To an engineer, some of these incompatibilities are immediately clear when reviewing their scientist’s protocol. Our workcell doesn’t have a centrifuge! Some are less obvious, and will only become clear once all of those hidden details are unpacked.

For an AI, making these adaptations is challenging. Context is key – the context of what equipment is present in the lab, and the constraints of that equipment. And even more tricky, the scientific (and economic!) context – a deep understanding of why protocols have been designed the way that they have been – does the scientist keep their reagent in a 1.5 ml tube because that’s how it was sent to them, or because it costs £1000 for 300 μl? If it’s the latter, the automator probably shouldn’t just dump that reagent into a single well reservoir.

Can an AI do anything to help?

An overriding theme here is translation – bridging the gap between scientific intent, and the concrete actions, functionality and constraints of each automated system.

Let’s start with unpacking that scientific intent. While an AI can’t know all of the detailed intention of the scientist, it can spell out the necessary details for automation and take an educated guess at what they might be. Then it can hand the reigns back over to the scientist to ensure the protocol matches their expectations.

Let me show you within the context of the example I mentioned above – washing HEK cells. The scientist starts with an instruction that makes sense to them – “Wash the HEK cells with PBS”.

The AI unspools this into mechanistic steps and parameters – based on its understanding of washing HEK cells. With all the details laid bare, our scientist can make adjustments from there to ensure it aligns with what they actually want to do.

And what about the constraints of the system? How do we can ensure that the instructions the scientist builds actually match what the system can do?

Constraints are defined by the engineer that built the automation – that could be the vendor or an internal engineer. These can then be applied to protocols in Briefly. The AI drafts protocols within these constraints – using only the steps and parameters that are allowed by the engineer. The scientist can tweak, but only inside these guardrails, ensuring that the steps they use have been tested and validated.

If a five minute incubation causes a little too much cell dissociation, they can simply tweak that parameter down. But if they want to chill their sample and their on-deck incubator doesn’t cool, then the tool will let them know. All these details can be ironed out without an engineer needing to be involved.

So while an AI can’t take a paper and run it on a robot, it does offer an opportunity to chip away at the wall that exists between scientists and automation, and get those idle robots running – not just for highly defined and parameterised workflows, but for the slippery stuff that has consistently evaded automation.

If you’re interested in using Briefly as an interface to your automation – either as a vendor integrating with us, or as an end-user interested in using this to power your automation, drop us your details below and let’s chat!

Let's chat

Last year, we attended SLAS. It was our first conference, and we were showing off the very first version of our product. Principally, it was a protocol builder. It used LLMs to take free text descriptions of methods, and convert these into a consistent structure, with steps and parameters explicitly documented.

We built this to help with reproducibility. To help produce consistent documentation that can be handed off from one scientist to the next more easily. At SLAS, we were somewhat inundated, not by scientists, or managers, but by automation engineers.

Although this protocol structure was not designed explicitly for automated systems, they saw potential in it that we missed. By starting to standardise how protocols are documented, we had taken one step towards tackling a key problem in lab automation: translating a scientist’s intent into a concrete automated process.

However, there was a core part of the puzzle missing. Without standardising the language of these protocols, and applying the constraints of automated systems, a protocol in Briefly could never be understood by automation.

This year at SLAS, we’re announcing our the next step on that path: automatic protocol validation, and adaptation for lab automation.

Before we go into that, a little context.

The complexity of lab automation software

Different automated systems have different ways of defining their protocols. They use different formats, different language, and have different constraints based on the specific constellation and configuration of equipment in that lab.

These wide ranging requirements end up in vendor software, which makes their interfaces unnecessarily complex for many applications. For example if you are running two plates per day, a scheduler that interleaves plates isn’t necessary. But interleaving plates is core to how many automation user interfaces are built.

This makes defining automated protocols really difficult without deep knowledge and understanding of your automated system. In practice this is the job of the automation engineer – working inside the lab itself, or at the automation vendor.

What’s the problem?

To build this automated system, huge time and energy is spent with scientists to understand and map the scientific workflow, adapt it to work with automated systems, then develop, and test these workflows. Depending on the complexity of the protocol, this can take weeks, months, even years.

This doesn’t have to be the end of the world – if that workflow is static. It can be run and run and investing that time ends up worth it.

But so much science isn’t static – it evolves and flexes as requirements change, projects move on, and methods are optimised. The scientists responsible for these changes don’t have the skills, or frankly the time, to make these adjustments.

This means that automation engineers need to be involved in even the smallest of changes. The time and effort spent programming and validating these changes means scientists often just move back to running things by hand and all the benefits of automation are lost.

A different model for lab automation

We think that a better model for lab automation exists – one that accommodates more of science’s fluidity. This model is built on more modularity and abstraction. Let’s walk through a simple automation task to illustrate.

Imagine you have a small work-cell, comprised of a liquid handler, an incubator and an arm. You have been asked to automate the growing and feeding of a particular organism. The protocol looks something like:

1. Grow for 24h

2. Add 50uL growth media

3. Grow for 24h

4. Add 50uL growth media

As the engineer, broadly you have two options. You can build and validate a system that runs the exact protocol above. Or you could build two reusable blocks: “Dispense media” and “Incubate”.

Developing the whole thing means you only have to validate it for this specific case. User interaction is simple – the scientist presses ‘go’ and it runs exactly as it was programmed. But if the scientist tweaks their protocol, they are powerless to change the automation without your help and without more validation, and they go back to running it manually.

Modularity brings flexibility

Taking the modular approach is harder up-front. You’ll need to design your building blocks and decide what level of control to expose to the user. For the dispense step, giving the users the flexibility to dispense a range of volumes, say, 1-100uL, means testing and validating the liquid handling across that range, and defining allowed labware that can handle it.

Having done the same work for the incubate step, you’ll need to validate these blocks together in various constellations and with varying parameter ranges in the lab. Only then can we can build the specific workflow that was requested.

This is more work, for sure, but this system has flexibility built-in. It allows for tweaks, adaptations and optimisations. The user can focus on variables that are relevant to the science without having to re-think and re-validate the rest of the automation each time.

This isn’t a new idea – these abstractions are being built. But much of the time, they are built for the engineer, to make their life easier as they develop and as the protocol evolves.

However, with a better interface for the scientist, we think there’s potential for these abstractions to empower scientists more directly.

A better interface with the scientist

As I mentioned earlier, automation software is not built for scientists. It does not allow them to work in a way that is familiar to them, or to focus on the steps and parameters of their protocol.

To empower scientists, we need something simpler. It must:

1. display the protocol in a way that makes intuitive sense to them,

2. actively help them to adapt their protocols to the language and constraints of the automated system,

3. accommodate the different constraints from different automation set-ups.

How this works in Briefly

Let’s go through an example of how to get a protocol ready for automation in Briefly, from start-to-finish. First, scientists can use Briefly to convert unstructured text-based protocols and into our structured, step-by-step format.

The constraints of any automated system can then be imposed onto these protocols. Once a protocol is imported to Briefly, it can be checked against these constraints. For example, if there’s a centrifuge step in the protocol but no centrifuge, Briefly will flag this to the user. If critical parameters aren’t defined, the user will be nudged to complete them.

This is a nice start, but it still leaves the user to fix all of these issues. To alleviate this, we allow AI to perform a first-pass at making the tweaks. Understanding the constraints, it can fill in the parameters where they’re missing, remove or re-word steps that don’t align with the constraints of the system.

Importantly, this is all transparent to the scientist. Each and every step in a protocol can have an impact on the resulting data. The scientist needs to understand exactly what is going to happen and retain agency and control over the design process.

This transparency is so often lacking in how automated protocols are developed today, since they are programmed by the automation engineer, in software that the scientist doesn’t understand.

Once the checks pass, the protocol can be sent to the scheduling software that runs a work-cell, or even used to run an individual device.

Come see our demo at SLAS

We’re demoing this at SLAS. Come see us at booth #1252, or at our partners Biosero at Booth #1330 and take a look for yourself. If you can’t make it, reach out! We’re looking for more automation vendors and teams to partner with on this, as well as end users to build alongside. Let’s chat!

Email us

So, what does your pipette tip box says about you?

I feel personally attacked. But how many of us are there out there?

OK. Not that many. Stop judging us.

Let’s learn a bit more about ourselves. Compared to the average scientist, jumbled pipette tip boxers are

• more intrigued by the outliers (+6%). Well maybe we have to be.

• more into their laptops than their pipettes (+7%)… To no one’s surprise.

• more likely to be late to the bus (+8%). Messy lab, messy life I guess.

  Thanks for reading Briefly Bio! Subscribe for free to receive new posts.

Back to the global analysis. What are we in science for?

We spend months, planning, designing, troubleshooting, and analysing experiments. It seems like the vast majority of us really just crave a clear answer to the questions we set out to answer

Interestingly though, when a fly does appear in the ointment and an outlier threatens our clear answer, a decent chunk (44%) of those hoping for clear answers can’t help but be curious about it. How did it get there? What’s its story? Why does it love my ointment so much?

The majority do just hate the fly though. Begone plot ruiner. For science’s sake, I hope they give it a fair trial before they exclude it…

How we approach science

So most of us want answers. How do we approach getting them?

Mostly, with due caution! Despite the majority preferring the pipette to the laptop, 62% still take the time to mull things over before rushing to test their brilliant new idea.

And what about once we have some data? With how much caution do we approach the results?

To the 42%… Well… Mayyybe there’s a band?. No judgement! But erm, maybe lets run it again to be sure? 😉

What about how you load your centrifuge?

Ask around your lab. Statistically, you probably know someone who has tried to develop an algorithm to solve The Balanced Centrifuge Problem. And by the looks of it, quite a few have found a solution too.

If you haven’t already, you can take the test here and find out your lab type. And no, it isn’t any more scientific than this analysis.

But yes, I still want to hear what result you got.

What do you think about when you read the words ‘reproducibility crisis’? Most think about academia. Papers showing that 80% of preclinical cancer papers that can’t be reproduced; publish or perish, the paper mill crisis, p-value hacking and photoshopped gel images. 

A system of incentives that rewards Impact to the exclusion of everything else. A peer review process that despite being ‘core’ to the scientific process, goes unpaid and doesn’t receive the attention it deserves. 

The pharma industry echoes these sentiments. A team at Amgen described ‘fundamental problems’ and ‘systemic issues’. To make things better, we’ll ‘require tremendous commitment and a desire to change the prevalent culture’. 

When you start reading about reproducibility, it’s easy to get sucked into this doom spiral. That our system of science is broken and getting out of it will require some huge restructure. A revolution.

Much of this criticism is valid; even vital. But it can make attempts to solve the problem feel a little, well… hopeless. And the situation isn’t hopeless - really it isn’t! But with many big hairy problems like this, to start making progress, it helps to zoom in and look practically at what is actually happening day-to-day.

To illustrate, let’s run through an example of some everyday experiment reproducing – common to both industry and academia alike and stripped of any questions of publishing or incentive structures. 

Scientist A has been developing an assay for a few months and has now become the de facto lab expert. They know all the quirks and tricks of the trade for running it and for producing those tight error bars. If someone wants that assay running, they ask Scientist A. 

What happens then, when Scientist A hands in their notice to move on to their next gig? Do we expect that Scientist B could just pick up their notebook and keep the assay running? Not likely.

To hand over a scientific workflow of any significant complexity, a detailed protocol will be required – all that knowledge spelled out completely. Alongside the protocol, Scientist A and B will meet up for a few run-throughs in the lab, to catch any of those important nuances that were forgotten in the written docs. Even then, with our expert hovering over, successful reproduction can still prove elusive. 

Bear in mind that in this scenario, we’re talking about the same lab. With the same reagents, the same equipment, in the same conditions. The only change being the hand on the pipette. There are no misaligned incentives here – everyone wants the experiment to work as quickly as possible. And yet… It's still hard. 

We started Briefly off the back of this fairly simple realisation: progress in science is being stunted because so few of us really know what the hell each other is doing. Junior scientists are struggling to figure out how their supervisor prepped that cell culture. Data scientists are analysing and modelling datasets, but don’t know precisely how they were generated. Projects are planned and funded based on snazzy data from a published paper, but with only a few sentences describing where and how that snazzy data came from.

The exciting part is that this is a problem that we can actually do something about. Thoughtful implementation of LLMs offer us a route to structured and standardised documentation of our workflows – in a way that doesn’t place a burden on the scientists doing the work. With our experiments documented completely and consistently, we’ll reduce the friction at every handover. When our experiments don’t work, we’ll have a solid grounding upon which to ask questions of our reagents, or of our experiment design, rather than digging back through the steps that were taken.

In the longer term, this standardisation could take us even further. These protocols could directly define workflows for lab automation. Or be aggregated to help us make better decisions about how experiments should be run. Or help us track how each and every experiment evolves over time. 

Fundamentally though, we’re convinced that we need to start with real transparency over how our experiments are being performed. This can serve as a foundation for tackling those other, messier problems of reproducibility. Because until we’re clear on what happened, how can we hope to understand why it happened?

If you feel the pain in communicating consistently about your protocols and experiments – we want to hear from you. Academics can use an early access version of our product for free. In a company? We’d love to partner with you to grease the wheels of your research. Either way, click the button below and we’ll be in touch.

Sign up

The location of these samples matters at the bench, because I need a map for my pipetting. It also matters downstream – when I’m analysing the data coming out the other end, I need to know all the conditions and metadata associated with each well.

Despite the contents of plates being the life-blood of the work of so many scientists, labs, and biotech companies, we still don’t have a good way of creating these maps at the source. 

On the one hand, we have sample lists. A table with a column for the coordinates in the plate, and columns for any other metadata that’s relevant – sample IDs, concentrations, volumes. They’re flexible and machine readable. They’re great for data scientists and automation engineers to wrangle into their analysis or development workflows. 

However, they’re just a data dump. This makes them painful to interpret and edit as a human. Seeing all of the data all at once makes finding a particular slice of information difficult, and editing error-prone. I can just feel my eyes glaze over looking at a table like this.

Also, the plate is a physical object in the real world. We need a visual to help us think through where things should actually be, as well as follow along while pipetting.

The other side of the coin is plate maps. These are often built in spreadsheets or tables, where each cell represents a single well. You can add sample names to each cell, and perhaps colour code them to visualise another layer of information – to show titration of a reagent, or highlight replicates.

These plate maps are pretty laborious to make, but they do at least visually represent what is in each well. 

However, as soon as I have more than one or two layers of information, there’s no way to document that third layer. I’ll have to create another, separate table to capture it. If I want to move samples around, these tables aren’t linked together, so I’ll need to go through every table individually and update the details and the colour coding. Annoying, and more chances to make a mistake. Ugh. 

This is clunky, but also from a data processing perspective, translating these maps into something that can be used for analysis is yet another job to do. It depends on how exactly this plate map was constructed in the spreadsheet, what the colour codes mean, where the headers are… 

We tried tackling this problem in our most recent update to our experiment builder. 

We started with a visual plate mapper. To make a simple, colour coded plate map, just drag over the wells and label them.

This information is synced with a table that summarises the data. Editing the plate map updates the table and vice-versa.  

Adding a new column to the table adds another layer of metadata, and I can now add this metadata into the same plate visualisation… where it should be. Here I’m titrating a target concentration down my plate.

If I make a mistake in my pipetting or just want to move some samples around, I can drag the contents of that well to another position. All that metadata stays linked together. 

Once the experiment is done and it’s time to analyse the data, it can be exported as a .csv in the sample list format I described earlier. 

This feature is now live in our Experiment Builder. If you’d like to try it, sign up! We’d love to hear what you think.

Sign up for early access

This is our first foray into capturing information in individual experiments. More is coming! 

Automating scientific workflows can sometimes feel like pushing a boulder up a hill. Just when you think you’ve got a handle on the workflow – that you’ve got all the parameters dialled in, another requirement appears out of nowhere, and the boulder rolls back down. As the iterations stack up, timelines extend, and patience from all sides starts to wear thin... 

In science, many things feel out of our control. That makes it even more important to have a firm handle on the things we can control. So, let’s break down the process by which a lot of automation happens. If we understand that and the sources of the inefficiencies, we can try to figure out ways to improve it.

The process

There are at least two people involved in the work. The person who developed the scientific process and the person who’s tasked with automating it. Below is a typical way it can happen: 

1. Sharing the workflow: A developing scientist sends our automation engineer a link to a document describing the workflow.
   These documents come in various shapes and sizes – wordy paragraphs, bullet lists, flow charts… whichever format has been most useful for the developing scientist.

2. Reviewing it: The engineer reads it through, focusing particularly on the protocol,  jotting down obvious questions:  What is missing? What is unclear? Wtf is p4480? 

3. Shadowing the scientist: The engineer might then shadow the scientist in the lab, focusing on understanding the protocol end-to-end, while disentangling any further ambiguities. 

4. Planning the big changes: With the workflow mapped, the engineer can start piecing things together and asking bigger questions.  Will an automated solution require changes that affect the science?
   A typical example could be changing from a centrifugation-based kit to using magnetic beads that can be manipulated on a liquid handler. 

5. Developing and iterating: With a grasp on the process, they’ll start actually developing the automation.
   As they do, more granular, automation-specific questions surface. How should the buffers be stored during a run? How long can this plate be left on the deck?   

This process is iterative, digging through how everything works and getting to grips with all the scientific constraints. 

It’s all in the interface 

Our main problem with this process is assumed knowledge. Automation engineers work with scientists with a diversity of backgrounds. One day it’s a molecular biologist, the next it’s a cell biologist. This means that everyone has different levels of understanding in their head that the other is not aware of, and all that information will be necessary to develop successful automation.

For example most cell biologists know that spinning down mammalian cells should be done gently. In their protocol, they might simply write “Spin down the culture”. An automation engineer (don’t look at me!), having only worked with bacteria in the past, may assume that the same speed can be used for all types of cells. 

By the same token, details that can be critical in getting a process automated won’t be obvious to the scientist. A scientist might assume that the centrifuge on the automated workcell spins just as fast as their manual benchtop one, when in fact, the automated ‘fuge is really only fit to clear samples of bubbles, and has no hope of pelleting cell debris.

Getting on the same page

When handing over a workflow then, we need to unfold as many of these hidden assumptions as we can. Unfortunately, both sides don’t know what they don’t know, and explaining every single detail risks us getting lost in the weeds. 

If there's time, shadowing in the lab is a great way of building up a solid understanding and a chance to ask practical questions. It doesn’t stop there, so below are some other things that I found helpful and that we now added to Briefly. 

Standardising protocols

A consistent format makes it easier for both sides to get a grasp of what exactly is happening in the lab. It makes it clear the types of information that should be shared, and takes the mental load off figuring out where that information will be. 

Getting everyone to write things up the same way requires time and effort, which can be a tough sell, especially to a scientist who has more experiments to run. 

To tackle this, we developed a clean, consistent format, and use LLMs to take care of translating unstructured text into this format. 

Collaborate on a shared artefact

Rather than having countless meetings and swapping documents back and forth, it’s more efficient to align over the same document, adding questions, comments, and execution notes that both the scientist and engineer can review and agree upon up front. 

All protocols in Briefly can be shared directly with a colleague, and you can collaborate with them directly in real time.  

Ask a third party to check for gaps and ambiguities

Some TechBio companies employ folks who bridge the gap between disciplines, like wet lab and dry lab, or bio and automation. 

What about using our friend AI as a helper that sits between the scientist and engineer? Have it point out gaps, or spot potential pitfalls. Think of it like a generalist that knows enough to check our work. 

Here’s a few examples using the AI copilot in our Experiment Builder. 

1. Ask it to look for missing parameters, leaving the values blank for the scientist to fill out. 

2. Ask it to look for potential mistakes that crept into the protocol and to add these as notes to review. I overdid my heat shock slightly? Oops, hehe.

3. Ask it to add notes that may be helpful to an automation engineer. It spots some important liquid handling constraints when washing cells.

These suggestions are made in the shared protocol itself. Both sides can act on any suggestions that are useful, and discard those that aren’t.

These are some things we have come up with so far to help the transition to automation. I really believe the work we do on the protocol early on sets us up for success in getting any automation over the line. If you have any general tips or perhaps ideas on how Briefly can do more for automators, I’d love to chat!  

Try out Briefly here!

In research methods, we have a lot of details. To make sure what you release out there can be reproduced, you need to add as much detail as possible. But the more detail you add, the less it feels like you are writing in English. And, when authoring methods sections myself, time and time again I compromised on readability in favour of completeness.

When reading a paper, processing those methods sections is no joke. I find my eyes running up and down the paragraph, struggling to understand the relationships and piece everything together. It's a mental workout to grasp what happened in the lab and how.

Consider this methods section example. Notice how long it takes you to understand it, how your eyes move across the text, and which details you notice first.

In this study, transfection was performed on HEK293 cells, which had been cultured to 70-80% confluency in a controlled environment at 37°C and 5% CO2. For this experiment, SiRNA was used, with Lipofectamine 2000 being employed in a 1:1 ratio. Both of these components were diluted separately in 100 µl of Opti-MEM. The mixture of siRNA and Lipofectamine, after being gently combined, was allowed to stand at room temperature (approximately 22°C) for 40 minutes to facilitate the formation of siRNA-Lipofectamine complexes. Meanwhile, the cell viability was assessed using a 0.4% trypan blue dye, using fluorescence microscopy at 560 nm excitation and 590 nm emission, establishing baseline health prior to transfection. The siRNA-Lipofectamine complexes were then introduced into the cells in a dropwise manner, ensuring even distribution. This introduction was followed by a 6-hour incubation period at 37°C, after which the medium was replaced with DMEM enriched with 10% FBS and 1% penicillin-streptomycin, to nourish and protect the cells post-transfection.

I usually start by fishing out the actions – and anchor there. Then, I look for the relevant parameters characterising the actions, e.g. at 37°C and 5% CO2. And, finally, move onto auxiliary information, like observations of the cells or vendor information.

Well, at least that’s what I try to do. Sometimes reading the extra fluff is easier because it feels more like a narration. So, my brain might take the path of least resistance and go to those bits of information first instead.

The extra level of complexity comes from the use of passive forms, e.g., siRNA was used, and from separating relevant information from the actual step, e.g., the 1:1 ratio mentioned before the mixing step. Let’s take our example paragraph again and highlight the main lab steps.

In this study, transfection was performed on HEK293 cells, which had been cultured to 70-80% confluency in a controlled environment at 37°C and 5% CO2. For this experiment, SiRNA was used, with Lipofectamine 2000 being employed in a 1:1 ratio. Both of these components were diluted separately in 100 µl of Opti-MEM. The mixture of siRNA and Lipofectamine, after being gently combined, was allowed to stand at room temperature (approximately 22°C) for 40 minutes to facilitate the formation of siRNA-Lipofectamine complexes. Meanwhile, the cell viability was assessed using a 0.4% trypan blue dye, using fluorescence microscopy at 560 nm excitation and 590 nm emission, establishing baseline health prior to transfection. The siRNA-Lipofectamine complexes were then introduced into the cells in a dropwise manner, ensuring even distribution. This introduction was followed by a 6-hour incubation period at 37°C, after which the medium was replaced with DMEM enriched with 10% FBS and 1% penicillin-streptomycin, to nourish and protect the cells post-transfection.

Now, let’s make the sentences active and reorganise the information.
We'll also start each step on a new line for easier reading.

Prior to transfection, we cultured HEK293 cells to 70-80% confluency in a controlled environment at 37°C and 5% CO2. 
We diluted siRNA and Lipofectamine 2000 separately in 100 µl of Opti-MEM. 
We gently combined mixture of siRNA and Lipofectamine at 1:1 ratio. 
We incubated the mixture at room temperature (approximately 22°C) for 40 minutes to facilitate the formation of siRNA-Lipofectamine complexes. 
Meanwhile, we assessed cell viability using a 0.4% trypan blue dye, using fluorescence microscopy at 560 nm excitation and 590 nm emission to establish baseline health prior to transfection. 
We then added siRNA-Lipofectamine complexes to the cells in a dropwise manner, ensuring even distribution. 
We incubated the mixture for 6-hour at 37°C. 
We replaced the medium with DMEM enriched with 10% FBS and 1% penicillin-streptomycin, to nourish and protect the cells post-transfection.

Okay, this is already much more readable. Skimming through this methods section, I can quickly get the gist. So even if I'm searching for a specific detail, I will roughly know where to look for it.

But how do we find those specific details? First, we probably formulate a request in our minds. For example, what ratio was used to mix siRNA and Lipofectamine? And then we look for it. So what if each step had a dedicated section for these key details, clearly labeled?

This feels a bit more queryable. You might notice some details are missing now, making the method seem dry. In every good method, there are free-text notes that provide additional context, like why a step is important, or how it is run. Let’s add a special field for those.

Now, it’s easier to navigate through the different parts and zoom into the relevant information. But there is one more piece missing – the “while”.

We all know there are plenty of wait times in the lab – and it always feels good to use those efficiently. But plain text lacks the means to show what steps can be parallelised. What if we visually connect steps that belong to the same process and indicate when different processes overlap?

We called this view a Tube Map [thought it looked familiar?].
Here, all the most important information [the lab actions] is discoverable when traveling along the Tube Lines. Once at the station, we can dig into more detail by sliding our eyes to the right. The less core the information is, the longer the travel distance from the station will be.

Now, when reading, we can layer the description on in any order or quickly zoom into just what we are looking for. And when designing our own method, we can optimise the parallelisation and add as much detail as we want – without sacrificing readability.

There's a catch, though. It does take substantially longer to categorise each detail and organise the information when creating a new method. And a couple of years ago, this would have been the end of the story. No one has the time to do all this legwork just to make the methods section look better.

But in our age of LLMs, the task of formatting plain text into a standardised representation becomes a piece of cake. And even though there are occasional mistakes here and there, the quality of the translation between plain text and the tube map format is pretty damn good. Check it out.

Honestly, this is the only way I read papers now.
And if you want to give it a go yourself, sign up here – and we’ll give you access to our alpha tool.

So how does great software get built? Is there anything we can learn as scientists to help us develop and maintain great methods and spend less time troubleshooting? We think version control – a key tool in grappling with code as it grows and evolves, could be particularly powerful if appropriately applied to scientific experiments.

Version control in software development

Let’s look at a simple example in software. A developer has built and released a janky version of their app. It gets the job done, but it’s slow, so they start working on speeding it up. They iterate on the code for a little while, making some tweaks here and there. When they come to run their new version, ah crap, these changes break the whole app, and worse, our software engineer has no idea why. This is not a reason to panic. Here’s why:

1. All of this development work is happening separately from the working app, on a  ‘branch’ – the old, slow, janky version may not be perfect, but it works and they can always get back there.

2. As our developer has been writing this code, they have been registering their changes (‘commits’) as they go along. Their version control system allows them to trace back through these changes, seeing how their code evolved during development, helping them figure out what may have broken it. If they’re stuck, they can always just revert back to a previous version and start again from there. 

Bringing version control to science

To us, some kind of version control has always felt like a natural fit for scientific experiments. We study complex interacting systems, where small changes in our methods can result in our experiments going awry in unexpected ways. Our experiments & methods also have a lineage, with each new design based on previous work. Version control could:

1. Help us separate development work from working methods. By developing or optimising methods on a branch, we can protect our most precious samples from unvalidated protocols.

2. Enable us to explore the lineage of our experiments - to see the evolution of each and every parameter and step and to understand how and why changes occurred. 

In short, it would give us the ability to time travel through our previous experiments.  We could spend less time leafing through countless notebook entries to figure out where things went wrong. Or how exactly we got that interesting result a few months back.

What’s stopping us?

When a developer looks back at a previous version of their software, they get the entire codebase as it was at that point in time. They can see each and every change that has occurred since then, and can piece together what might have gone wrong. 

Scientists on the other hand  have a lab notebook entry. As I discussed in a previous post, these are unstructured and rarely contain every detail of an experiment – documenting in this way is just an unrealistic amount of work.

The result is that many mutations in experimental design become invisible, and accumulate over time. They exist in a single lab notebook entry and in the head of the scientist. Some may be passed down from senior scientists to juniors. But there is no phylogeny – no record of where and why those changes first appeared, how old datasets were generated in the past, or whether certain tweaks are still relevant in the experiments we’re running now. 

Moving away from the notebook

To enable scientists to track how their experiments change over time, we need to move away from the free text lab notebook as the primary source of truth for tracking how our experiments were done. In its place, we need something that 

1. Facilitates and actively helps scientists to completely capture the details of each of their experiments.

2. Captures these details with a more consistent format and language, such that experiments can be compared directly, back-to-back.

3. Tracks these changes actively over time, experiment-by-experiment, so that scientists can revisit the full picture of an experiment at any point in the future.

How we get there

Again, we can look to software engineering for some inspiration. We have countless tools that actively help engineers write good quality code. One basic example is the code linter. Linters analyse and flag issues while you’re coding. This happens automatically, in the background. Oops you forgot to define this variable, close that brace, or flag that you’re writing in an inconsistent style. 

Today, AI-enabled tools like Github Copilot are taking things a few steps further – not just spotting semantic issues with what the developer has written, but actively drafting code for them based on their ideas and requests. 

We’re building something similar for scientists – a tool that takes scientists' ideas and works with them to create clear, consistent, complete experimental designs, spotting details that are missing (‘what CO2% are you growing these cells in?’), and suggesting potential issues and pitfalls (‘You’re using the wrong antibiotic for that plasmid!’). 

We think a tool like this could help us reach the consistent, complete experimental documentation I described earlier. With it, we can unlock version control for scientific experiments, tracking changes over time, and building up the phylogeny behind each method and experimental design.

Interested? We're looking for scientists who are searching for a better way to organise and track their experiments. We want to build this with you!

Sign up

Last time, I discussed that our lack of focus on the how of experimental biology is slowing our progress – blocking us from getting value from the mountains of biological data we’re generating, and adding frustration and inconsistency to life in the lab. 

This ‘how’ contains a lot of things – experimental design, lab process, automation, statistics… but here I’m going to focus on the sexiest of them all, and the one nearest and dearest to our hearts at Briefly: documentation. 

How exactly did you run that experiment?

In science, but especially in biology, every change to our experimental process can result in changes to our precious data. If we don’t document these changes fully, how can we be sure our experimental tweaks aren’t responsible for what we’re seeing in the data? And how can we expect someone else picking up this method to get to the same result?

I appreciate this is rather, erm, basic. In science, it is important to control variables and write down what you did. Welcome to high school! And yet, glance over at the methods section of any Shiny High Impact Journal and discover that, well, we don’t. 

Complex 1000-word protocols are routinely boiled down to a single sentence. "The cells were transfected.” We’re asked to either fill in the gaps ourselves, or send the author an email. 

Take a look at scientists’ lab notebooks and you’ll find the completeness and consistency of documentation varies wildly, depending on the individual, the lab, the company, whether the experiment worked or it didn’t… 

Challenges like these have pushed some companies to standardise and structure their lab processes – this currently being the only way to get complete control and visibility over how their experiments are being run.

So why don’t we just document more?

It’d be easy to stop here. To conclude that we have a cultural problem in science. To solve it, we need to establish standards and structure, improve education, and change incentives… But we’re not so sure.

Completely and consistently documenting every experimental detail is excruciatingly difficult. There is the pure volume of stuff to write, sure, but the scientist must also figure out where to stop - information that is obvious to them may not be to someone from a different lab or a different background. 

Not only is creating this documentation difficult, but truly complete protocols generally aren’t helpful for the scientist planning and running their own experiment. 

Let’s look at Nature Protocols, the gold standard.  Each and every step is painstakingly recorded. Thousands of words. Marvels of methodology. This is what we should all be striving for… Isn’t it? 

These documents may be helpful for a scientist coming at a technique completely blind, but they simply aren’t to the scientist who wrote them – quite the opposite. Critical details and variables are buried in an avalanche of text. Difficult to summarise, difficult to follow, frustrating to adapt and edit. Scientists simply don't have time to create docs with such limited value to their day-to-day work.

Naturally then, both in industry and academia, when faced with a deadline and another experiment to run, the vast majority will write up what they reckon is important, not everything.  And next year, many will find themselves re-running their experiments and struggling to remember exactly how they did it last time. 

Pestering scientists will not solve this problem – they already understand it, but they have to make tradeoffs.

Structured science

So how do we get ourselves out of this mess? As I touched on earlier, the approach many Techbio companies are taking is to build structure around their science. They take their critical lab workflows, then standardise, track, and automate the hell out of them. 

This means constructing rigid databases around wet lab processes. Experimental variables are predefined and tracked, while the rest of the workflow locked down in standard operating procedures and automation. 

This approach can work,  but it’s limited: 

• It’s expensive to set up: Companies must build digital infrastructure around their workflows. This means hiring data engineers, integrating deeply with wet lab and computational biologists, and building culture and systems from the ground up.

• It’s difficult to maintain: These systems can be brittle. Wet lab workflows in biology are rarely actually standardised. We’re not building cars here. When a workflow is adapted to a new project, all those databases, protocols and automation need updating too.

• It’s inappropriate for early R&D: Less established workflows are off limits – they change too much for this kind of standardisation and infrastructure to be worthwhile or practicable.

These problems make this approach a non-starter for academia and smaller companies, and extremely tough to implement at older companies where systems and culture are already established. 

A common language

We think there is a better way – a common, structured language to describe lab work. This language should make intuitive sense to scientists; it should be flexible. It should accommodate their latest experimental design while keeping track of all those pesky details. 

To get there, we need software that translates what we have today into this new language. Taking care of the formatting automatically, suggesting forgotten details, keeping track of all those calculations and dependencies, while helping find relevant methods to learn from that others have run before.

By introducing structure, we unlock different ways of viewing our experiments. When we’re setting up a new method from scratch, iterating on it for the 27th time, calculating a master mix composition, or running it in the lab – we care about different things. We should see the information we actually need to help us get our work done.

Where this can take us

By creating this common language, we can begin to truly build on top of, adapt and directly compare our experiments with others.

Imagine running your experiment, and getting an alert that someone in your department already ran it 2 years ago. Or even that someone is running something similar right now in Kyoto – maybe you could share some ideas and moral support?

How about having access to the combined wisdom of everyone who has run your method before  – choosing the enzyme they used, and avoiding that dodgy one that would have sent you down another troubleshooting rabbit hole. 

Imagine how much more efficient and reproducible our science could be if we stopped having to constantly reinvent the wheel.

This is the future we’re building towards at Briefly.

Are you also frustrated by how inefficient and messy doing science is today? We’re creating a place to meet and figure out how we can make things better. We can’t wait to meet you.

Sign up

“We need better data!” – a distressed call from a data scientist, presented with the latest csv from the plate reader. “There’s too much noise in these replicates! What are these controls? Why do they look different from last week?” 

These rumblings are growing louder around machine learning in bio. We have AlphaFold, sure, but protein folding is as close to physics as biology gets. What about the mess of interacting pathways that give us actual living systems? To model them, we need data that accurately reflects that biology, and getting that data is hard.

So much of the data we generate to explain biology are proxies, even proxies of proxies. Extracting meaning from this data means controlling for the noise in the biological system, but also having a deep understanding of the method that we use to generate that data. Without it, that data is just as likely telling us something about our method than the biology itself. 

Most wet lab biologists understand this intuitively. It gets to the root of why running these experiments is so flipping difficult. One week your experiment is working a treat, the next you’re bashing your head against the gel imager. Something must have changed in the method? But what?! There’s so many details to keep track of. Did I make a mistake? Why didn’t I think of that control? Maybe my enzyme went off? When I was in the lab, I always blamed the enzyme... it was never the enzyme. 

Figuring out, planning, and tracking the how of an experiment – the steps to follow in the lab, the calculations, the controls…  all this stuff really matters. It matters both to the grand future of biotech that we’re all excited about, and also to helping free scientists from the cycle of failed experiments and inconclusive results.

And yet, it feels as though very little is being done to help. Automation is often held up as the answer, but there is still so much science that is out of the reach of robots for now. Automation requires a known working protocol, but a lot of science is in flux – too changeable, too complex, too ill-defined. 

And what about software? We have tailor-made tools to help designers prototype and collaborate, developer tools that superpower engineers while they code… not to mention all the software built to help wrangle the data coming out of these experiments. Why not something to help design and capture those experiments? A word processor and a spreadsheet hardly feels like the answer.

We need to recognise that getting ‘better data’ means working together with scientists. Let’s take a fresh look at the process of designing and running experiments. How can we be more efficient, more effective, more reproducible? What tools could help us? What can we learn from other fields? Maybe there’s a world where waiting for the gel imager to load doesn’t have to be an emotional rollercoaster.

At Briefly, we’re building software for scientists to help tackle this problem; but we won’t get there with software alone. There are questions around lab tooling, process optimisation, statistics, collaboration… If you’re an experimental biologist who obsesses over the details of doing your science, we’re building a community of people like you so we can figure this out together. If you’re interested in joining us, head here and let’s chat.