Building Reliable LLM Workflows in Biotech Research

moderna · Healthcare · 2026 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.5 (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: Regulated biotech research and documentation workflows

Moderna's research data science team needed to help scientists automate low-value but correctness-sensitive documentation and analysis work in a regulated biotech environment without overusing autonomous agents or introducing uncontrolled data-security risk.

Constraints:

• Most internal LLM applications are protected workflows rather than true autonomous agents.
• Regulatory documentation work involves source PDFs, curated reports, intents, and target formats that must be transformed correctly.
• Regulated data cannot simply be copied into S3 buckets, vector stores, fine-tuning pipelines, or trace logs without preserving authorization.
• Permission mapping spans Active Directory, Okta, internal identity systems, and vendor-proprietary systems.
• Evaluation rigor must match consequences, from low-stakes commit messages to patient or regulatory outcomes.
• Production systems should prefer reliable simpler methods over novel LLM or agent designs when simpler methods work.

Architecture

Moderna's pattern is a protected workflow architecture, not an autonomous agent architecture. Humans curate source documents and declare intents; command-line tools read those documents, Python reports, and intent files; LLM steps draft regulatory-style documentation or reformatted outputs only where simpler Python or ML is insufficient. A non-LLM filter routes work from simple Python to simple ML to LLMs and avoids agents unless autonomy is genuinely necessary. Regulated data movement is guarded by permission mapping across source systems, destination stores, vector stores, model artifacts, and LLM traces. Evaluation is consequence-based: low-risk outputs can use repeatable human vibe checks on curated input sets, while clinical or regulatory outputs require stringent evals and error-mode characterization. Rapid experimentation and deployment use tools such as Marimo notebooks and Modal, but GxP validated systems may require internally hosted models rather than external APIs.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  research-scientists[Research scientists] --> curated-source-documents[Curated source documents]
  research-scientists --> intent-declarations[Intent declarations]
  curated-source-documents --> permission-mapping-layer[Permission mapping layer]
  curated-source-documents --> documentation-cli[Documentation CLI]
  intent-declarations --> documentation-cli
  python-reports[Python reports] --> documentation-cli
  documentation-cli --> non-llm-filter[Non LLM filter]
  non-llm-filter --> llm-drafting-step[LLM drafting step]
  llm-drafting-step --> trace-logging[Trace logging]
  llm-drafting-step --> evaluation-suite[Evaluation suite]
  permission-mapping-layer --> trace-logging
  permission-mapping-layer --> model-artifact-store[Model artifact store]
  model-artifact-store --> llm-drafting-step
  experimentation-stack[Experimentation stack] --> documentation-cli
  evaluation-suite --> documentation-cli

Components

Data flow

A scientist curates source PDFs or reports and declares the intended document. The documentation CLI reads those source documents, Python reports, and intent declarations, then uses the non-LLM filter to decide whether simple Python, simple ML, or an LLM is justified. If an LLM is used, permission mapping must carry source-document authorizations into downstream storage, vector stores, model artifacts, and trace logs. Outputs are evaluated with a curated input set whose formality depends on consequences: quick repeatable human judgments for low-risk commit messages, stringent evals and error-mode characterization for clinical or regulatory outputs. Experimental tooling can be packaged in Marimo or deployed with Modal, while validated regulated systems may need internally hosted models.

Why this architecture

Moderna avoids autonomous agents because its valuable use cases are structured, correctness-sensitive workflows, not real-time customer-service autonomy. The non-LLM filter removes stochasticity where deterministic code or simple ML is enough. Permission-aware architecture dominates because regulated documents, model artifacts, vector stores, and traces can all leak protected information. The evaluation layer is consequence-aware so low-risk tools can move quickly while patient- or regulator-facing outputs receive much stronger validation.

Models used: GPT-4o for an existing git commit message writer baseline · GPT-4.1 mini considered for a cheaper commit-message model · Open-source internally hosted LLMs for potential GxP validated systems · Simple ML models before LLMs when possible · Fine-tuned LLMs as a last resort for regulated document style or performance

Scale

• The research data science team has six people.
  “There are six of us in total. So, myself and five others.”transcript, stated
• The GPT-4.1 mini model switch was motivated by an 80% cost reduction.
  “slightly less accurate, slightly less powerful, but 80% cheaper model.”transcript, stated
• For a low-stakes commit message, a bad output might confuse someone for two minutes.
  “Someone's maybe going to be confused for 2 minutes in the future looking at the commit history”transcript, stated
• A hypothetical RAG-to-fine-tuning threshold is whether humans can offload work in 95 to 98% of cases.
  “allow a human to go off like offload work from a human in 95 to 98% of the cases.”transcript, stated
• Existing non-LLM chromatography models can fail 2 to 5% of the time, and sometimes 50% in difficult chemistry.
  “our custom algorithms and machine learning models still suffer from a 2 to 5% failure rate and sometimes depending on the chemical analyte and it's sometimes 50%”transcript, stated
• Modal deployment of a Marimo notebook can be done in about 10 minutes in the speaker's experience.
  “deploying Marimo like 10 minutes and you're done.”transcript, stated

Alternatives considered (roads not taken)

Build autonomous agents for the internal use cases

Rejected because: The business problems are better served by protected workflows and tool use; autonomous agents are rarely necessary.

Reach for an LLM or agent first

Rejected because: Simple Python or simple ML removes stochasticity and failure points when it can solve the problem.

Switch the commit writer from GPT-4o to GPT-4.1 mini immediately

Rejected because: The cheaper model needed a repeatable eval against representative git diffs before the model change could be accepted.

Use fine-tuning before retrieval and prompting

Rejected because: Fine-tuning is treated as a last resort for cases where RAG cannot reach required performance, internal hosting is required, or regulatory style must be learned.

Rely on prompts alone to enforce authorization

Rejected because: Prompt-based security is only one layer, and system prompts can be jailbroken when leakage probability must be near zero.

Patterns

privacy-preserving-processing (security)

Regulated source-document permissions must be preserved across buckets, vector stores, model artifacts, and LLM traces.

eval-driven-development (quality)

Model and workflow changes use curated input suites, side-by-side comparisons, human judgment, or stringent evals depending on consequence.

model-routing (modeling)

The team explicitly gates model changes, comparing GPT-4o and GPT-4.1 mini on representative diffs before accepting a cheaper model.

rag-retrieval (retrieval)

RAG is considered before fine-tuning for regulated document knowledge, but the same permissions and trace-access problems apply to vector stores.

fine-tuning-adaptation (modeling)

Fine-tuning remains an option for internally hosted regulated systems when RAG cannot produce enough hands-off performance or regulatory style.

batch-offline-processing (workflow)

The main production use case is structured document reformatting and drafting, where humans provide curated sources and intents for an offline CLI workflow.

Tradeoffs

Use protected workflows instead of agents

Chose Structured LLM workflows with human-curated sources and intents over Autonomous agents with broad tool-choice autonomy.

Rationale: The biotech use cases do not need real-time autonomous action; reliability and regulatory fit matter more.

Automate intellectual drudgery

Chose Document reformatting and regulatory drafting workflows over High-autonomy scientific decision-making.

Rationale: The value is freeing humans from tedious reformatting while letting scientists retain source curation and intent control.

Run a non-LLM filter before using generative AI

Chose Simple Python, then simple ML, then LLM only when needed over Defaulting to LLMs or LLM agents.

Rationale: Simpler methods remove stochasticity and reduce production failure points.

Delay an 80% cheaper model switch until evals run

Chose Side-by-side evaluation on representative diffs over Immediate cost-driven downgrade from GPT-4o to GPT-4.1 mini.

Rationale: The model was cheaper, but the team wanted repeatable evidence that output quality remained good enough.

Use fine-tuning only for constrained regulated cases

Chose RAG and prompting first, fine-tuning as a last resort over Fine-tuning as the default way to adapt models.

Rationale: Fine-tuning may be necessary for internally hosted GxP systems or regulatory drafting style, but it brings artifact-permission and hosting complexity.

Gotchas (what bit them)

Permission mapping becomes the dominant implementation problem.

Root cause: Data moves from regulated source systems into new buckets, vector stores, models, and logs while identity systems vary across Active Directory, Okta, internal systems, and vendors.

Resolution: Treat authorization propagation as a business-process and security-design problem before training or embedding regulated data.

Fine-tuned model artifacts inherit ambiguous access rules.

Root cause: A model trained on documents with different permission sets may probabilistically reveal information from any source document.

Resolution: Resolve who may access model artifacts before fine-tuning across permission boundaries.

LLM traces can leak regulated source information.

Root cause: RAG and fine-tuning logs contain data derived from original documents, while trace viewers may not share the same authorization set.

Resolution: Govern trace access as carefully as source-document, vector-store, and model access.

Novel agent designs add stochasticity and failure points without necessarily adding business value.

Root cause: The work can often be done with protected workflows, simple Python, or simple ML rather than autonomous tool choice.

Resolution: Apply the non-LLM filter and escalate only when simpler methods are inadequate.

Low-formality evals do not transfer to high-consequence outputs.

Root cause: A bad commit message is cheap, but a clinical or regulatory output can affect patients or product approvals.

Resolution: Scale from repeatable vibe checks to stringent evals and error-mode characterization based on consequence.

External API models may be unusable for GxP validated systems.

Root cause: Validated regulated systems may require internally hosted model weights even if API models perform better on long-document drafting.

Resolution: Use APIs for early baselines, but plan for internally hosted open-source models and possible fine-tuning when validation demands it.

Evaluation

Moderna's evaluation stance is consequence-based. Every workflow needs a curated, reusable input set; low-risk tools can use repeatable human judgments or side-by-side comparisons, while clinical and regulatory workflows require stringent evals, error-mode characterization, and ongoing expansion of edge cases. Model changes, such as moving from GPT-4o to GPT-4.1 mini, are checked against representative diffs before rollout.

Metrics: Curated input-set coverage · Human pass/fail or quick snap judgment for low-risk outputs · Side-by-side output quality under GPT-4o versus GPT-4.1 mini · Error-mode characterization for high-consequence outputs · Consequence level of a bad LLM output · Human offload target such as 95 to 98% of cases for a potential fine-tuning need · Failure rates from comparable custom algorithms, such as 2 to 5% or higher in difficult chemistry

Outcomes

• The audit found no true internal agents by Anthropic's workflow-versus-agent definition.
• The dominant deployed pattern is protected workflow automation for document reformatting and regulatory-style drafting.
• The team uses a non-LLM filter to reduce stochasticity and avoid unnecessary agents.
• Permission mapping, artifact access, and trace access remain unresolved regulated-environment challenges rather than solved technical details.
• The source does not report measured time savings, production usage volume, regulatory submission outcomes, or accuracy benchmarks for the documentation workflows.

Concrete scale includes a six-person research data science team, an 80% cheaper candidate model, two-minute low-stakes commit-message impact, potential 95 to 98% human offload threshold for fine-tuning, and observed 2 to 5% or sometimes 50% failure rates in comparable non-LLM scientific automation. No production document volume or latency is reported.