From a Question to a Source-Grounded Run
For Feynman, the important workflow question is not simply where to search. It is how to decide what kind of investigation a question deserves, gather evidence through the right routes, and leave enough of a record to tell a checked result from an unfinished one. This makes planning and scale selection part of research itself. A reader who understands that lifecycle can choose between a focused direct search and a broader delegated run, interpret source-access limits, and judge what the final synthesis is actually entitled to say.
Planning is a control on scope
Feynman’s deep-research workflow starts by writing a plan with key questions, the evidence needed, an execution-scale decision, a task ledger, a verification log, and a decision log. That is more than project-management ceremony. Before a source is opened, the plan states what would count as relevant evidence and what uncertainty the run is meant to reduce. Without that step, a broad prompt can expand indefinitely: every new paper suggests another search, and the final answer becomes a record of attention rather than a reasoned selection.
The scale decision comes before delegation. Feynman’s workflow distinguishes a narrow question that can be handled by the lead agent with several targeted searches from a broad survey that benefits from multiple researcher agents. The distinction is operational. A small question has a short path from search to synthesis, so dispatching workers can add coordination overhead without adding useful coverage. A broad question can divide evidence gathering by source type or angle, provided the results are later consumed and reconciled rather than merely launched.
The repository is unusually explicit about the last point. In its delegated workflow, a launch receipt is not completion. Child results must be inspected in order, their actual output paths checked, and failures or missing evidence recorded before synthesis. Parallelism therefore changes the shape of the evidence problem; it does not eliminate the lead agent’s responsibility for the result. The documented implementation bounds the parallel workflow with a concurrency limit of four, a practical reminder that breadth is being managed rather than treated as infinite.
Planning also prevents a second kind of confusion: treating every workflow as if it promised the same output. Deep research aims at a cited brief. Literature review emphasizes consensus, disagreement, gaps, and trajectories. Audit compares a paper’s claims with a codebase. Replication extracts what is needed to rerun a claim and asks where execution should occur. Recipe work ties a reported result to a dataset, method, configuration, compute assumption, code path, and verification status. These are not competing personalities for one chatbot. They are different ways of defining the next justified research action.
A useful way to see the distinction is to imagine a reader asking Feynman about a new machine-learning method. If the reader needs orientation to a narrow concept, a direct search may be enough. If they need the state of a field, the run needs wider source coverage and explicit synthesis. If they want to know whether a reported number can be trusted, the relevant workflow shifts toward code comparison or reproduction. The question has not changed only in wording; its evidence threshold has changed.
The source layer has several routes
After the question and scale are defined, Feynman gathers evidence through a deliberately heterogeneous source layer. AlphaXiv is the primary academic route described by the project: it supports paper search, paper content retrieval, targeted questions, linked-code inspection, and persistent annotations. Web search covers material that academic indexes may not represent well, including official documentation, repositories, release notes, technical writing, and current information. The web package can route across providers, send several queries, apply domain or recency filters, retrieve bounded page text, and inspect bounded GitHub issues or pull requests.
The reason to combine these routes is not that more sources automatically mean a truer answer. Each route exposes a different kind of evidence. A paper may state a method and its results. A repository may reveal how the method is actually implemented. Documentation may explain a current interface that a paper predates. A release note may identify a behavior change. Feynman’s own workflows are designed around such differences: the source is part of the claim’s context, not a generic container of text.
For applied machine-learning research, the read-only Hugging Face tools make this principle concrete. Before a recipe or replication plan calls a dataset usable, the researcher can inspect its metadata, features, splits, access state, and small repository files. The file reader is not a weight downloader or bulk-shard reader; obvious model weights, archives, and dataset shards are refused. That restriction narrows convenience while protecting the distinction between checking whether an implementation path exists and silently acquiring a large external resource.
Feynman’s science workbench extends the source idea into domain-specific routes for literature, trials, regulatory data, chemistry, genes, proteins, variants, expression, genomes, regulation, and omics archives. The list is broad, but the important design fact is that these tools are not presented as one undifferentiated search box. A biomedical identifier, a paper citation, a dataset schema, and a code repository have different semantics and different ways to fail. Exact domain routes preserve some of those distinctions.
There is also a capability gradient. The documentation says that Feynman can fall back to web search when AlphaXiv authentication is unavailable, but that the fallback loses some academic metadata, discussion threads, and source-specific paper text. That does not make the fallback useless; it changes what the run can support. A search path with fewer bibliographic relationships may still locate a paper, but it may be weaker for mapping citations or asking section-specific questions. The system’s job is to preserve that difference rather than silently treating all routes as equivalent.
Direct and delegated paths
A narrow direct run is comparatively simple. The lead agent chooses several varied queries, gathers the most relevant source text, extracts findings, and writes a synthesis. The key control is query diversity: a definition or history search, a mechanism search, and a current-use or comparison search can reveal different parts of the same topic. The result should still record the terms used and the evidence each term uncovered, so the reader can tell how the search frame shaped the conclusion.
A broad delegated run adds a coordination layer. Researcher tasks may divide papers, web sources, repositories, or specific questions. Each task needs a short brief and a declared output. When the results return, the lead agent must verify that the expected artifacts exist, note ordinary child failures, and reconcile overlap or disagreement. A parallel worker can improve coverage; it can also introduce inconsistent source standards or leave an empty handoff. Feynman’s workflow treats the returned artifact, not the intention to produce one, as the meaningful boundary.
That boundary creates a useful failure taxonomy. If a child search returns no usable result, the gap belongs in the evidence record. If the provider is unavailable, the run may continue in degraded mode with the capability marked as limited. If synthesis begins before child outputs are consumed, the problem is a workflow error. If the final brief contains a claim no source supports, the problem is a verification failure. The stages are connected, but their failures should not be merged into a vague statement that “the research was done.”
The diagram’s loop matters. Verification can send a run back toward another source search rather than acting as a ceremonial final stamp. A source may contradict another source, a method may be underspecified, or a citation may support a narrower claim than the synthesis used. In each case, the next step is determined by the gap.
Full text is an access decision
Feynman’s paper-access path makes the source boundary especially visible. It records access candidates from academic and open repositories, source-specific text services, landing pages, and DOI resolvers. Those candidates have different meanings. A fetchable text API can supply content for section extraction. A PDF URL can establish that a document is available without being a text route the resolver will parse. A DOI landing page identifies the canonical publication while leaving access dependent on the publisher or repository.
The system also separates legality from convenience. Its access plan states that it records legal open-access and publisher or repository candidates and does not bypass paywalls. It validates external URLs as HTTP or HTTPS and rejects unrelated metadata when resolving an identifier. These are not peripheral security checks. If a research run quietly substituted the wrong paper or treated an inaccessible document as if it had been read, every later citation would inherit the error.
When source-specific full text is available, Feynman can extract canonical sections and attach evidence spans to the section and surrounding text that produced them. PaperRank can then use those spans for methodology and reproducibility screening. But the durable artifacts retain bounded metadata such as full-text status, length, section information, and evidence spans rather than raw full-text bodies. The design gives later readers a location and a reason for attention without turning every research manifest into a copy of the source corpus.
That choice has a cost. A bounded artifact is easier to move, inspect, and protect, but it cannot preserve every nuance of a long paper. A later reviewer may need to retrieve the source again. The repository itself acknowledges that a source-specific route may be unavailable and that an access candidate is not the same as fetched text. In other words, “available” is not one state. It can mean that a legal link was found, that a source-specific fetch succeeded, or that enough extracted material was retained for a particular screening task.
Synthesis changes the status of the result
The final stages—extraction, synthesis, and verification—are where Feynman’s lifecycle earns its source-grounded description. Extraction turns pages, metadata, code, or datasets into claims, methods, entities, and limitations that can be compared. Synthesis organizes those findings into a coherent answer. Citation links each important claim to the evidence that supports it. Verification asks whether the source actually supports the wording, number, attribution, or conclusion attached to it.
That last distinction is essential because citation presence is weaker than citation fit. A source can be on the same topic while failing to support a particular claim. Feynman’s workflow documentation therefore treats URL reachability and semantic support as separate concerns. A dead or unrelated link cannot carry a claim, but a live link is not enough if the prose outruns what the source says. Where verification cannot be completed, the workflow is expected to preserve a blocked or partial status rather than conceal the gap.
The result is a layered output. A brief may be the most readable artifact, but the plan, research notes, citations, verification record, and open questions explain how much weight it deserves. A replication plan may be valuable even when no experiment has run. A literature review may map disagreement without resolving it. A source access report may establish a route without establishing the paper’s conclusion. The status of the artifact depends on the stage it represents.
This is also why Feynman’s source diversity should not be sold as automatic comprehensiveness. Providers have different coverage, authentication, rate limits, and freshness. Delegated searches can fail or overlap. Full-text retrieval can stop at a legal access boundary. A model can synthesize a packet incorrectly. The workflow provides places to record those conditions; it does not remove them.
By the end of a run, the useful question is not merely, “Did Feynman produce a report?” It is, “What did the run establish, through which route, with what remaining dependency?” Once that question becomes habitual, a plan, source, synthesis, and verification record can be read as connected states rather than as unrelated output files. The next step is to make those states explicit: to distinguish a present artifact, a recorded check, a partial run, and a scientifically supported conclusion.