Building a model well means finding the right features to feed it, and finding the right features means a lot of reading: papers, pathway databases, internal data, prior work. That reading doesn't scale to one scientist doing it alone for every candidate. So I built a research copilot for it: a set of subagents and small, domain-specific tools that each specialize in one kind of check, like whether an identifier is real, whether a paper actually supports a specific claim, whether a correlation holds up in our own data. The goal was never to replace the scientist's judgment. It was to get them to the judgment call faster, with the receipts already assembled.
That part worked. The part that didn't work first is the part worth writing about.
The failure that doesn't look like a failure
The problems with using AI for frontier research aren't the ones people usually warn you about. It's not that the model is obviously confused or refuses to answer. It's quieter than that. Identifiers aren't static: a gene referenced under one accession today might be reclassified under another next year, and a model has no way to know which vintage it's remembering. Ask an AI to find support for a hypothesis and it will, by default, go find support. That's just the shape of the question. Refuting a claim is often more valuable in actual research than confirming it, and that instinct doesn't come for free; you have to build it in. And sometimes there's genuinely no scientific consensus yet, or a correlation that can't be assumed causal, and a fluent answer will flatten that uncertainty into something that reads more confident than the evidence deserves.
I wanted to contextualize all of that into the system's design, so nobody had to keep reminding the model to be careful.
The moment that made the stakes concrete for me wasn't abstract. A scientist described a case where the model came back with a gene list that was, for all practical purposes, correct. The problem was underneath it: the identifiers attached to those genes were made up, or wrong, or didn't exist in the database at all. It cited a paper about an enzyme in the same class as the one in question, not the enzyme itself. To someone without deep domain expertise, that output looks polished and authoritative. To someone who checks, it collapses, and every downstream number now needs a full review.
The two ways that goes wrong aren't equally bad. If the identifier doesn't exist, you go looking for it in your own data and simply don't find it: annoying, but self-correcting. If you don't check and just build on it, you've trained a model on the wrong gene, and you won't find out until much later, when it's expensive.
Diagnosing the wrong bug
My first version of the copilot fired off the research loop the instant a scientist asked a question. It felt efficient. Feedback said otherwise: the answers weren't badly executed, they were aimed at the wrong thing. The system would pick an intent and run with it, and that intent was often too narrow, or just not what the scientist meant.
"Find candidate features for gut ammonia production" sounds specific. It isn't. Biology is redundant at nearly every level: multiple genes doing overlapping jobs, multiple pathways touching the same outcome from different angles. A question like that can mean several genuinely different research tasks depending on what you actually need. Do you want direct producers of ammonia, or should removal count too, since the real quantity is a balance between the two? Are proxy measurements acceptable, and if so, which ones, and which are off the table? Does this need to hold in humans, or is animal and hypothesis-stage evidence useful too? None of that is obvious from the question alone, and guessing wrong doesn't look like an error. It looks like a confident, well-cited answer to a question nobody asked.
That was the actual bug: the intent, not the execution.
The fix
So the system stopped researching first and started asking first. Before anything gets dispatched, there's a step whose only job is to interview the scientist about what they mean: what decision this feeds, whether proxy signals are acceptable and which ones, what scope of evidence counts, whether the relationship needs to be direct or can be broader. The system won't proceed until that's pinned down, the same way you wouldn't let a junior analyst start pulling data before agreeing on what question they're actually answering.
Once intent is fixed, the actual research fans out into the specialized checks I mentioned earlier — one tool confirms an identifier is real and current, another checks whether a paper's claim is about the specific enzyme in question rather than its whole class, another checks whether an association holds in our own cohort data rather than just in the literature. Each of those is a narrow, checkable thing, which is exactly why they're trustworthy: nobody is asking one generalist model to hold all of that context at once and get all of it right from memory.
I'll say only this much about the other half of the system, because it deserves its own post: candidate features don't just get research written in their favor. A second pass actively tries to falsify the first one, hunting for counter-evidence and misattributed claims before anything reaches a human. It's the same underlying instinct as the interview step. Assume the first pass can be confidently wrong, and design something into the system that checks it, rather than trusting it to check itself.
What changed
The difference showed up quickly once intent-capture was in place. Identifiers came back correct. Citations matched what a scientist would actually expect from that specific mechanism, not its neighborhood. In more than one case, the system surfaced papers a scientist was already independently reading, the kind of detail that's hard to fake and that visibly moved the needle on trust. The critiques it made about which features to keep or drop also landed; scientists said as much unprompted.
What I'm not sure about yet
The interview step has a real cost, and it's paid every time. Asking clarifying questions up front means a scientist waits before any research happens, and that friction doesn't go away just because the answer at the end is better.
The other open question is one I don't have an answer to yet: once intent is captured, the system converges on a feature set fast, and it's not clear whether that convergence is well-calibrated to each specific question or whether it's a strong prior that would land on similar features regardless of what was actually asked. I don't know which it is yet. I'd rather say that plainly than pretend the fast convergence is proof the system is right.
There's also no way to steer a run once it's underway. If a subagent starts drifting in the wrong direction, or something about the question changes halfway through, you can't correct it mid-flight. You just let that round finish and eat the wasted work. The interview step front-loads a lot of the judgment that would otherwise catch this, but it doesn't solve it entirely, and I haven't yet found a way to intervene on a running loop that doesn't reintroduce the same over-triggering problem the interview step was built to fix.