Scientific literature search often requires more than retrieving papers from a single query: users' intents are underspecified, preference-dependent, and evolve through interaction. Existing search agents typically rely on fixed pipelines or implicit language-only reasoning, making their search strategies difficult to control, inspect, and refine. We introduce PaperPilot, a multi-turn literature search agent that frames scientific search as workflow induction. Given an anchor paper and a user query, PaperPilot constructs an executable DAG of paper-search operators, including keyword search, citation expansion, filtering, scoring, reranking, and evidence extraction. User feedback is then used to refine both the query and the workflow itself. We train PaperPilot with supervised workflow imitation and preference optimization over controlled workflow corruptions. Experiments show that PaperPilot-9B improves over the base Qwen3.5-9B toolset agent under multi-turn interaction, increasing Hit@5 from 58.0 to 77.0, MRR from 47.5 to 59.4, and nDCG@10 from 26.8 to 32.5, while reducing workflow execution errors from 9.5% to 0%. These results show that explicit, editable search workflows provide an effective and controllable interface for aligning literature search agents with complex scientific intent.
Alex: Welcome to another episode of ResearchPod.
Sam: Today we're looking at a system called PAPERPILOT. The central idea is that searching for scientific papers shouldn't be a one-shot process. It should be something an AI can actively revise based on your feedback—the way a real researcher would.
Alex: So the argument is that current AI search tools are too rigid for how researchers actually work?
Sam: Exactly. Think about how you'd actually look something up for a school project. You don't just type one question and accept whatever comes back. You look at the results, decide they're too broad or too old, and then adjust your approach. A standard AI agent doesn't do that well. If you ask for follow-up work on a paper and then say "that's too broad, I want recent applications," it typically just adds the word "recent" to its original search and tries again. PAPERPILOT does something fundamentally different—it treats your feedback as instructions to rebuild the entire search process from scratch.
Alex: So instead of tweaking a single dial, it's rebuilding the whole machine?
Sam: That's a good way to put it. Think of it like a water filtration system. If the water comes out dirty, you don't just pour it through the same filter again—you change the mesh, or add a new layer. PAPERPILOT builds that kind of layered system for your search. It organizes the process as a series of connected steps—keyword searches, citation checks, date filters—arranged in a specific sequence that flows in one direction and never loops back on itself.
Alex: So instead of a black box that spits out a list, it's building a visible, step-by-step plan?
Sam: Exactly. And because the plan is visible, the agent can go back and surgically swap out one step when you give it feedback. If you say "focus on recent papers," it doesn't just add a word to a text box. It physically removes the general search step in its map and replaces it with a date-filtered one. The rest of the plan stays intact.
Alex: Does that actually make the results better, or is it just more complicated?
Sam: The study indicates it makes a meaningful difference. By making the search process explicit and editable, the system reduced the number of times it failed to execute a search correctly—from around ten percent of attempts down to zero. It also improved how accurately it ranked the most relevant papers compared to a standard agent using a fixed pipeline.
Alex: That's a significant improvement just from changing how the agent thinks about its own work. The key isn't more data—it's better control over the method.
Sam: That is the core insight. A rigid system can be very powerful and still fail you, because it can't adapt when your needs shift. By treating search as an editable plan rather than a fixed command, the agent can align itself with your specific, evolving intent. It's not just guessing at what you want—it's iterating toward it.
Alex: How do they actually teach it to build these plans without it making a mess?
Sam: They use a two-step training process. First, they show the model thousands of examples of successful search plans—essentially, a strong "teacher" model demonstrates what good looks like, and the student model learns by imitation. The second step is about learning from contrast. They create pairs of search plans: one that works correctly, and one with a broken or illogical step. The model is then trained to consistently prefer the working version.
Alex: So it's learning to recognize the shape of a failure before it makes one—not just copying success, but actively avoiding the patterns that lead to bad results.
Sam: That's a precise way to put it. Like a student who studies model answers but also reviews a list of common mistakes. And that combination turns out to matter quite a bit, especially for smaller models.
Alex: Smaller models being the ones with less computing power behind them?
Sam: Right. Smaller models often struggle with these kinds of structural edits—they tend to lose track of the plan mid-way through. But the researchers found that their training approach helped even these smaller models stay on track, bringing their error rate down to zero as well. The key insight is that when a model understands the structure of the search—when it has a clear map to follow—it doesn't need to be massive to be reliable. It just needs to be organized.
Alex: That's a meaningful finding on its own. It suggests the bottleneck isn't always raw computing power—it's having the right framework.
Sam: Precisely. It's a shift in emphasis—from building smarter machines to building better-structured ones.
Alex: Are there limitations the researchers flag?
Sam: A couple of important ones. The system is limited to a pre-set library of search tools, so it cannot invent entirely new ways to search on its own. If the right tool isn't in its toolkit, it can't improvise. The researchers also note that testing was done primarily on computer science papers, so how well the approach transfers to other fields—medicine, history, law—remains an open question.
Alex: So it's capable within its domain, but it isn't a universal research assistant yet.
Sam: That's a fair characterization. It's a specialized tool that works well within defined boundaries. The researchers suggest that future work will likely focus on letting the agent design its own search tools from scratch, which would make the system considerably more flexible.
Alex: That's a clear look at how structuring AI workflows—rather than simply scaling them up—can lead to more reliable results. Thanks for walking us through it, Sam.
Sam: My pleasure. Thanks for listening to ResearchPod.