Biotech Drug Discovery AI Needs Institutional Memory
A practical Connectory use case for biotech and drug discovery teams that need shared org memory, PR evidence, and agent governance across scientific software.
Drug discovery companies should use Connectory when the risk is not one model prediction, but the organizational chain behind it. AI is already showing up across the drug product life cycle, and FDA says CDER has seen a significant increase in submissions using AI components across nonclinical, clinical, postmarketing, and manufacturing phases [1]. The hard problem is no longer "can an agent edit a pipeline?" The hard problem is "can the organization prove which assay definition, model context of use, owner, SOP, validation expectation, and prior decision governed that change before it merged?"
That is a Connectory problem. FDA and EMA's 2026 good AI practice principles point drug developers toward human-centric design, risk-based controls, clear context of use, multidisciplinary expertise, data governance, documentation, life cycle management, and clear information [2]. FDA's 2025 draft guidance also centers AI credibility on a specific context of use, not on a generic claim that a model is accurate [3]. Connectory maps to the control gap between those expectations and the software work that changes discovery pipelines: Genie institutional memory, RepoWatch, OrgWatch, SlopBuster review, Guardian gates where configured, and advisory MCP checks.
Where Connectory Fits In Your Scientific Stack
Your scientists and engineers may already rely on RDKit, DeepChem, Schrödinger, Benchling, Dotmatics, an ELN, a LIMS, notebooks, a model registry, and an internal workflow engine. Connectory works alongside these systems. It does not replace the scientific tools your teams use to run experiments, manage data, or develop models.
Connectory is designed for CTOs, VPs of Engineering, Heads of Data Platform, Heads of Computational Biology, and compliance leaders who are accountable for the software layer that turns scientific work into repeatable decisions. It helps you keep assay assumptions, data provenance, model intent, ownership, and approval evidence aligned across teams, repositories, and systems.
Pistoia Alliance framed the current bottleneck well in June 2026: AI models can generate predictions faster, but without standardized, context-rich, integrated datasets, reliable outcomes remain hard to scale [4]. A later Pistoia poll found that 27% of life-science professionals do not know what scientific content their AI or LLM systems use, and 50% identified lack of shared verification standards as the biggest barrier to agent adoption [5]. Those are not only data science problems. They are institutional memory problems.
Why Existing Tools Leave A Gap
A strong biotech engineering group can solve many local problems without Connectory. It can build CI checks, add CODEOWNERS, enforce unit tests, require model cards, write SOPs, run Great Expectations, use MLflow, manage workflows in Airflow or Nextflow, and protect branches in GitHub.
Those are necessary controls. They are not a shared memory control plane.
The gap appears when scientific intent crosses tools. The assay protocol may live in the ELN. Raw results may live in the LIMS. Normalization rules may live in a Python repo. Feature definitions may live in a data platform repo. The model card may live in a registry. Approval context may live in a ticket. The reason a principal scientist allowed an exception may live in Slack.
Existing systems can each be correct and still fail the organization:
| Existing Tool | What It Handles Well | What It Cannot Do Alone | Connectory Role |
|---|---|---|---|
| ELN or LIMS | Scientific records, protocols, samples, assay outputs | Govern a pull request in a different repo when assay interpretation changes | Carry the current assay decision into review |
| Model registry | Model versions, metrics, artifacts, cards | Ensure an API or data transform still matches approved context of use | Store context and expose it to reviewers and agents |
| GitHub branch protection | Required reviews, status checks, merge rules | Know whether the right scientific owner reviewed the change | Connect people, repos, teams, and policies |
| Data quality tools | Schema checks, null checks, distribution checks | Explain the scientific meaning of a field or why an exception exists | Preserve the decision and rationale as org memory |
| Wiki or SOP library | Human-readable policy | Apply that policy automatically to every future PR and agent plan | Turn prose into typed, reusable memory |
| Local coding-agent files | Repo instructions for one agent session | See all repos, all owners, and decisions outside the current checkout | Give agents an org-level advisory surface |
This is the part most companies cannot maintain by hand unless they choose to become a software governance vendor themselves. A wiki can explain the rule, but it cannot make every future coding agent ask the rule before planning. A model registry can store model metadata, but it cannot stop a pull request in a different repo from violating an assay constraint. A Slack answer can unblock the current incident, but it does not become durable evidence for the next review.
Composite Example: Kinase Discovery Program
Consider a composite oncology biotech prioritizing kinase inhibitors. No proprietary source code is needed for the example.
The program spans seven practical surfaces:
1. Assay results arrive from a CRO into LIMS.
2. Scientists review plate-level quality and annotate exceptions in an ELN.
3. Data engineers normalize assay values and publish curated datasets.
4. Computational chemists generate fingerprints and molecular descriptors.
5. ML engineers train ranking models and uncertainty estimates.
6. Platform engineers deploy an internal scoring service.
7. Program leads use model output during weekly candidate review.
Now add coding agents. One agent edits the ingestion connector. Another writes a transform for a new assay format. A third updates feature generation. A fourth changes the scoring API. Each change can look reasonable in isolation. The scientific risk appears only when the changes are read together.
The practical question is not whether engineers can review code. The better question is whether the review process can see the same scientific and organizational memory that the program depends on.
In this example, Connectory would capture a small set of high-value memory objects: the current assay interpretation, the approved context of use for the ranking model, the scientific owner for each target family, the exception policy for low-quality plates, the data split rule for retrospective validation, and the evidence path that must be preserved for IND-supporting work. That memory then shows up where software is approved.
What Connectory Adds With Existing Tools
Connectory adds the shared operating layer around discovery software, not a replacement for scientific systems.
Genie is the institutional memory. It stores the people, teams, projects, sources, beacons, questions, events, and relationships that define how the organization works [9]. In a biotech setting, those beacons can represent approved assay assumptions, model context of use, data restrictions, validation expectations, program ownership, and known scientific caveats.
RepoWatch understands each repository before review. That matters when a discovery program has ingestion jobs, feature pipelines, scientific libraries, internal APIs, dashboards, and infrastructure repositories. The same change pattern may be harmless in a prototype notebook and unacceptable in a pipeline feeding candidate selection.
OrgWatch keeps the cross-repo people picture current. It helps leaders see contributor patterns, bus factor, quality trajectory, and human versus agent activity. In a biotech, that exposes the painful cases: one computational chemist is the only person who understands a descriptor library, or agent-heavy changes are concentrating in a regulated evidence path.
SlopBuster is the review surface. It uses live organizational context when a pull request is opened or updated. The review can ask whether a change matches the repo, the program, the policy, and the prior decision, not only whether the code compiles.
Guardian is the enforcement surface where a policy requires a block, approval, or exception record. Advisory MCP tools let coding agents ask the organization before they act, using checks such as check_idea, check_plan, and check_code without allowing the agent to mutate the graph.
Biotech teams can use the same review surfaces to keep repository-specific policies and decisions close to the pull request, so researchers and engineers can see the context behind a review.
Review-Time Evidence Matrix
For biotech leaders, the useful product story is not "Connectory writes better code." It is "Connectory makes the right organizational memory available at the moment code is approved."
| Biotech Question | Memory Needed | PR Evidence To Capture | Connectory Surface |
|---|---|---|---|
| Does this transform preserve the approved assay interpretation? | Assay decision, owner, exception notes | Finding, reviewer action, linked policy | Genie plus SlopBuster |
| Is this model still being used in the approved context of use? | Model purpose, target population, output use | PR comment, approval, exception reason | Genie plus Guardian |
| Did the right scientific owner review the change? | Person, team, project, repo relationship | Requested reviewer and outcome | OrgWatch plus review metadata |
| Is an AI agent changing regulated evidence paths? | Human, agent, and hybrid contribution signals | Author pattern and risk tier | OrgWatch plus Guardian |
| Are we repeating a solved pattern from another repo? | Repo purpose, shared utility, accepted convention | Finding that points to existing pattern | RepoWatch plus SlopBuster |
| Can compliance read the story without installing a coding tool? | Policy, decision, event, question, result | Dashboard state and audit trail | Genie dashboard |
This aligns with FDA's risk-based credibility framing. Even when a discovery tool is not itself submitted to FDA, the same discipline is valuable: define the purpose, preserve evidence, manage changes, and show who was accountable [3]. FAIR data principles reinforce the same direction: data should be findable, accessible, interoperable, and reusable, but that also requires people, policies, identifiers, and stewardship to survive beyond one notebook or one team [7].
A 30-Day Pilot Plan
Start with one discovery program, not the whole company. Pick a pipeline where software changes can alter scientific interpretation: assay normalization, feature generation, cohort selection, model scoring, or candidate ranking.
| Week | Work | Output | Connectory Tool |
|---|---|---|---|
| 1 | Identify critical repos and owners | Project, repo, team, and owner map | OrgWatch and RepoWatch |
| 1 | Capture current scientific decisions | Assay policy, model context, data restrictions | Genie beacons |
| 2 | Connect review to highest-risk repos | PR findings grounded in program context | SlopBuster |
| 2 | Define required approval paths | Merge rules for assay, model, and evidence changes | Guardian |
| 3 | Let agents ask before writing | Plans checked against org memory | Advisory MCP checks |
| 4 | Run an evidence replay | One change traced from policy to PR to approval | Genie dashboard and review history |
The pilot should answer four questions:
1. Can a reviewer see the relevant scientific decision in the PR?
2. Can an agent check its plan against the current policy before writing?
3. Can leadership see bus factor and agent activity around the discovery program?
4. Can compliance reconstruct why a high-impact change was allowed?
If the answer is yes, the organization has more than local automation. It has a working memory loop.
Frequently asked questions
Is this only for regulated software?
No. The strongest starting point is any discovery workflow where software changes can alter scientific interpretation. Regulated evidence paths raise the stakes, but the memory problem starts earlier.
Does Connectory replace LIMS, ELN, model registry, or data catalog tools?
No. Those systems remain the systems of record for scientific data and workflows. Connectory preserves the organizational memory around them and uses it during review, merge decisions, leadership visibility, and agent guidance.
Why not just write better SOPs?
SOPs are necessary, but they are prose. Connectory turns decisions, owners, exceptions, policies, and questions into typed memory that can be read by reviewers and agents at decision time.
Does Connectory need to store our source code?
No. Connectory is designed for security-sensitive engineering organizations and does not need to store source code permanently to preserve org memory, review evidence, and governance context [10].
What is the strongest first use case for a biotech?
Start with an AI-assisted assay normalization or model scoring pipeline. Those workflows have clear owners, clear scientific risk, and enough cross-repo activity to show why local review is insufficient.
Summary
Biotech and drug discovery companies do not need Connectory because they lack scientific tools. They need Connectory because their most important software decisions sit between scientific systems, engineering repos, AI agents, reviewers, and compliance owners.
The existing Connectory toolset gives them a practical control loop. Genie stores the organization's scientific and engineering memory. RepoWatch and OrgWatch keep repository and people context current. SlopBuster applies that memory in pull request review. Guardian enforces the rule when review needs a gate. Advisory MCP checks let agents ask the organization before acting.
That is the part a biotech usually cannot build for itself without turning a discovery software team into a governance platform company. The business value is not another coding assistant. It is shared memory that governs the software changing the science.
References
[1] FDA, "Artificial Intelligence for Drug Development," accessed August 10, 2026. https://www.fda.gov/about-fda/center-drug-evaluation-and-research-cder/artificial-intelligence-drug-development
[2] FDA, "Guiding Principles of Good AI Practice in Drug Development," January 2026. https://www.fda.gov/about-fda/artificial-intelligence-drug-development/guiding-principles-good-ai-practice-drug-development
[3] FDA, "Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products," January 2025 draft guidance. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological
[4] Pistoia Alliance, "From Data Access to Data Readiness," published June 18, 2026. https://pistoiaalliance.org/resource-library/from-data-access-to-data-readiness/
[5] Pistoia Alliance, "1 in 4 Life Sciences Professionals Do Not Know What Data Their AI Models Use," December 3, 2025. https://pistoiaalliance.org/news/1-in-4-life-sciences-professionals-dont-know-what-data-their-ai-models-use/
[6] Pistoia Alliance, "Pistoia Alliance Unveils Agentic AI Initiative and Seeks Industry Funding to Drive Safe Adoption," September 4, 2025. https://pistoiaalliance.org/ai/pistoia-alliance-unveils-agentic-ai-initiative-and-seeks-industry-funding-to-drive-safe-adoption/
[7] Wilkinson, M. D. et al., "The FAIR Guiding Principles for scientific data management and stewardship," Scientific Data, 2016. https://www.nature.com/articles/sdata201618
[8] FDA, "Part 11, Electronic Records; Electronic Signatures - Scope and Application," September 2003 guidance. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application
[9] Connectory, "Organizational Memory (Genie)." https://www.connectory.ai/memory
[10] Connectory, "Privacy Policy." https://www.connectory.ai/privacy