Paper2Agent

Your 3-hour plan

• 0:00–0:10Part 0 and A1: the short version, and your own summary checked.
• 0:10–0:55A2–A8: architecture, MCP, the build pipeline, testing, the query loop. The most important 45 minutes.
• 0:55–1:40Part B with the paper open beside you. Read each figure using the guides.
• 1:40–2:05Part C: what is shown vs claimed, a statistician's notes, questions to make you think.
• 2:05–2:25Part D: read the ten research ideas; pick two you could talk about.
• 2:25–2:50Part E: say your intro and 2-minute summary out loud, twice.
• 2:50–3:00Write the one-page cheat sheet (E9) by hand. Then take a break.

0The short version

Paper2Agent is a group of Claude Code agents that reads a paper and its code, runs the paper's own tutorials, turns the tutorial steps into general functions, and keeps only the functions that reproduce the tutorial outputs. It packages those functions, together with the paper text, data links and workflow recipes, as an MCP server. Any MCP-compatible AI agent can connect to it, so a user can run the method by asking in plain English.

A1Your summary, checked

Your summary is mostly right. Four refinements:

A2Page 1: the problem and the idea

A3Page 2: the architecture

Your example project, conceptually

Paper Tools are single-purpose functions with file-based inputs and outputs; hard-coded paths, thresholds and column names become parameters. My reading workflow.py could also become one “run everything” tool, but the paper's pattern is small tools plus a prompt that orders them, so the agent can still adapt between steps.

A4MCP, properly

For each idea: what it is, an analogy, where it appears in the paper, and why it matters.

Outside MCP's design gives each part a different controller. The model decides when to call tools. The app or agent reads resources into context. The user chooses prompts.

A5Figure 1, part by part (p. 3)

Figure 1a

The chart inside the agent's reply is a GWAS “Manhattan plot”. It is just an example output; you don't need to read it.

The .py question

Paper Yes: the server is packaged as an MCP Python file. In the Methods, step 5 turns each executed tutorial into a standalone Python module of reusable functions and marks each function as an MCP tool. Step 6 merges all validated modules into one server with a manifest, versioning and basic security defaults. You can see the Python definitions in the figures: Fig. 3b defines a prompt with @clustering_mcp.prompt, and ED Fig. 1D defines a resource with @mcp.resource(...).

My reading The file does not replace the original repository. The tool functions follow the tutorial code, which calls the original package installed in the configured environment. Paper Each tool also carries a link to the original source code it came from.

Tool names differ slightly across the paper (score_variant, score_variant_effect(), score_variant_batch(); quality_control() vs quality_control_basic_filtering()). Don't get stuck on this.

Figure 1b: the workflow, mapped to the Methods

A6The build pipeline (Methods, pp. 10–12)

Paper An orchestrator agent coordinates sub-agents. Each sub-agent is a separate Claude session with its own role prompt and a set of allowed actions: read and write files, run shell commands, search code. Steps run in order, and within a step several tutorials can be handled in parallel. Steps hand work to each other through JSON reports and file conventions.

The specialised agents, in one line each

A7Testing: why tutorial outputs are the reference

• Why run the original first: the original code on the example data defines what “correct” means for this test, rather than the LLM's opinion. An LLM-written wrapper can silently change a default, skip a normalisation step or use the wrong column. Comparing with the original outputs exposes that.
• Expected files exist: did the function produce its outputs at all?
• Numbers within 3%: allows tiny floating-point differences (different hardware, library versions, order of operations) but flags real ones.
• Perceptual hashing, Hamming distance under 20: each figure is reduced to a short “fingerprint” of its visual structure. The Hamming distance counts how many positions differ between two fingerprints. Under 20 counts as the same figure, even if exact pixels differ (fonts, anti-aliasing).
• Six attempts, then exclusion: a tool that can't reproduce a known answer can't be trusted on an unknown one. The agent can't call what isn't exposed, and a smaller toolset you can trust beats a larger one you can't.
• Why this beats “does this code look correct?”: looking right isn't behaving right. An LLM reviewer checks plausibility and shares the writer's blind spots. Execution checks behaviour against real outputs.

A8Query time: planning, action, observation, finding (Fig. 2d)

A non-biology example

User  In survey.csv, which variables are associated with customer satisfaction?

Planning  1 inspect columns and missing values · 2 clean · 3 fit a model · 4 check robustness · 5 report
Action  inspect_data("survey.csv")
Observation  satisfaction is a 1–5 rating; wait_time has 12% missing; region is categorical
Action  clean_data(max_missing=0.2, impute="median") → fit_model(target="satisfaction", model="ordinal")
Observation  wait_time and first-contact resolution have large, stable effects; region does not
Finding  longer waits and unresolved first contacts go with lower satisfaction (association, not causation)
Next action  does the wait_time effect differ by channel? → fit_model(..., interaction="wait_time:channel")

Why the loop helps: the agent reacts to what the data actually shows (missing values, variable types, errors) instead of running a fixed script blindly, and problems become visible mid-way.

B1Biology decoder (just enough)

Why GWAS leaves a puzzle: nearby variants are inherited together, so a GWAS finds a region and a set of correlated suspects. It can't say which variant, or which nearby gene, is causal. AlphaGenome's predictions are one way to narrow it down.

B2AlphaGenome agent (pp. 3–5, Fig. 2)

Figure 2a: construction

The benchmark: what it is actually asking

“Given the same questions, does an agent with pre-built, validated tools get the right answer more often, faster and more consistently than (a) the same LLM handed the raw repository, and (b) a general biomedical agent? And does this hold on known task types and on new inputs?”

Results in words. On exact tasks, Paper2Agent was right 98.7% (tutorial) and 100% (novel) of the time. Claude + Repo managed 82.7% and 78.7%, and Biomni 37.3% and 56.0%. On open-ended questions the scores were 82.7% for Paper2Agent, 56.7% for Claude + Repo and 72.2% for Biomni. The gains held under reworded prompts and against a newer model for the Claude + Repo baseline.

What it tells you: pre-built, tested tools remove the step where a general agent writes its own code and gets it wrong. Notice that Biomni does much better on open-ended synthesis (72%) than on exact numbers (37–56%): general agents can reason, but exact execution is where they slip.

Why two graders: open-ended answers need judgement, and independent agreement shows the grades aren't one person's opinion. C3 explains why 96.7% needs context.

Figure 2b: how to read the bar chart

• x-axis: the method, grouped by benchmark (tutorial-based on the left, novel on the right). y-axis: the % of queries answered correctly.
• Bar = the mean over 5 runs. Each dot = one run's accuracy. Error bar = ±1 standard error of the mean across the 5 runs.
• Why five runs: the same query can get a different answer on a different run, so five runs show consistency.
• “98.7 ± 1.3%”: 15 queries × 5 runs = 75 attempts. If four runs got 15/15 and one got 14/15, the mean is 98.7% and the s.e.m. is 1.3, exactly the reported numbers. So that is one miss in 75 attempts. “100.0 ± 0.0” means 75 out of 75.
• Left panel: the ground truth is −0.0203067882 and the agent's answer is −0.0203067882, identical to 10 digits. It ran the same code rather than estimating.
• What it says about reliability: on these task types the agent is accurate and consistent across runs. It doesn't show how the agent does on other kinds of task. The ± reflects run-to-run noise only, not which 15 questions happened to be chosen (see C3).

Figure 2c: the box plots (runtime)

• Each dot in the paper's figure is one query run: 75 per box (15 queries × 5 runs).
• Median (centre line): half the runs were faster, half slower. Box: the 25th to 75th percentile, i.e. the middle half of runs. Whiskers: the furthest runs within 1.5 × the box length from the box. Dots beyond: outliers.
• The ratios are ratios of medians. On tutorial queries, Claude + Repo's median time is 1.9× Paper2Agent's and Biomni's is 3.1×. On novel queries they are 2.9× and 3.8×. Read roughly off the figure, that is about 50 s vs 100 s vs 170 s on tutorial queries.

Why runtime matters: agents are used interactively and many times, and every extra minute is also extra LLM calls, i.e. cost. Paper2Agent is faster because it calls a ready tool instead of reading the repository, writing code and debugging it. In the large-scale test, a query cost US$0.20 and took 1.6 min, against US$0.38 and 4.3 min for the baseline.

Figure 2d and the SORT1 result (pp. 4–5)

The question: why is the variant chr1:109274968:G>T associated with LDL (“bad”) cholesterol? The agent plans, runs batch scoring and visualisation, and observes liver tracks (CAGE, RNA-seq, splice sites; the genes CELSR2, PSRC1 and MYBPHL are in view). It then reports SORT1 as the causal gene.

Quantile score, simply: where this variant's predicted effect ranks against a large background of other variants. 0.99983 means more extreme than about 99.98% of them. It is relative: a small absolute change can still rank as extreme, because most variants do almost nothing. It can be negative (−0.0203 in Fig. 2b), so read it as signed: near 0 is ordinary, near ±1 is extreme.

B3Scanpy (pp. 5–6, Fig. 3)

The name: you were right to question it. Scanpy (“Single-Cell Analysis in Python”) is a Python package, used as import scanpy as sc. “scan.py” is not its name. It is a standard toolkit for single-cell gene-expression data: quality control, normalisation, dimensionality reduction, clustering, UMAP plots and marker genes. The paper agentified its most common workflow, preprocessing and clustering.

A data analogy

Figure 3a: the Scanpy MCP

• quality_control_basic_filtering(): calculates quality metrics (genes per cell, total counts, % of mitochondrial reads; a high % suggests dying cells), applies filters, and writes the filtered data plus the violin plots shown. The agent reports 17,041 cells and 23,424 genes kept.
• clustering_analysis(): runs Leiden clustering at several resolutions, from coarse to fine, and saves labels and plots.
• Both execute Scanpy's own functions inside the configured environment. My reading These would be Scanpy's standard calls for QC metrics, filtering and Leiden; the paper doesn't list them.
• The resource is a link to the Scanpy documentation. The prompt holds instructions for preprocessing and clustering. The Scanpy agent is Claude Code plus this server: 7 tools, all passed, built in about 45 minutes for US$13.

Figure 3b: the chain of tools, checked against the figure

Paper The left panel is a Python function in the server, marked as an MCP prompt (@clustering_mcp.prompt, named preprocess_and_cluster_scanpy, taking data_path). It returns a text recipe:

• First inspect the data: size, organism, batch columns, quality. Change defaults only with a strong reason.
• Then run, in order: quality_control → normalize_data → select_features → reduce_dimensionality → build_neighborhood_graph → cluster_cells → annotate_cell_types.
• Each step comes with parameter guidance (e.g. 2,000–3,000 variable genes; 10–30 neighbours; resolution 0.1–0.4 for broad or 0.6–1.5 for fine clusters), plus an instruction to validate each step.

On the right, the user runs /scanpy:preprocess_and_cluster_scanpy in Claude Code and gives data.h5ad. The agent executes the pipeline and summarises the results.

Paper How it was made: the authors asked Paper2Agent, in one sentence, to build a prompt that replicates the tutorial in the correct order, inspects the data first and only departs from defaults when needed. The steps were inferred from the code and tutorial, not written by hand.

Figure 3c: agent vs human researcher

On the left is the agent, given only a file path. On the right is a human following the official Scanpy tutorial on the same blood-cell (PBMC) data. Paper “Reproduces human results” means the same numbers of cells and genes after quality control and equivalent top marker genes per cluster, with matched parameters, on public datasets not included in the Scanpy codebase.

B4TISSUE (p. 5; Extended Data Fig. 1)

Analogy: you have complete purchase histories for a sample of customers but not their locations, and for every store you know sales of only 50 products. You predict the other products' sales per store from similar customers. TISSUE attaches an error bar to every predicted number and makes later comparisons respect those error bars, so shaky predictions aren't treated as facts.

What Paper2Agent did:

• Built a TISSUE MCP. The tools include calibrate_uncertainties_and_prediction_intervals() and multiple_imputation_hypothesis_testing(). The resources are the spatial datasets used in TISSUE. The prompts are instructions for uncertainty-aware analysis.
• Connected the MCP to Claude Code.
• Compared the agent's outputs with those of human researchers who followed the TISSUE GitHub tutorial on the same mouse brain dataset (somatosensory cortex).

How to read Extended Data Fig. 1

B5Paper agents working together (pp. 7–8, Fig. 4)

How they combine: if the region works through gene X, switching off the region should look like knocking down X. So you correlate the region's fingerprint with each candidate's fingerprint. Only GPR137 matched, and only when the cells were stimulated.

Analogy: a feature flag seems to hurt a metric, and you suspect it acts through one of five features. Log 1 records what happens to 20 metrics when the flag is off. Log 2 records what happens to the same 20 metrics when each feature is disabled. The feature whose pattern matches the flag's pattern is the likely route.

Psoriasis in plain English: an immune-driven skin disease in which activated CD4+ T cells are involved. A GWAS linked rs887314 to psoriasis risk, and the question is which gene it acts through.

Who did what

• HUMANAsks: what is the causal gene and mechanism for rs887314 in CD4+ T cells?
• AGENTUses AlphaGenome tools to rank nearby genes; GPR137 comes out on top.
• HUMANInstructs: verify using the scCRISPRi and Perturb-seq data.
• AGENTReads both papers, their supplementary tables and summary statistics, and proposes ten validation strategies.
• HUMANSelects one: signature correlation.
• AGENTComputes Spearman correlations for the five top candidates that have knockdown data, in three conditions, and reports that GPR137 matches.
• AUTHORSInterpret: GPR137 is the probable causal gene, and its role depends on T-cell activation.

Paper The signature-correlation idea was not in either source paper; the agent proposed it as one of ten, and a human chose it. Note the language gap. The agent's reply in Fig. 4a says the result confirms GPR137 as the causal gene, while the authors' text says the evidence supports it as the probable causal gene. My reading That gap is exactly why the human stays in the loop.

B6Spearman correlation

One sentence: Spearman's ρ measures whether two lists rise and fall in the same order. +1 means the same order, −1 the opposite order, and 0 no relation.

Tiny example: five students are ranked 1, 2, 3, 4, 5 in maths and 1, 3, 2, 4, 5 in physics. Only two swap places, so ρ = 0.9. Because it uses ranks rather than raw values, one extreme value can't dominate the way it can with ordinary (Pearson) correlation.

In the paper: each dot is one downstream gene. For GPR137, ρ is 0.61 at Stim8hr and 0.63 at Stim48hr. That high positive value means genes that drop more when the region is switched off also drop more when GPR137 is knocked down, so the fingerprints match. ρ = 0.29 at rest (P = 0.21) is weak and not distinguishable from chance. For BAD, ρ is −0.12, 0.09 and 0.05: no match.

P value: how often a correlation at least this strong would appear by chance if there were no real relationship. With about 20 genes, ρ ≈ 0.3 happens easily by chance, but ρ ≈ 0.6 rarely does (P ≈ 0.004). Why they care: 5 candidates × 3 conditions = 15 tests, so some would look good by luck. They used Benjamini–Hochberg correction; orange labels mean the false discovery rate is below 5%.

Figure 4: how to read it

B7ADHD example (Extended Data Fig. 2)

B8Large-scale evaluation (pp. 5, 7, 11–12)

Procedure Paper:

1. Produce ground-truth answers.
2. Run the agent non-interactively, capturing its answer, runtime and cost.
3. Human graders compare the answer with the ground truth.
4. Summarise: mean ± s.e.m., paired t-tests on per-run accuracy, and bootstrap tests for the 100-paper set.

“Ground truth” in this paper means answers obtained by running the original code, plus rubric items for open-ended questions.

Why the third group matters for you: it includes causal inference, Bayesian time series, game theory, MCMC and selective inference, which are statistics and economics tools. My reading Caveat: these are popular, well-maintained packages, and 42 tasks is a small number.

How each case study was evaluated

What makes a codebase “agentifiable”

Paper Failures came from missing executable code, missing data or model files, environment and dependency failures, and scripts that don't generalise. Turned around, an agentifiable codebase has:

• Code that is public and complete, not “available on request”.
• Models, weights and data that can be downloaded.
• An environment that can be rebuilt: dependencies resolve, with no dead or licence-only packages.
• Runnable examples with example data. These become the tests.
• General logic (functions with parameters), not one-off scripts hard-wired to one dataset.
• Checkable outputs (files, numbers, figures) and controlled randomness.

The authors suggest that how easily a paper can be agentified could itself be a practical measure of its reproducibility.

Out-of-scope questions

Why: to measure false positives. Does the agent make up answers to questions its paper can't answer?

How Paper: questions for the 26 data papers were randomly re-paired with the wrong paper. The agent was run with and without an explicit instruction to say “I don't know”. A correct rejection means declining instead of answering. The reported rate was 100%.

Why “I don't know” can be better: in research, a confident wrong answer flows into later work, while an honest refusal costs little.

• A useful agent answers in-scope questions correctly.
• A hallucinating agent answers everything confidently, whatever the evidence.
• A correctly refusing agent recognises when its paper doesn't cover the question.

Shortcut learning (memorising the tutorial)

The worry: tools are tested against tutorial outputs, so an LLM could “pass” by hard-coding the tutorial's numbers, fixed file paths or cached outputs, or by writing logic that only works on the tutorial data. The tool would then fail on new data, like a student who memorised the practice exam.

The check Paper: manual inspection of the generated servers across the 100 papers, plus an automated reviewer agent that scans server files for those patterns. They found no systematic evidence of it.

What it tells you: the tools appear genuinely parameterised. My reading There are limits. The reviewer is itself an LLM, and “no systematic evidence” isn't “none”. The stronger evidence is correct results on new inputs.

Ablations

Ablation study: remove or swap one component, keep everything else the same, and see what changes. It tells you what each part contributes. These were run on AlphaGenome with 30 questions on Sonnet 4.

The main text says only that automated validation and the multi-agent design contribute to performance. The numbers are in the Supplementary Note, which is not in your PDF.

Repository-drift tests

Why: real repositories decay as packages update, paths change and functions get deprecated. The authors injected four kinds of error: missing dependencies, broken file paths, typos and deprecated API calls. They used three repositories (AlphaGenome notebooks, POP-TOOLS in Python, mlearner in R) and injected one error type at a time without telling the agent, giving 12 set-ups.

If it recovers: the loop that runs code, diagnoses errors and repairs them can fix errors that make code crash. This works across Python and R, notebooks and command-line tools.

What it does NOT prove:

• That it catches silent errors, where code runs but computes the wrong thing. The authors say the loop fixes bugs that show up as execution failures.
• That a “fix” keeps the original scientific intent.
• That it copes with several errors at once.
• That the tutorial outputs themselves were right.

Paper Also: with every executable tutorial removed from POP-TOOLS, it still built a working server that matched human-run outputs on five tasks. Tutorials help but aren't strictly required.

C1Shown, suggested, not yet solved

C2Limitations: your list, checked

Add these, all grounded in the paper:

• Validation covers only the tutorial's own examples, because the tests are built from them.
• The repair loop targets crash-type bugs, not silent ones.
• The benchmarks are small: 15 + 15 + 30 AlphaGenome queries, several of them tutorial-derived.
• Human choices shaped the discovery case studies (the question, the strategy and the interpretation).
• One model family (Claude Sonnet 4) was used for building and for answering.

C3A statistician's notes My reading

These are not claims made by the paper. Pick two to raise, as questions.

1. Small n. 15 out of 15 correct is consistent with a true success rate as low as about 78% (the exact 95% binomial interval is roughly 78–100%). “100%” on 15 questions is encouraging, not conclusive.
2. What the ± measures. In Fig. 2b the s.e.m. is across 5 runs of the same 15 questions. It captures LLM randomness, not uncertainty about which questions were chosen, and the second is probably larger.
3. Circularity. Tools were validated on tutorial outputs, then benchmarked on tutorial-derived questions, so high scores there are expected. The “novel” queries are the fairer test, and they are new inputs to the same task templates.
4. Agreement without chance correction. When most answers are correct, two graders agree often by chance. Suppose each marks about 85% of answers correct. Chance agreement is then 0.85² + 0.15², about 0.75, and Cohen's kappa is (0.967 − 0.75) / (1 − 0.75), about 0.87. That is still good, but more informative than 96.7%.
5. Conditioning. The 91.2% is accuracy on the 74 papers that succeeded. It says nothing about the other 26.
6. Fixed tolerances vs randomness. A 3% band and a hash cut-off suit deterministic outputs. Random methods (MCMC such as emcee, bootstrap, simulation) give different outputs from identical inputs. A fixed band can therefore fail correct tools or pass wrong ones. The natural test compares distributions.
7. Wording vs evidence. The agent says “confirms” where the authors say “probable”. Agent language may not match the strength of the evidence.
8. The Fig. 2d sign (+0.058 vs “downregulation”); see B2.
9. Familiar repositories. Some test repositories come from the authors' own groups (TISSUE; POP-TOOLS and mlearner). Not wrong, but worth noticing.

C4Your 15 questions, answered short

C5Questions to make you think

A · Five questions for yourself (don't answer them yet)

1. If a tool passes all its tests, what exactly do you know about its behaviour on your data, and what don't you know?
2. Why might Claude with the full repository do worse than an agent that can't even see the repository?
3. In the SORT1 answer, which parts came from AlphaGenome and which from the LLM? How would you check?
4. What would a benchmark look like that measures whether a conclusion is valid, not just whether it matches a reference?
5. In Fig. 4, if the human had chosen a different one of the ten strategies, could the conclusion have changed? Who gets the credit, and who is responsible if it's wrong?

B · Five research questions (not ranked)

1. Validating random methods. For methods with random outputs (MCMC, bootstrap, simulation), what test should decide that an extracted tool is equivalent to the original? How should its tolerance balance rejecting good tools against accepting bad ones?
2. Benchmark design. How many questions and repeated runs does an agent benchmark need to separate two agents reliably? How should question sampling, run-to-run randomness and grader disagreement be modelled together?
3. Human oversight as a decision. If expert time is limited, which agent outputs should a human check? When should an agent stop and ask rather than continue?
4. Combining agents' evidence. When several paper agents supply evidence that may be correlated or biased, how should it be combined? When does adding another agent actually add information?
5. Incentives. If journals expected an “agent availability” section, how would authors' incentives change? Could agentifiability be gamed as a reproducibility signal?

C · Three limitations worth discussing with the professor

1. Validation is anchored to tutorial examples. A pass means “reproduces the original code on the example”, not “correct on new data”.
2. The evaluation is small and partly circular. There are 15 + 15 + 30 AlphaGenome queries, many of them tutorial-derived. The ± reflects run-to-run noise only.
3. Conclusions have mixed sources. Final answers blend tool outputs with the LLM's own knowledge and wording, which makes them hard to audit.

D · Three directions to investigate

1. Agentify statistics, OR and analytics codebases and measure build success, tool pass rate and accuracy on genuinely new tasks, with proper intervals.
2. For methods whose correctness can be certified (optimisation, interval methods), test whether certificate-based checks catch silent bugs that tutorial matching misses.
3. Study reliance: when people see “validated tools”, do they check less?

E · Five questions you could ask Prof. Keppo

1. “Their tests accept a tool if outputs are within 3% of the tutorial's. For random methods like MCMC or simulation that seems ill-defined. How would you think about validating a stochastic tool?”
2. “They say agreement with one reference measures faithful execution, not analytical validity. How would you evaluate an agent on open-ended questions where several answers are defensible?”
3. “In the psoriasis example the agent proposed ten strategies and a human chose one. Could the split between what the agent decides and what the human decides be studied formally, as a decision under uncertainty?”
4. “If journals required an ‘agent availability’ section, how do you think authors' incentives would change?”
5. “What made you choose this paper for me? Is there an angle on it, from operations or decision-making, that you think is under-explored?”

D0How to use these

• They are not ranked. Each is sized so you could start it alone in 4–6 weeks with a laptop, Claude Code and public data.
• In the meeting, mention two at most, as questions: “Would something like this be interesting?” Let his reaction guide you, not your pitch.
• Each idea has a decision or statistics core (uncertainty, incentives, evaluation, aggregation). That is what makes it research rather than a build.
• Two are pricing-adjacent (8 and 9) because that is real experience you have; the rest are not.

E1What today is

• He has said there are no RA positions now. He still made time and sent you a paper, so he wants to see how you read and think. Treat it as an exploratory conversation, not an interview for a post.
• Your goals, in order:
  1. Show you understood the system and can think critically about it.
  2. Find out why he chose this paper and what interests him about it.
  3. Get his honest advice on PhD vs industry routes.
  4. Leave with one concrete next step you can deliver.
• What tends to work with a quantitative professor: precise understanding; separating what was shown from what was claimed; one or two sharp statistical questions; honesty about your goals; following through.
• Avoid: reciting numbers, attacking the paper, big startup talk, and pretending you want an academic career.

E2Your 60-second introduction

E3Your 2-minute summary (say it out loud)

E4A simple flow (about 30–45 min)

1. Thanks and intro (1 min).
2. The paper: give the 2-minute summary, then say “There were two things I wanted your view on …”. Pick them from C3 or C5-E.
3. Listen: ask “What made you pick this paper for me?” Then let him talk, and follow his thread.
4. Your situation, honestly: you're considering a PhD, leaning towards industry or a startup, want work that combines AI with decision-making, and want to stay and work in Singapore.
5. Routes: ask the career questions (E6).
6. Ideas: if the conversation opens up, float one or two ideas from Part D as questions.
7. Offer: a small piece of work (E7). “Could I send you something in three or four weeks?”
8. Close: thank him, and ask whether there is anyone else he'd suggest you talk to.

E5Programmes: fact sheet

Checked on 21 Sep 2026 against the sources at the end. Rules change, so confirm on the official pages before relying on a detail.

E6Career questions to ask

1. “For someone who wants to end up in industry or a startup rather than academia, when does a PhD in Analytics & Operations make sense, and when would you advise against it?”
2. “What do your department's PhD graduates do when they don't take faculty jobs?”
3. “The AISG fellowship expects an AI-related PhD, usually in a computing school, and a supervisor with recent top-tier AI papers. Is co-supervision between the Business School and SoC common here?”
4. “SAP Labs has just posted an NUS industry PhD on LLM agents and evaluation, but it prioritises people with Singapore work rights. Do you know whether such industry PhDs can be based in the Business School, or whether there are routes open to international students?”
5. “The deadline for August 2027 is 15 December. What would make an application from someone like me stronger in the next three months?”
6. “Would you be open to me doing a small independent project related to this paper and sharing it with you?”

To ask other people rather than him: what PhD graduates earn compared with MSc graduates in the roles you want, and whether any part-time or employed PhD route exists.

E7A next step you could offer

1. Any one idea from Part D, cut down to a 3–4 week pilot. Ideas 2, 3 and 10 build directly on this paper.
2. Agentify 3–5 statistics, OR or analytics codebases with the open-source Paper2Agent, which now installs as a Claude Code skill. The paper reports about US$13–14 of API cost per server. Record whether each build succeeds, how many tools pass, and accuracy on genuinely new tasks.
3. Write a two-page critique of the paper's evaluation design (C3), with a proposal for a better benchmark.

Keep it small enough to finish alongside your MSc. Offer it; don't over-promise.

E8Follow-up email (send within 24 hours)

Subject: Thank you: Paper2Agent discussion

Dear Professor Keppo,

Thank you for your time today and for sending me the Paper2Agent paper. I especially appreciated your point about [one specific thing he said].

As we discussed, I will [next step, e.g. agentify three statistics packages with Paper2Agent and test how its validation handles random outputs], and I'll share a short write-up by [date].

[If he suggested someone or something to read: I'll also look into / reach out to …]

Best regards,
Aditya

E9The one-page cheat sheet (write this by hand)

1. Mental model: the two-phase flow in Part F (build once, use on every query).
2. MCP: tools act (the model chooses them), resources are read (context), prompts are recipes (the user chooses them).
3. Build: locate → environment → find tutorials → run them → extract → test (files, 3%, hash under 20, up to 6 tries, drop failures) → assemble → host.
4. Numbers:
   • AlphaGenome build: 22 tools, about 45 min, about US$14.
   • Exact queries (tutorial / novel): Paper2Agent 98.7 / 100%, Claude + Repo 82.7 / 78.7%, Biomni 37.3 / 56.0%.
   • Open-ended queries: 82.7% vs 56.7% vs 72.2%.
   • 1.9–3.8× faster (medians).
   • 74 of 100 papers agentified; 593 of 599 tools passed.
   • 91.2% vs 80.3% on the 300 tutorial questions.
   • Non-biology 98.1%; resources alone 89%; out-of-scope rejection 100%.
5. Two critical points you will raise (from C3).
6. Two research ideas you might float (from Part D).
7. Two questions for him (C5-E) and three career questions (E6).

F1The whole system

What changed from your version:

• Build and use are split, and the build runs once.
• “Understand + extract” really means run the tutorials first, then extract.
• Resources and prompts are packaged too.
• There is a refusal path.
• A human sits at the end.

F2The paper in one paragraph

Paper2Agent treats a research paper as software that should be usable, not just readable. A team of AI coding agents finds a paper's code, gets it running and runs its tutorials. It then rewrites the useful steps as general functions and keeps only the functions that reproduce the tutorials' outputs. Those tested tools, together with the paper's text and data (resources) and step-by-step workflows (prompts), are packaged as an MCP server that any AI agent can connect to. A user can then ask, in plain language, to apply the method; the agent plans, calls the tools, checks the results and reports. On the authors' benchmarks this is more accurate and faster than giving an AI agent the raw repository. It works on about three-quarters of real biology papers and on statistics and machine-learning packages, and several paper agents can be combined to build evidence for a hypothesis. What it demonstrates is faithful execution of published methods. Whether the scientific conclusions are right still needs human judgement and, often, new experiments.

·Sources

• The paper: Miao et al., Nature (2026), doi:10.1038/s41586-026-11044-y · code: github.com/jmiao24/Paper2Agent
• AISG PhD Fellowship page · AISG application guideline (Jan 2026 intake)
• SAP job posting (req. 439621) · EDB release on SAP Labs + NUS
• SUTD EDB-IPP page · NUS Business School PhD admissions · NUS Graduate School scholarships
• COMPASS 2026 summary (Fragomen) · MOM Employment Pass
• CFPB Consumer Complaint Database (for idea 7)