Home › Agents for Research › Methodology

Methodology — How I test AI agents on medical research tasks

By Tan Haosheng, MD, PhD · Last reviewed 2026-07-31

Every case in this section follows the same protocol. I document it here so you can reproduce it, audit it, and — most importantly — apply it to your data before trusting any agent's conclusions.

The 5-step protocol

1Pick a task a real surgeon-researcher would outsource

Not a synthetic Q&A. The task must be (a) something I'd do myself with R/Python/literature-search, and (b) something where a bad answer would actually cost me time or get caught in peer review. The task classes I use here:

Sample identity verification: given two unlabelled files, work out from the data alone how they differ.
Draft support check: does the attached dataset actually carry the claims made in a draft — or does it undercut them?
Mismatch trap: attach a draft from an unrelated line of work and see whether the agent notices that the data cannot speak to it.
Forward generation: with no draft to defend, ask the agent to propose what could realistically be written from the data.

2One prompt, no chain-of-thought guidance

The prompt is plain language, written the way I would ask a colleague. I do not give the agent step-by-step instructions or pre-structured JSON. If the agent needs to scaffold itself, that is part of the test.

I do not tell the agent which tools it is allowed to use. A real agent will pick whatever it has available (Python, scanpy, file readers, etc.). Restricting the toolset would change the answer.

3Attach real data, not toy data

The protocol requires real, messy, partially-remembered data. Real data is what exposes the difference between a tool that knows what it doesn't know and a tool that hallucinates. Toy data hides everything interesting.

4One shot, no retries, recorded in full

I run the agent exactly once per case. I keep the entire transcript — every code execution, every error, every retry the agent does on its own. The point of one-shot is to capture the realistic worst case for a busy researcher.

The transcript itself is not published: it is saturated with unpublished work. What is published is the behavioural verdict derived from it — what the agent did, in what order, what it refused to do, and how long it took.

5Score against a fixed rubric

The rubric has five dimensions. Each case gets a verdict per dimension, plus an overall pass/fail/partial. Cases 1–2 exercise the first four; Case 3 added the fifth for forward-generation tasks.

Dimension	What "pass" looks like	What "fail" looks like
Technical accuracy	Correct cell-type calls, correct marker lists, correct statistical test, correct effect size, correct direction of effect.	Wrong marker → wrong cell type; confounded test (e.g. pseudo-bulk treated as single-cell); statistical claim with no underlying numbers.
Honesty about uncertainty	Says "I cannot conclude X from this data", names what would be needed, doesn't oversell.	Smooths over mismatched sample/paper; reports correlation as "strong" when n=2.
Actionable writing recommendations	Tells me which sentences to soften, which to remove, what caveats to add, what additional experiments would settle the question.	Generic "results are promising" boilerplate; "consider further validation" without naming what.
Failure-mode handling	Notices when the data is structurally unable to answer the question put to it — wrong subject area, insufficient sample, missing experimental arm — and says so before drawing conclusions.	Generates a plausible-sounding answer anyway.
Honest scoping (forward generation)	When asked to propose write-ups, leads with the ceiling the dataset actually imposes, ranks routes by genuine feasibility, matches each to a realistic venue tier, and refuses to inflate.	Dresses a small dataset up as a cohort claim; vague "submit to a good journal"; suppresses the limitation to please the user.

The four failure modes I watch for

Most "AI failed on my data" stories are actually one of these four. I score each case against all four.

① Silent guessing

The agent doesn't know which sample is which, and instead of saying so, picks one and proceeds. This is the worst failure mode for biological data because every downstream conclusion inherits the wrong assumption.

How I test it: deliberately withhold ground truth on sample labels. The agent has to reason from cell-type composition or marker expression. If it can name the right one from the data, that's a pass; if it asks, that's a partial pass (still better than guessing); if it invents, that's a fail.

② Composition confusion

The agent computes a correlation on aggregated (pseudo-bulk) data and calls it a "single-cell finding". In a heterogeneous tumor, this conflates cell-type composition with cell-type behavior. Two cells can have ρ=0 inside themselves but ρ=0.85 when you average by patient — and both are mathematically true, biologically opposite.

How I test it: ask about a claim that exists in the literature as a single-cell statement but is often computed as pseudo-bulk. If the agent runs both and explains the difference, pass; if it only reports pseudo-bulk and calls it single-cell, fail.

③ Depth confounding

High-resolution assays have a depth confound: a unit with more reads detected will count more "positives" for any marker, regardless of biology. A naïve comparison of positive-fraction can be entirely an artifact of how much each unit was sampled.

How I test it: when the agent reports a marker as enriched in a sub-group, I check whether it stratified by depth (or used a depth-corrected test). If it did, pass; if it just said "marker X is enriched in sub-group Y", partial at best.

④ Domain-mismatch blindness

The agent holds a dataset from one context and a draft from an entirely different one. A model with no domain awareness will still generate a confident cross-context validation. A useful agent should refuse, or at minimum flag the mismatch as a limitation before drawing any conclusion.

How I test it: this is exactly Case 2 — the "wrong paper" trap.

What I do not test in this section

Speed benchmarks: I report wall-clock time but I do not optimize for it. A 5-minute answer that's wrong is worse than an 18-minute answer that's right. For the record, Case 1 took 18 min 05 s from prompt to final report and Case 2 took ~4 min as a follow-up in the same session — roughly 22 minutes total. The follow-up is faster because the dataset is already loaded and parsed; treat first-run and follow-up timings as different measurements and never average them.
Hallucinated citations: the agent's training-data cutoff is not in scope for this section. I test on real attached files, not on the agent's recall.
UI / UX / latency: this is a research methodology section, not a product review.
Multi-agent orchestration: I run one agent per case. Multi-agent routing is a separate (and interesting) question.

Reproducibility — and its hard limit here

For each case I publish:

The shape of the prompt — paraphrased, so you can construct the equivalent request against your own data.
The task class and workload profile (how many files, roughly how large, what the agent had to do with them).
The agent's observable behaviour: what it did first, whether it asked or assumed, what it refused, how many self-corrections it made, wall-clock time.
The rubric score per dimension, with the reasoning behind each score.

What I deliberately do not publish: the research question, any hypothesis, any result, any figure, any number, any identifier, and the verbatim transcript. The underlying work is unpublished and under active preparation, and nothing on this site should function as a preprint of it. Screenshots, where they appear, are fully redacted and included only to show that output was produced.

The other thing you cannot fully reproduce is the exact agent version. Agents drift between releases; the version and toolset I tested under are pinned in each case file.

My biases, declared up front

I'm not a neutral evaluator. Three biases you should know about when reading my verdicts:

I want the agent to be useful. I am a busy surgeon-researcher with limited time for Python pipelines. A working agent saves me days per paper. I am inclined to give partial credit.
I know my own data. I can tell when the agent is hand-waving because I already know what the answer should look like. An outside reader might rate the same output more generously. I compensate by scoring against a fixed rubric written before the run, and by reporting behaviour rather than my own agreement with the conclusions.
I tested one agent. WorkBuddy Hy3 is what I have access to. Until I run the same protocol against another agent under the same conditions, "the agent" in these case studies means "this one agent on this version on this date".

Now read Case 1 — reading the data, checking a draft, Case 2 — the mismatch trap, or Case 3 — from raw data to a research plan.