Production AI in biotech is often framed as a model-selection problem: choose a foundation model, connect a vector database, add a chat interface, and iterate on prompts. That can produce a compelling demo. It does not produce a dependable scientific system.
The more useful architecture question is: where does the workflow cross a boundary that can invalidate the result? In scientific software, those boundaries are everywhere—identity, evidence, orchestration, reasoning, controlled action, human review, and feedback.
The model is one component in a decision system
Consider a seemingly simple request: “Which formulation performed best, and why?” The answer may depend on assay results, formulation metadata, experimental conditions, document versions, outlier handling, historical context, and the scientist’s definition of “best.” A language model can synthesize evidence, but it cannot make missing system boundaries disappear.
A production architecture therefore starts with a decision loop:
scientific question
→ authorized evidence
→ retrieval + structured data
→ context construction
→ model reasoning
→ claim verification
→ human review
→ controlled action
→ feedbackBoundary 1: identity and authorization
Authentication at the chat interface is insufficient. Authorization has to survive retrieval. If a user is not permitted to read a source document, the retrieval layer cannot allow the model to see it merely because the embedding is semantically relevant.
This pushes permissions into the evidence plane: document ACLs, row-level constraints, tenant or project boundaries, and version-aware access checks should participate in retrieval itself. The architecture should make it impossible for a later prompt instruction to “undo” an access decision made earlier.
Boundary 2: evidence and provenance
Similarity is not evidence. A useful scientific RAG system should preserve source identity, document hierarchy, section, version, timestamps, and enough context to let a reviewer inspect the basis of an answer. Provenance should be attached to claims, not sprinkled onto a paragraph after generation.
The system also needs a concept of evidence sufficiency. Sometimes the correct behavior is not a fluent answer; it is an explicit abstention because the retrieved material does not support the requested conclusion.
Boundary 3: orchestration and state
Once an AI system uses tools, it becomes a workflow system. The question is who owns state. My default is that probabilistic components may propose what should happen next, while deterministic software owns durable state transitions.
That separation makes retries, recovery, auditability and human approval tractable. It also prevents a model from becoming the accidental source of truth for a long-running process.
Boundary 4: reasoning and structured output
Model reasoning should be constrained by explicit contracts. Use schemas for classifications, comparisons, extracted claims and tool requests. Validate outputs before they cross into deterministic services. Structured output is not merely developer ergonomics; it is an architectural control surface.
Boundary 5: action and consequence
Reading is different from writing. A system that summarizes experimental evidence has a different risk profile from one that updates records, schedules work or changes a downstream workflow. Consequential actions should be narrow, typed, permission-aware and idempotent where possible.
Human-in-the-loop design should therefore be placed at consequential boundaries rather than bolted onto the end as a generic “approve” button.
Boundary 6: feedback and evaluation
A production system needs two feedback loops. The first is engineering: latency, errors, retrieval misses, tool failures and cost. The second is task quality: groundedness, completeness, reviewer disagreement, override behavior, abstention quality and whether users return to manual work.
That second loop matters because adoption is diagnostic. If scientists repeatedly export results into spreadsheets or manually re-open the same source documents, the system is revealing an architectural gap.
Reference architecture
User / application
↓
Identity + policy
↓
Workflow orchestrator ─────→ durable state
↓
Permission-aware retrieval ─→ structured scientific data
↓
Evidence assembly + provenance
↓
Model gateway / structured reasoning
↓
Claim checks + evaluation hooks
↓
Typed tools ───────────────→ deterministic services
↓
Human review at consequential boundaries
↓
Telemetry + quality feedbackTradeoffs I would make explicit in an architecture review
- Freshness vs. indexing cost: which sources need near-real-time availability and which can tolerate batch ingestion?
- Recall vs. review burden: aggressive retrieval may increase coverage while making evidence inspection harder.
- Agent flexibility vs. determinism: open-ended planning increases capability but expands the failure surface.
- Latency vs. verification: reranking, claim checks and secondary evaluators cost time; decide where that cost is justified.
- Central platform vs. workflow-specific products: standardize primitives, not every user experience.
What I would deliberately not build first
I would not start with a general-purpose autonomous agent for “all scientific work.” The risk surface is too broad and the evaluation target is too vague. I would choose one expensive decision, build the smallest vertical slice through the real evidence and permissions stack, and instrument the failure modes before widening autonomy.
Production AI is not a model surrounded by APIs. It is a decision architecture in which a model is one reasoning component.
That is the lens I would use for AI architecture in biotech and life sciences: optimize the full workflow, make evidence inspectable, make state explicit, and make failure behavior part of the design.