Every knowledge worker eventually encounters the same wall. You have read twenty sources. You understand each one. You have notes, highlights, annotations. And then you sit down to write and discover that the raw material does not arrange itself into an argument. The passage from "I have read these sources" to "I have an argument based on these sources" requires something that did not happen automatically during the reading process.
That something is synthesis, and it is where most research workflows have no support at all.
Tools for finding sources have proliferated. Search is better than it has ever been. Academic databases surface related work well. Web browsing history and bookmark managers help retrieve things you have already seen. Note-taking tools make it easier to capture what you read. None of these tools address the synthesis step. They get you to a well-populated research folder and leave you there.
What Synthesis Actually Requires
Synthesis is often described as combining or summarizing multiple sources, but this undersells what the task actually involves. Summarizing multiple sources produces a collection of summaries. Synthesis produces a position, a view about what the sources collectively imply, where they agree and where they differ, and what argument can be built from what they collectively show.
This requires several specific cognitive operations that are difficult to support with standard note-taking tools.
The first is claim extraction: identifying the specific claims in each source that are relevant to your question, as opposed to summarizing the source's overall argument. A long paper might contain ten claims, three of which are directly relevant to your inquiry and seven of which are context or method. Distinguishing these requires knowing your question well enough to evaluate each claim against it.
The second is relational mapping: understanding how the claims across your source base relate to each other. Does Source A's finding support, contradict, qualify, or simply not engage with Source B's? When two sources address the same phenomenon from different methodological angles, are they saying compatible things or incompatible things? This relational structure is the skeleton of synthesis. A flat list of source summaries contains none of it.
The third is gap identification: recognizing where your source base has insufficient coverage to support a claim you want to make. A well-synthesized argument knows where it is strong and where it is thin. A researcher who has not synthesized their sources yet cannot see the gaps, because the gaps only become visible when you try to assemble the argument and find the pieces missing.
The fourth is the synthesis move itself: deciding what position is defensible given the relational structure you have built. When Source A and Source B point in the same direction and Source C points elsewhere, what do you do with Source C? Incorporate it as a complication, challenge its methodology, note it as a limitation, or find that it addresses a different enough question that it does not actually conflict? This decision requires judgment, and it is genuinely different from any of the steps that precede it.
Why Tools Leave This Step Unassisted
The synthesis step is difficult to support with software for a straightforward reason: it is the part of research where the researcher's specific question, judgment, and argument are irreplaceable. Tools can retrieve sources, capture notes, and surface patterns in a corpus. They cannot decide what position is defensible given those sources, because that decision depends on context that only the researcher holds.
This has led to a kind of learned helplessness around synthesis in the tool space. Because AI cannot perform the final synthesis move for you, some tool builders conclude that AI has nothing useful to offer in this area. The result is tools that handle acquisition and retrieval well and offer no synthesis support at all, leaving researchers to do the hard part entirely in their heads.
We think this is the wrong conclusion. The synthesis step requires judgment that tools cannot replicate. But the inputs to that judgment, a clear view of which sources address which claims, which sources agree and disagree with each other, where the relational gaps are, can be supported computationally. Making those inputs visible and navigable reduces the cognitive load of synthesis without attempting to automate the synthesis itself.
The Silent Synthesis Problem
There is a quieter version of the synthesis problem that is worth naming separately: researchers who believe they have synthesized their sources when they have not.
The most common form of this is sequential summarization: writing a literature review or a background section that moves through sources one at a time, summarizing each in turn. This is not synthesis. It is documentation. A reader of the resulting section encounters a parade of positions without a map of how they relate or what they collectively imply. The researcher has demonstrated familiarity with the literature without producing an argument from it.
Sequential summarization feels like synthesis because it requires having read and understood multiple sources. But understanding sources sequentially is compatible with not having formed a view about their relationships. You can move from "Smith says X" to "Jones says Y" to "Chen says Z" without ever asking whether X, Y, and Z are compatible, and if not, which is more credible given the evidence.
This failure mode is particularly common in long-form research precisely because the volume of sources is large enough that getting through them at all feels like a significant accomplishment. When you have read fifty sources, writing a section that documents what each one says can fill substantial pages and create the feeling that the synthesis work is done. The emptiness of the argument only becomes apparent to a reader who comes to the section expecting a view, not a survey.
How We Think About Supporting Synthesis in Pilgrim
When we started building Pilgrim, synthesis support was the hardest design problem on the table. The instinct is to build toward automation: could the system produce a synthesis of the sources in a project? We decided fairly quickly that automating the synthesis move is the wrong goal. Synthesis requires the researcher's judgment, and any system that attempts to make that judgment removes the researcher from the part of the process where their expertise matters most.
The design direction we pursued instead was synthesis scaffolding. The goal is not to synthesize for the researcher but to make the inputs to synthesis visible and navigable. This means: a view of which sources address which questions in the project; a way to see where sources agree, where they diverge, and where the source base is thin; the ability to pull claims from specific sources into a draft section with their relational context attached.
The synthesis view in Pilgrim is oriented around argument structure rather than source structure. You see your developing position, the claims that support each part of it, the sources those claims come from, and the places where sources provide conflicting evidence. The goal is to give the researcher a real-time view of the current state of their argument so that synthesis judgments can be made against an accurate picture of the source base, not against a mental model that may have drifted from what the sources actually say.
Synthesis remains the researcher's job. Our position is just that the researcher should not have to do it entirely in their head while working from a flat list of saved documents. The cognitive load of holding the relational structure of a large source base in working memory while simultaneously trying to form an argument is significant. Offloading the structural visibility to a tool leaves the judgment, which is where the work actually lives, in the hands of the researcher who has the context to exercise it.