robin

repository·main·Indexed 20 days ago

https://github.com/future-house/robin

A multi-agent system designed to automate scientific discovery, specifically for generating experimental assays and therapeutic candidates for diseases. It features a two-step asynchronous workflow consisting of experimental assay generation via the `experimental_assay` function and therapeutic candidate generation via the `therapeutic_candidates` function, configurable through the `RobinConfiguration` object.

Tokens
11.1K
Snippets
31
Records
45
Agent score
70%

What's inside robin

  1. Run the Robin Demo Notebook

    main

    To run the standard scientific discovery pipeline as described in the research:

    1. Launch Jupyter: Navigate to the robin directory and run jupyter notebook or jupyter lab.
    2. Open the Notebook: Open robin_demo.ipynb.
    3. Configure: Locate the RobinConfiguration cell and set your disease_name and (optionally) API keys.
    4. Execute: Run the cells sequentially to perform:
      • Experimental Assay Generation: Generates and ranks potential assays.
      • Therapeutic Candidate Generation: Generates and ranks candidates based on the top assay.
      • Experimental Data Analysis (Optional): If you have experimental data, this step uses the Edison platform to analyze it and refine candidate generation.
    jupyter notebook
  2. Install Robin via Python/uv

    main

    To install Robin directly in your local environment:

    1. Clone the repository:

      git clone https://github.com/Future-House/robin.git
      cd robin
    2. Create and activate a virtual environment: Using uv (recommended):

      uv venv .venv
      source .venv/bin/activate

      Or using standard venv:

      python3 -m venv .robin_env
      source .robin_env/bin/activate
    3. Install dependencies: Install the base package and development dependencies (including Jupyter):

      uv pip install -e '.[dev]'
      # OR
      pip install -e '.[dev]'
    4. Set API Keys:

      cp .env.example .env
      # Edit .env with your actual keys
    git clone https://github.com/Future-House/robin.git
    cd robin
    uv venv .venv
    source .venv/bin/activate
    uv pip install -e '.[dev]'
    cp .env.example .env
  3. Install Robin via Docker (Recommended)

    main

    Docker is the recommended approach to avoid OS-level dependency conflicts.

    1. Build the image:

      docker build -t robin .
    2. Set up API keys: Copy the example env file:

      cp .env.example .env

      Edit .env and fill in EDISON_API_KEY and OPENAI_API_KEY. CRITICAL: Do not wrap values in quotes (e.g., use OPENAI_API_KEY=sk-abc123, NOT OPENAI_API_KEY="sk-abc123").

    3. Run Jupyter:

      docker run -p 8888:8888 --env-file .env robin

      Use the URL provided in the logs that starts with http://127.0.0.1:8888/.

    docker build -t robin .
    cp .env.example .env
    docker run -p 8888:8888 --env-file .env robin
  4. Assay Proposal and Ranking Workflow

    main

    The system follows a pipeline to generate and select the best experimental assays:

    1. Literature Review

    Generates {num_queries} research queries to investigate the {disease_name} landscape, covering biochemistry, mechanistic underpinnings, and existing assays.

    2. Assay Proposal

    Generates {num_assays} distinct assay ideas. Output Format: A single JSON array of objects, each containing:

    • strategy_name: A simple name for the strategy.
    • reasoning: Scientific justification citing relevant literature.

    3. Hypothesis Evaluation

    Performs a literature review on a specific assay to evaluate its utility for {disease_name}. The response includes:

    • Assay Overview: Pathogenesis modeling, measurements, and biological materials.
    • Biomedical Evidence: Argument for central role in pathogenesis.
    • Previous Use: Historical drug discovery usage.
    • Overall Evaluation: Strengths and weaknesses.

    4. Assay Ranking

    Compares two proposals using a rigorous scientific framework. Output Format: A JSON object containing:

    • Analysis: Detailed comparison of the two assays.
    • Reasoning: Explanation of why the winner is superior.
    • Winner: A tuple (winner_name, winner_id).
    • Loser: A tuple (loser_name, loser_id).
  5. How therapeutic_candidates pipeline handles experimental insights

    main

    When the experimental_insights dictionary is passed to therapeutic_candidates, the pipeline modifies its behavior in several ways:

    1. Prompt Augmentation: The system messages for query generation and candidate proposal are appended with additional context derived from the insights (analysis_summary, mechanistic_insights, and questions_raised).
    2. File Pathing: Output files are saved to directories or with filenames containing the _experimental suffix (e.g., therapeutic_candidates_summary_experimental.txt instead of therapeutic_candidates_summary.txt).
    3. Literature Review Storage: Literature review results are saved to .../therapeutic_candidate_literature_reviews_experimental instead of .../therapeutic_candidate_literature_reviews.
  6. Therapeutic Candidate Generation Workflow

    main

    The system generates novel, testable drug candidates for a {disease_name}.

    1. Candidate Query Generation

    Generates {double_queries} research queries to investigate:

    • Target Validation: Pathway dysregulation.
    • Efficacy in Relevant Models: Evidence in cell/animal models.
    • Mechanism Confirmation: Engagement of the target.
    • Pharmacokinetics/Safety: ADME and safety profiles.

    2. Candidate Generation

    Generates {num_candidates} proposals. Output Format: A text block where each proposal is wrapped in <CANDIDATE START> and <CANDIDATE END> tags. Each block must contain:

    • CANDIDATE: The specific single-agent drug/therapeutic (including catalog numbers if applicable).
    • HYPOTHESIS: A mechanistic hypothesis of how it treats the disease.
    • REASONING: Detailed scientific rationale, evidence, and novelty.
  7. Requirement for therapeutic hypothesis generation with experimental data

    main

    Generating therapeutic hypotheses using experimental data requires access to the Finch data analysis agent.

    Note: As of the current documentation, Finch is in a closed beta. You must sign up to be a beta tester at bit.ly/finchbeta to use this specific capability.

  8. Chain-of-Thought (CoT) Analysis Workflow

    main

    The COT prompt template defines a structured, multi-stage reasoning process for creating scientific analysis notebooks. Each stage requires explicit reasoning within <analysis_planning> or <thought_process> tags before execution.

    Stages:

    1. List Directory Contents: Use list_workdir to organize the directory structure. Output results inside <directory_contents> tags.
    2. Load Data and Perform Descriptive Statistics: Identify relevant files, plan efficient loading (e.g., in R), and plan descriptive statistics (e.g., summary(), str(), head()).
    3. Develop Analysis Plan: Break tasks into testable components, select statistical tests/visualizations, and justify choices. Write the plan as comments in the notebook.
    4. Execute Analysis Plan: List specific functions/libraries to be used and execute the steps, creating new cells as needed.
    5. Conclude and Submit Answer: Reflect on results, limitations, and findings within <thought_process> tags.
  9. Configure Robin with RobinConfiguration

    main

    To initialize Robin, create a RobinConfiguration object by specifying a disease_name. This configuration object is then passed to various Robin modules to define the scope of the scientific discovery task.

    It is also recommended to set up a logger named robin with the level logging.INFO to monitor the multi-agent system's progress.

    from robin.configuration import RobinConfiguration
    import logging
    
    config = RobinConfiguration(disease_name="dry age-related macular degeneration")
    
    logger = logging.getLogger("robin")
    logger.setLevel(logging.INFO)
  10. Configure Robin for drug repurposing tasks

    main

    To initialize Robin, create a RobinConfiguration object specifying the target disease and the scale of the discovery process. You must also define the number of assays, candidates, and queries to be generated.

    Key configuration parameters:

    • disease_name: The target condition (e.g., "Non-alcoholic Steatohepatitis").
    • num_assays: The number of experimental assays to generate.
    • num_candidates: The number of therapeutic candidates to generate.
    • num_queries: The number of queries to perform.
    from robin.configuration import RobinConfiguration
    
    config = RobinConfiguration(
        disease_name="Non-alcoholic Steatohepatitis",
        num_assays=10,
        num_candidates=30,
        num_queries=5,
    )
  11. Workflow: Hypothesis Generation for Drug Repurposing

    main

    A standard drug repurposing workflow in Robin follows a two-step asynchronous process:

    1. Experimental Assay Generation: Generate assay goals using experimental_assay.
    2. Therapeutic Candidate Generation: Use the output from the first step to generate candidates using therapeutic_candidates.

    This sequence allows the system to first determine how to test for biological effects before identifying the specific molecules to test.

    # 1. Setup
    config = RobinConfiguration(disease_name="CKD", num_assays=10, num_candidates=30, num_queries=5)
    
    # 2. Generate Assays
    candidate_generation_goal = await experimental_assay(configuration=config)
    
    # 3. Generate Candidates
    await therapeutic_candidates(
        candidate_generation_goal=candidate_generation_goal, 
        configuration=config
    )
  12. Experimental Analysis Notebook Guidelines

    main

    When generating notebooks for scientific analysis, follow these structural and coding guidelines to ensure debuggability and reproducibility:

    Notebook Structure

    • Cell Size: Write small to medium-sized cells to facilitate easier debugging.
    • Bug Fixing: When fixing errors, edit existing cells by their index number rather than creating new ones.
    • Data Inspection: Always check dataframe shapes before printing. Use head() for large dataframes to avoid overwhelming the output.
    • Execution Flow: Ensure each cell executes successfully before proceeding to the next.
    • Environment: Assume necessary packages are already installed; only install new ones if errors occur. Use pip or mamba for installations.
    • Cell Types: All cells are by default {language} cells. You can use bash by adding %%bash to the first line of a cell or running a subprocess. Note that you can only create code cells, not markdown cells.

    R Programming Best Practices

    • Package Loading: Use the following pattern to minimize verbose output:
      if (!requireNamespace("package_name", quietly = TRUE)) {
          install.packages("package_name")
      }
      suppressPackageStartupMessages(library(package_name))
    • Tidyverse: Use the tidyverse suite whenever possible (dplyr, tidyr, ggplot2, readr, stringr, forcats, purrr, tibble, and lubridate).
    • Namespacing: Use explicit namespace qualification for functions (e.g., dplyr::select() instead of select()).
    • Plotting: All plots must be created using ggplot2.
    • Data Operations: To suppress messages about column name repairs when reading files, use .name_repair = "minimal":
      variable_name <- read_excel("<fpath>.csv", col_names = FALSE, .name_repair = "minimal")
    # Example of correct ggplot2 usage
    plot_data <- as.data.frame(dmso_data[, c("FSC-A", "SSC-A")])
    scatter_plot <- ggplot2::ggplot(plot_data, ggplot2::aes(x = `FSC-A`, y = `SSC-A`)) +
      ggplot2::geom_hex(bins = 100) +
      ggplot2::scale_fill_viridis_c(trans = "log10") +
      ggplot2::labs(
        title = "FSC-A vs SSC-A Density Plot (DMSO Control)",
        x = "FSC-A",
        y = "SSC-A"
      ) +
      ggplot2::theme_minimal()