LLMs and Protein Engineering: Building a Sustainable Materials Platform

cambrium · Tech · 2023 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Biotech protein engineering and internal research retrieval

Cambrium needed to design useful proteins for sustainable materials while making expensive wet-lab experiments and scattered research knowledge usable for a small scientist-facing engineering organization.

Constraints:

• Biological experiments are expensive, so lost or poorly captured data can force costly repeat lab work.
• The users are internal researchers rather than high-QPS external customers, shifting the main reliability constraint from serving latency to data preservation.
• Protein design searches an enormous sequence space where random amino-acid sequences usually do not produce useful function.
• Scientist notes, machine CSVs, Slack, and Notion knowledge had to be made queryable without turning the lab workflow into a generic consumer-scale application.

Architecture

Cambrium combined a pragmatic internal RAG assistant with a protein-design platform. The assistant retrieves across experimental data, Slack, and Notion to answer researcher questions, while the design stack uses a protein programming language, optimization constraints, and newer diffusion-style protein generation to choose candidates before expensive wet-lab validation. Reliability work centers on preserving every experimental data point and shaping lab workflows around digital data capture.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  Researchers["Researchers"] --> RAG_assistant["Research RAG assistant"]
  Slack_Notion["Slack and Notion knowledge"] --> RAG_assistant
  Experimental_store["Experimental data store"] --> RAG_assistant
  Researchers --> Protein_language["Protein programming language"]
  Protein_language --> Design_optimizer["Protein design optimizer"]
  Diffusion_generator["Diffusion protein generator"] --> Design_optimizer
  Experimental_store --> Design_optimizer
  Design_optimizer --> Lab_experiments["Lab experiments"]
  Lab_experiments --> Reliable_pipelines["Reliable data pipelines"]
  Robotic_workflow["Robotic lab workflow"] --> Lab_experiments
  Reliable_pipelines --> Experimental_store

Components

Data flow

Researchers ask an internal assistant questions; a LangChain-style RAG layer fetches from experimental data, Slack messages, and Notion pages, then returns synthesized answers. In the protein-design path, scientists express target biophysical constraints through a protein programming language or generative loss functions, computational models narrow the candidate sequence space, and selected proteins move into lab experiments whose machine and scientist outputs are captured by reliable data pipelines.

Why this architecture

Cambrium optimized for experiment de-risking and data integrity rather than consumer-scale serving. A RAG assistant was enough for internal research search, while protein-specific languages and generative models let the team convert scientific intent into constrained computational search before paying for lab validation.

Models used: LLMs · LangChain stack · diffusion models · protein AI models

Scale

• Cambrium was a three-year-old Berlin biotech startup when describing the system.
  “Cambrium is a three-year-old biotech startup based in Berlin that uses AI to design proteins which become sustainable materials.”summary, stated
• The NovaColl product reached market in under two years.
  “that's also how we manag to basically um take a product to market to in in less than two years right”transcript, stated
• The protein design search space was roughly 10^18 possible proteins before computational narrowing.
  “it allowed us to sift through all might need to 10 10 to the 18 different possible proteins right and we got like you know like a top 100 and another top 100”transcript, stated
• Computational de-risking was described as raising experiment success from about 1% to 10%, 50%, or 75%.
  “we're making a lot of experiments maybe you know 1% is successful and if you we use computers including machine learning LMS and so on like all of a sudden we manage to like crank up to like 10% success 50% success 75% success”transcript, stated

Alternatives considered (roads not taken)

Optimize for low-latency, high-QPS model serving

Rejected because: The production constraint was not serving millions of external requests; the critical risk was expensive experimental data loss and scientific workflow reliability.

Random wet-lab trial-and-error over computational candidate narrowing

Rejected because: Random protein exploration has very low success rates and makes each failed lab experiment expensive; computation improves the odds before testing.

Treat the RAG assistant as a standalone external SaaS product

Rejected because: Cambrium valued the assistant as a quick internal search tool but was skeptical that generic RAG front ends alone create enough external business value.

Patterns

rag-retrieval (retrieval)

Cambrium used a LangChain-style internal assistant to retrieve from experimental data, Slack, and Notion so scientists could query scattered company knowledge.

tool-use-orchestration (agent-architecture)

The internal assistant orchestrated retrieval across multiple internal systems rather than relying on one static document store.

structured-output-contract (integration)

The protein programming language acted as a structured intermediate representation for scientists to express protein properties and constraints as an optimization problem.

data-quality-loop (data)

Cambrium treated experimental data capture and preservation as the central operational loop because each lab datapoint is costly to recreate.

synthetic-data-generation (modeling)

The diffusion-based design path generates candidate protein structures with desired properties before laboratory validation.

Tradeoffs

Optimize the platform around experiment de-risking

Chose data integrity and computational candidate selection over low-latency or high-QPS model serving.

Rationale: Internal scientists were the users, and the dominant cost was repeating expensive experiments if data or candidate selection failed.

Use a domain-specific protein language before newer diffusion-generation methods

Chose constraint programming for NovaColl and diffusion-style generation for later products over direct natural-language prompting as the only design interface.

Rationale: The protein language converted scientific requirements into mathematical constraints before LLM-era generative models became the main design path.

Start with cosmetics before commodity sustainable materials

Chose high-value cosmetics such as NovaColl over immediately targeting lower-margin plastic replacements.

Rationale: Cosmetics offered a more practical first market while the long-term sustainability vision required further scale and economics.

"They started with cosmetics because:

• High price elasticity and innovation hunger in the industry • Faster regulatory pathways compared to medical applications"

Gotchas (what bit them)

Data loss is much more expensive in wet-lab ML than in typical web analytics pipelines.

Root cause: Each biological datapoint comes from DNA handling, robots, consumables, and experiment time rather than cheap user telemetry.

Resolution: Prioritize robust data pipelines and data models even though the serving workload does not need consumer-scale QPS.

Scientist-authored experimental notes are harder to operationalize than machine outputs.

Root cause: Biology training and lab habits were slower to adopt data-first digital workflows, leaving people and paper/process habits as the hard data source.

Resolution: Hire for data-driven mindsets, use robots to free scientists' hands, and train scientists to record experiment settings digitally.

Generic RAG can be useful internally while still being overhyped as a standalone product.

Root cause: A well-engineered retrieval assistant solves internal knowledge access, but that does not automatically prove external SaaS value.

Resolution: Use the assistant pragmatically as a quick internal MVP and keep value claims tied to concrete research workflows.

Evaluation

Cambrium evaluates the system primarily through wet-lab success, product commercialization, data preservation, and whether internal researchers can retrieve useful experimental knowledge; the transcript does not describe a formal LLM evaluation harness for the RAG assistant.

Metrics: experiment success-rate improvement from roughly 1% toward 10%, 50%, or 75% · ability to bring NovaColl to market in under two years · successful retrieval of latest products or high-performing lab protein entries · avoidance of lost experimental data

Outcomes

• Cambrium brought NovaColl, a vegan human collagen cosmetic ingredient, to market in under two years.
• Computational protein design helped narrow roughly 10^18 possible proteins to lab-testable candidate sets.
• The internal RAG assistant gave researchers quick access to experimental data, Slack, and Notion knowledge.
• The platform reframed Cambrium's LLMOps priorities around data integrity and experiment de-risking rather than QPS.

This is an internal scientist-facing biotech platform rather than a large public SaaS service; the meaningful scale is product commercialization speed, protein search-space reduction, lab data cost, and scientist workflow coverage.