Got a genomic question but no bioinformatics team? Nemotron agents on Nebius, powered by NVIDIA Parabricks, take raw DNA to an answer. Watch the whole Run as it happens; approve at the key points.
Inspiration
I'm a bioinformatics researcher. For years I've been the person behind the genetics in other people's research: the Python analysis that answers the genetic part of a study that isn't mainly about genetics. More and more studies, in many fields, need genetic evidence and genetic verification. Sequencing has become dramatically cheaper. The bioinformatics hasn't: it is still slow, specialised work.
I wanted a tool where a researcher can verify facts from a paper, or check the specific variants their study needs, and get the answer back with observable evidence, quickly and cheaply.
Even a simple question needs a chain of specialised stages:
choosing the right reference genome and a variant-calling recipe; aligning the reads and calling variants on a GPU in the cloud; resolving loose variant names against public databases (one name can hide two different letter changes, or have been merged into another); reading the VCF without over-claiming (a variant missing from the VCF does not mean the sample doesn't carry it). Today that researcher could hand the job to a coding agent, and it would probably come back with an answer. What they wouldn't get is observability:
which reference it used, and who chose it; which allele it meant; whether a missing record was read as "not carried"; where exactly it went wrong, and a way to fix that one step without starting over. The researcher is left with an answer they can't inspect and a chat log they can't check. Finding the variant is easy. Trusting the answer is the work.
So Traceome isn't a smarter agent. It is a pipeline where every step is on a record the agent cannot rewrite and the researcher can always read, and where the researcher decides at the points that matter.
What it does
A researcher asks a question, cites a paper or names the variants, and uploads the raw reads. Traceome then runs five stages:
Plan (Nemotron). A planning agent identifies the reference genome and retrieves everything the alignment needs, ready for NVIDIA Parabricks. Align and call (Parabricks). Once the researcher approves the plan, Parabricks runs as a Nebius Serverless AI job on an H100, aligning the reads and calling the variants. The output files are verified before anything builds on them. Investigate (Nemotron). An agent looks up each variant with tools such as NCBI and EVA, and turns loose names into exact Work items for the researcher to approve. Findings (code + Nemotron). Each Work item gets exactly one answer from the sample's own data: observed, not carried, no VCF record, or unresolved. "No record" is never turned into "not carried". When the agent runs into a conflict, it brings it to the researcher to resolve, and only that item waits. It's a collaboration. Report (Nemotron). An agent presents the results and writes a report of the findings in plain words. It may cite only approved facts, and every citation opens that fact in the Journey. The Journey sits under all five stages. Every model call, tool call, approval and file is a fact, stored once and never changed:
one human-genome Run recorded 1,834 facts and 337 files, all re-verified; the researcher reads it while the Run happens and afterwards; the agents read it too. Correct or fork.
At each approval the researcher can do more than say yes: approve some items, amend a target, reject one, or stop and still get an honest report. After the Run, fork starts a new branch from a finished Run with zero new external calls, leaving the original untouched. One variant, traced from reads to report In development Run H, rs4149056 was one of 24 requested identifiers on HG001, the public Genome in a Bottle reference sample. (Background, not a Traceome finding: this SLCO1B1 variant is widely studied for statin side effects.)
The planner identified GRCh38. Parabricks ran on one H100 in about 9.5 minutes. The investigation planner found rs4149056 at NC_000012.12:21178615, reference T, with two alternate alleles, so it became two Work items, T>A and T>C. An older ID the researcher also listed, rs60037639, had been merged into it by dbSNP; the same two items serve it. The sample's VCF has a T>C record: genotype 0/1, depth 26, quality 99. So T>C is observed and T>A is not carried. The table reader also flagged two more records within 100 bases. The explainer wrote: "…the exact T>C allele at 21178615 is carried (heterozygous 0/1), while the T>A target at that same position is not carried.
The Journey: one record for the agent and for you What goes in. Every model request and reply, every validated tool call, every source retrieval, every approval and every published report is a typed fact. Every file is stored under the SHA-256 of its bytes. Run H's record. One human-genome Run recorded 1,834 facts of 65 kinds and 337 files. All 337 addresses re-verified with 0 mismatches. The researcher reads it. The GUI, observe and journey-feed read it during the Run and afterwards, without contacting anything or changing a byte. The agents read it too, through a search_journey tool. Run H made 12 such reads. Junctions: approve, correct, or fork Three approvals gate the consequential steps: the compute proposal, the Work items, and the report basis. Each binds the exact object by its digest and records what it authorises and what it does not establish ("scientific validation: not established by this decision"). More than yes or no. In development Runs the researcher has: approved a subset while others waited; revised a proposal; amended a target; rejected an extra target; stopped the Investigation and still received an honest report of what was and wasn't done. Fork. A finished Run is not a dead end. fork copies the parent's exact prefix into a new child Run. It makes zero external contacts and leaves the parent byte-for-byte unchanged; the child needs its own approvals. Two examples: One Fork amended two targets the parent had left unresolved, and both became observed findings. All 186 parent files were hash-identical before and after. Another Fork reused the parent's verified H100 outputs, skipping about 38 minutes of planning, approval and GPU, and reproduced all 29 outcomes.
How we built it
The agents decide; code copies. The work splits in two:
Deterministic. NVIDIA Parabricks does the alignment and variant calling. Our own code reads the VCF, hashes every file, and assembles the report. Agentic. NVIDIA Nemotron makes the judgements that change from question to question: which reference to plan for, which record a loose variant name means, and how to explain the findings. The rule between the two halves is simple. An agent chooses which tool to call and what it means. Whatever a source returns is copied into the record exactly as the source wrote it, never generated or rewritten by the model. Each source's original answer is kept beside the typed result copied from it. When an agent names a value, it must cite the record or the quote it took it from, and code checks that the citation is real. The researcher approves, and the Journey keeps all of it.
Layer What Reasoning NVIDIA Nemotron 3.5 Super VL through the Nebius Token Factory API. One model for every agent role: planner, investigation planner, table reader, report explainer, paper reader. Compute NVIDIA Parabricks pbrun germline as a Nebius Serverless AI job on an H100 Storage Nebius Object Storage: a fresh bucket per Run; large outputs downloaded in parts and verified Sources NCBI (Datasets, E-utilities, genomes FTP, assembly reports, dbSNP RefSNP, Variation Services for SPDI and HGVS), EVA (European Variation Archive), Europe PMC and PMC Open Access for papers, and the Galaxy Project's prebuilt reference indexes. Every lookup is a recorded contact. Agents Pydantic AI; each role is offered only its own typed tools Record The Journey file: append-only, immutable facts, plus files stored once under their SHA-256 Interfaces A GUI for researchers, so no technical skill is needed, and a CLI underneath it. Today the GUI replays recorded Runs; running new Runs from it is next. The loop every agent runs. The agent picks its tools; code owns everything else:
a call to a tool the role wasn't offered is refused; duplicate calls in one reply collapse into one; a call that repeats an earlier one with nothing changed is stopped; a malformed answer gets a short repair note, a bounded number of times, and is then refused; an accepted answer stays a proposal until the researcher approves it. Two Runs, by the numbers (development Runs, each examined in a post-Run review):
Demo Run (#457, HG001, earlier build): 29 targets, 27 searched in the sample's own VCF, 20 with the target allele called. 184 Nemotron requests, 2,398 Journey facts, 62 minutes from raw reads to the report. Final build, paper Run (HG002): given only a paper's title, Traceome found and read the paper (PMC7599709), took the reads from Object Storage, measured the Run's health and per-target coverage, and wrote its report in 2 h 4 min with no stop, retry or fix. At about 1× depth, it honestly reports the genotypes as not established.
Challenges we ran into
Making the record readable by a researcher. Recording everything was the easy half. A Run writes thousands of facts, and a raw log tells a biologist nothing. The hard part was simplifying the observability layer so a researcher can follow what happened: which stage ran, what the agent looked up, what it decided, and what was approved. We built one reading path over the Journey. The same views serve the GUI, the command line and the agents, so the researcher sees the Run the way the code ran it, step by step, without reading code or logs.
A report that stays loyal to the facts. The explainer is the one place the model writes prose, and prose drifts. An early explainer wrote "never checked" about variants it had in fact checked. The question was how to check generated text against verified facts. Now code fills in the claim words, each genotype is checked against the VCF row it cites, and the explainer may cite only approved facts from the Journey. It is still our weakest part, and we're still improving it.
Human was easy; everything else wasn't. Runs that worked smoothly on a human sample struggled on non-human ones. Human and non-human data come from different scientific sources, with different names and formats, and our first pipeline quietly carried rules that held only for human. We combined the sources into one set of tools and adopted one principle: code copies, the model decides, code checks. Each source's answer is copied exactly as written, the agent makes the choice and cites the record it rests on, and code checks that the citation is real. Human and non-human samples now run through the same pipeline.
A model that wouldn't stop calling. On NVIDIA Nemotron 3 Ultra, one reply came back holding thousands of copies of a single tool call, and long requests timed out at the gateway. Streaming didn't help: with forced tool use, every call arrived in the final chunk, so we couldn't see a runaway coming or cut it off. We took control of the turn in code (copies collapse, unoffered calls are refused, a cut-off call is dropped) and switched to Nemotron 3.5 Super VL with the model free to choose its tools. The runaways stopped, and our full Runs reached a report.
Accomplishments that we're proud of
From a question to an answer, end to end. A researcher starts from raw genomic DNA reads and a paper or a list of variants. Traceome takes it from there to an explained answer, with NVIDIA Nemotron agents on Nebius Token Factory and NVIDIA Parabricks on Nebius AI Cloud. It's simple to start and fast to answer.
Species-agnostic by design. The same pipeline takes genomic DNA from human and non-human species. The agents choose the reference and the tools for each organism instead of following rules written for one.
The Journey keeps the model honest. Every step is on the record, so the model can't slip in a fact: whatever a source returns is copied as-is, and every claim must cite a recorded fact that code checks.
A collaboration, not a black box. The researcher asks; the agents investigate. When the evidence conflicts or a result is ambiguous, the agent asks the researcher or has them confirm the finding, instead of carrying on silently. Only that item waits.
Nothing is lost. A Run can be watched as it happens and reopened at any time afterwards. To ask something new, the researcher forks the finished Run into a new one, and the original stays untouched.
A proof of concept with room to grow. We built a germline variant pipeline to show the Journey working end to end. Parabricks offers many more workflows, and the same approach applies to them.
Approvals that mean exactly what they say. Each approval covers exactly what was shown, and records what it does not establish. It is never a blank cheque.
One open model for every agent. Planner, investigator, table reader, explainer and paper reader all run on NVIDIA Nemotron 3.5 Super VL through Nebius Token Factory.
One record behind every view. The report, the GUI, the command line and the agents all read the same Journey, so they never tell different stories.
Every live Run examined. Each live development Run got a written post-Run review before we built on it.
What we learned
Reliable research needs both deterministic and agentic code. To make an agent's work reliable enough for research, we gave the agents real freedom: they choose their tools, plan the work and judge what a record means. The computation and the facts stay deterministic, and every step is recorded. Freedom where judgement is needed, and a record where trust is needed. Copy, don't generate. The moment a model rewrites what a source said, nobody can check it. Copying source answers as they are, and making the model cite them, turned "trust the agent" into "check the citation". Observability is a product feature, not a debugging tool. We started recording everything to debug our own agents. It turned out to be what researchers need most: a way to see what happened, in their own terms. The researcher is part of the loop, not the end of it. The best moments came when the agent stopped and asked about a conflict instead of guessing. A pipeline that asks at the right point is worth more than one that never stops. Model settings are part of correctness. One tool-choice setting decided whether a Run finished. Settings are now explicit and recorded with every request.
What's next for TraceOme
Traceome is a prototype. Each part does one simple thing well enough to show the Journey working end to end, and each can grow.
More of NVIDIA Parabricks. We use one workflow: germline alignment and variant calling. Parabricks also offers RNA-seq alignment, somatic variant calling, fusion detection and DeepVariant-based calling. Each would add a kind of sequencing question Traceome can answer. From checking to interpreting. Today Traceome checks the variants a researcher names, or a paper cites, against the sample's own VCF and alignment. The final build also measures the Run's health and the coverage at each target. Next, the pipeline can do much more than check: interpret the variants it finds, add annotation and population frequency, look at structural variants, and search the whole sample broadly instead of only at named targets. More papers, more sources. A Run reads one paper from one open-access source. Next: several papers per question, and more literature sources. Inside a coding-agent harness. Put the pipeline inside an agent harness, so a researcher can add the tools and resources their question needs, while the Journey and the observability layer still record every step. Reports the researcher shapes. Customise what a report covers and how it reads. Across Runs. Today each Run answers its own question. Next: compare what several Runs found, across samples or questions, from their Journeys. Formal evaluations. Repeated Runs and held-out cases, scored by review of the recorded evidence: how often the right targets are found, how long a Run takes, and what it costs.
What Traceome is not Not a clinical tool. It is research decision support. It makes no diagnosis and claims no function or causality, and "no record" never becomes "not carried". Not autonomous, by design. The agents investigate, but they can't settle every question alone. When evidence conflicts, it takes a knowledgeable researcher to drive the answer, so the researcher approves at the key points and nothing consequential runs without that approval. Not a full analysis suite. It's a prototype that answers one kind of question well: does this sample carry these variants? We tested it with one Parabricks workflow, a single paper at a time, and one open-access literature source. Not fully evaluated yet. A small evaluation of planning cases is under way. A bigger evaluation, with more hand-picked scenarios, is planned.
Built With
- dbsnp
- europe-pmc
- eva
- ncbi
- nebius-ai-cloud
- nebius-object-storage
- nebius-serverless-ai
- nebius-token-factory
- nemotron-3.5-super-vl
- nicegui
- nvidia-h100
- nvidia-nemotron
- nvidia-parabricks
- pubmed-central
- pydantic-ai
