GARSGitHubGitHubJavier Rodríguez Hernáez

Genomics analysis an AI agent can run and a scientist can check.

GARS lets an AI agent run real genomics pipelines inside a folder of written rules: tested code does the computing, a scientist makes the decisions, and each project keeps an append-only record of every step and the model that took it. On public data, the three comparisons scored so far (of six) reproduce the published results, and it flagged a failed replicate the paper's depth-only QC could not have seen.

Javier Rodríguez Hernáez · formerly Senior Bioinformatics Programmer, NYU Langone (2018–2026). I designed the contracts, the wrappers and the gates; Claude Code drove them, and every agent run here but the live lane is recorded.

Checked against published dataA run can finish cleanly and still be wrong.

One library in a published ChIP-seq study had plenty of reads but almost no signal. The paper's QC reported only read depth, and by depth it looked fine. GARS's QC step flagged it, and the authors' own deposited data agrees.

Peaks per million reads, from GARS's pipeline QC, on one scale

Peaks per million reads, from GARS's pipeline QC, on one scale04,0008,000flagged library1,007the other three7,487–7,742

Why it matters: A library like this passes a depth check and pulls its group's average down. On the authors' own track, the gap between the two cell lines on GARS's simple measure holds only while it is counted.

The evidence, and the one-command recompute

How GARS works

The agent guides. Tested code computes. You decide.

GARS at a glance
  1. You ask

    your question, your sequencing data

  2. GARS: a folder of written rules

    1. The agent guides

      asks for what's missing

      Claude CodeCodex
    2. You decide
      • design
      • reference
      • comparison
      • plan
    3. Code computes

      tested scripts; pinned pipelines wrapped as skills

  3. A result you can check

    with its record

Checked against the real world: on public data, GARS's results are scored against what the original authors deposited

One GARS project, start to finish

you ↔ the AI agent

Your guide at every step

You ask in plain words. The agent reads the stage's written rules, tells you what comes next, asks for what's missing, runs GARS's registered tools and reports what they returned, errors included.

Every stage runs inside written rules, code checks and your checkpoints.A guard checks the agent's file and shell calls before they run: the shell runs only GARS's registered tools and read-only commands, and writes to the system's own files are refused (Claude Code sessions in gars/).

  1. 00codeyou

    Register the data

    Scripts register your files and check them; you confirm the sample IDs before anything is linked.

    An input fails a check: the script refuses and nothing runs. The refusal comes from code, not the model.

  2. 01youcode

    Describe the design

    You fill in the study design; code checks it before any compute.

    A decision is missing: the run stops and asks. A blank group is never guessed from sample names.

    A confounded design is refused before compute.

  3. 02you choosecode computes

    Run the pipelines

    You pick the reference from the genome registry and the comparison from a menu built from your design. A versioned wrapper runs an established pipeline, such as nf-core, at a pinned version; each tool runs in its own container.

    Code computes, not the agent.

    A check fails: the wrapper reads what came back, and the step is marked failed, not complete.

  4. 03you approvecode

    Plan, approve, analyse

    Analyses beyond the standard pipelines run from a written plan bound to its exact bytes: the executor submits the agent's scripts only while the plan's recorded approval holds, and editing the plan afterwards voids it. The approval itself is a rule the agent follows, not yet a lock it cannot reach.

Every stage writes to the project's own record

Your decisions · generated settings · each step's status · every pipeline-stage output with its checksum · a history kept append-only by written rule, each entry naming the model when the agent reports it.

Plain files that outlast the conversation; a new session starts from them.

Underneath: plain files you can read, diff and pin

  • Rules you can read

    Each stage's contract is a markdown file in a git checkout, so a change to a rule is a diff you can review.

  • Pipelines you don't rebuild

    Wrappers pin established pipelines, and each tool runs in its own container.

  • Where it runs is a setting

    Chosen in the workspace's settings, not written into the workflow.

Check it yourself

  1. Read what the agent may not do.
  2. Try to break a rule; the guard refuses, with no AI in the verdict.
  3. Watch code refuse a confounded design.
  4. Watch the agent stop for a person (opens at the gate): a recorded agent session stops at the exclusion confirmation; code refuses to write the samplesheet until the run carries the confirmation flag.
  5. Follow the failed replicate to the authors' deposit and the recompute command.

Or clone it and run the tests.

Where it's going

AI agents can now run a genomics analysis fast; checking their work has not kept up. GARS is built for the checking.

Next, not claimed until shown

GARS moves trust out of the model and into rules and code wherever it can; where the rules are silent, the model still matters, and GARS's own Gap Study measures how much. The runs so far used Claude models.

What GARS rests on, and where each part stands

  1. proven

    Rules as files

    The agent's rules are markdown files in the folder you clone; each stage's contract says what the agent may not do there.

    proof: recording → · the rule: document →

  2. proven

    Code computes, the model navigates

    The rules require derived files to come from deterministic scripts that refuse bad inputs; the model reads the rules, runs those scripts and reports what they returned.

    proof: recording → · proof: test →

  3. proven

    You approve the science

    Scientific choices wait for a person: in the recording, the design table and the exclusions each stop the run until someone answers.

    proof: recording →

  4. partial

    Every run recorded

    Each project's history is kept append-only by rule, and each entry is required to carry a model line, which says unknown rather than guess; whether a re-run gives the same answer is not measured yet.

    proof: test → · not yet: table →

  5. partial

    Checked against published data

    Pipeline output is scored against what the original authors deposited, and rows not yet scored stay in the table, marked as such.

    scored and not yet scored: table →

The folder is the system

  • CLAUDE.mdClaude Code's entry point; Codex reads AGENTS.md, in GARS today
  • 02_bioinformatics/chipseq_bulk/…/CONTEXT.mdwhat the agent may not do here
  • _system/wrappers/…/SKILL.mdthe pinned wrapper

    CreditWrappers modelled on ClawBio's open bioinformatics skills.

  • projects/epigenome-a/HISTORY.mdappend-only memory
  • projects/epigenome-a/…/STATUSthe only authority on state
  • projects/epigenome-a/…/OUTPUTS.tsvoutputs, by type

Context layers

Context is layered, so an agent loads only what the current task needs:

Layer 0AGENTS.mdCLAUDE.mdOrientation.
Layer 1CONTEXT.mdRouting.
Layer 2<stage>/CONTEXT.mdThe stage contract.
Layer 3_references/_templates/_system/a project's _config/Domain knowledge, stamps, runtime and settings.
Layer 4stage outputsWorking artifacts.

CreditGARS's premise, carried through every layer of the system, follows the Interpretable Context Methodology by Jake Van Clief and David McDermott (arXiv:2603.16021).

The full architecture: stage flow and who writes each folder →

Source on GitHubthe README's Architecture at GARS d6963f7, on GitHub ↗

A real project folder (nf-core test data, run by a script, not the agent): it shows the process, not a finding.

Open the folder