AI for life sciences software
SequoiaAT builds AI software for life sciences products and workflows. We work with computer vision on biological images and language models for research and clinical text. Around the model, we build the application, data handling, review flow, and testing needed to make it part of a working product.
The software around the model
Most of the work is around images or text. We use vision models on biological images and language models on scientific and clinical text. The output might be a score, structured data, or something a specialist needs to review. We build the rest of the application around it, including the data handling, workflow, review step, audit trail and controls.
A model working in a notebook is only one part of the job. We then have to get it into the application, connect it to the data and workflow, and make sure people can review the result.
Cleaning a reference table nobody could clean by hand
On a patient platform for allergic contact dermatitis, we used language models to reduce an ingredient reference table from about 140,000 names to about 40,000 standard INCI entries. One pass separated combined strings. Another mapped each name to its standard form. Rules handled the straightforward cases, but a long tail still needed more work. We flagged those mappings for review before they could be used in a patient's safe list.
Scoring biomarkers on tissue slides
On a digital pathology platform, computational models score HER2, Trop2 and CD8 staining. The pathologist reviews the result in an interactive viewer. Known slides are replayed after changes, so a change in score is caught before release.
Where the person makes the decision
What happens next depends on the workflow. On one system the model produces a measurement for a pathologist. On another it proposes an ingredient mapping that stays unapproved until someone clears it. An automated action needs more care because there is no one there to catch a bad result.
The software produces a number or marks a region, and the person using it makes the decision. Slide scoring is one example. The measurement needs to be consistent, and validation needs to show that it is accurate and repeatable.
The software puts a result in front of someone who accepts or rejects it. Ingredient mapping works this way. New mappings stay unapproved until an administrator clears them. The review happens in the application.
The software takes an action without someone checking it first. That needs more scrutiny in a life sciences setting. When a client wants that kind of automation, we look at what happens when the model is wrong, what can be affected, and what needs to be recorded.
As the software takes on more of the workflow, we add more testing, review and traceability around it.
Choosing the model
OpenAIAnthropicLlamaQwenDeepSeekRetrievalDocument level accessWe work with models from OpenAI and Anthropic, and with models such as Llama, Qwen and DeepSeek that can run inside a client's environment. The choice depends on where the model will run, the kind of data it will see, latency and cost, and the accuracy the application needs. Life sciences data can be idiosyncratic, so we work through those details before picking the model. For a narrow task, the pragmatic choice is often a smaller model. There is little reason to run a larger one if it does the same job.
For applications that answer questions over documents, we normally put a retrieval layer in front of the model. It finds the relevant passages and sends only those passages to the model. Document level access control limits the answer to material the user is allowed to see. Knowledgewise uses this pattern and runs inside the client's environment rather than as a shared service.
For images and structured data, we record the input, model version and output. That gives each result clear provenance and makes it possible to trace it back to the source data.
Model selected, product still to build
We build the viewer, pipeline, review flow, audit trail, and the integrations needed to fit it into the systems the team already uses.
From prototype to the application
The prototype may already prove that the model works. We then put it into the application, deal with the error cases, define how the result is reviewed, and handle deployment and the evidence required for the environment.
The software is headed for regulated use
Our regulatory and validation work runs alongside the build. A reference set is replayed as the software changes, and the results are kept with the release evidence.
GXPFORGE, OUR OWN VALIDATION PLATFORM. REQUIREMENTS, TEST EXECUTIONS, COVERAGE AND DEVIATIONS IN ONE PLACE. READ ABOUT GXPFORGE
Who we work with
Our work includes a research organisation at a large pharma, pathology and tissue analysis companies, cancer diagnostics companies, and a medical society with a patient facing platform. We add models to existing pipelines and build products where AI is central to the workflow. We do not name clients on this site.
Computer vision for biological imaging
Software that helps specialists review biological images and find the features they need to see.
NLP and research intelligence
We extract structured information from scientific text so researchers can search it and work with it.
Generative AI in research workflows
Large language models for research workflows, with controls for sensitive and regulated data.
Computer vision is covered in more detail under Digital Pathology and Imaging.
Knowledgewise
Knowledgewise lets people search and ask questions over a client's own documents. It runs inside the client's environment, with access control at the document level.
Read about Knowledgewise
A web, iPhone and Android platform for allergic contact dermatitis patients, with language models cleaning 140,000 ingredient names down to 40,000 INCI entries.
Read the case study →Questions people ask
Do you build models or integrate them?
We usually integrate an existing model and build the software around it. We train from scratch when there is a clear reason to, but most projects use fine tuning, prompting, retrieval and validation.
How do you validate an AI component for regulated use?
We validate the model step as part of the software around it. A reference set contains known inputs and expected outputs, and we replay it whenever the software changes. The results are kept as evidence, with our regulatory and validation team involved when the work is headed for a submission.
What happens when the model is wrong?
Some outputs will be wrong. The system needs a way to catch them before they are used. Depending on the workflow, that may be a review queue, a flag, or a threshold that sends the result to a person. On the dermatitis platform, new ingredient mappings stay unapproved until an admin clears them.
Have image or text data your team cannot get through by hand?
Tell us what you are working with, where the data sits, and who needs to review the result.
Start a conversation