Feynman Review: Is This Open-Source AI Research Agent Ready for Teams?

Feynman is one of the most complete open-source attempts to turn deep research into an auditable terminal workflow. Give it a topic and it can search papers, websites and repositories, delegate work to four specialist agents, draft a sourced brief, check citations, compare a paper with its code, plan a replication and monitor a topic over time.

Our verdict after reviewing the public code and documentation on 3 September 2026: Feynman is a strong pilot candidate for technical research teams, but “fully local” describes a possible configuration, not every default workflow. Model calls, search providers and cloud GPUs can still move data outside your machine and create usage cost. Citation checks reduce a dangerous failure mode, but they do not replace a scientist, engineer or analyst who can judge whether the evidence is sufficient.

This page owns the product-specific “Feynman review” and “open-source AI research agent” decision. Our LangChain Deep Agents review covers a general-purpose agent harness, Agent Reach covers low-cost source access, and LLM-as-a-Verifier covers fine-grained trajectory scoring. Keeping those jobs separate prevents a branded tool review from competing with broader architecture guides.

What is Feynman?

Feynman is an MIT-licensed research-first CLI built on the Pi agent runtime and alphaXiv. Its official README describes research workflows for deep investigation, literature review, paper ranking, drafting, peer-style review, code audit, replication, ML recipes and recurring watches. Outputs are written to local project folders, with provenance artifacts for source-heavy workflows.

The four-agent story is useful, but the workflow is more important than the headcount. Feynman stores plans, intermediate research, drafts, verification notes and final outputs as files. That gives a team reviewable handoff points and a recovery path when a long run fails. It also means sensitive research notes need the same access, retention and backup policy as any other working dataset.

How does Feynman deep research work?

The project does not immediately unleash a swarm. Its deep research workflow starts with a written plan and waits for approval. Narrow explainers remain lead-owned; broader surveys can delegate parallel searches. The system then extracts findings, synthesizes agreement and disagreement, and runs a final claim-to-source verification pass.

1. Plan the question. Define subquestions, source strategy, task ledger and verification log before spending model budget.
2. Choose the scale. Keep a narrow question with one lead agent, or parallelize a broad evidence search.
3. Extract, do not merely summarize. Capture methods, results, limitations and claim locations from the strongest sources.
4. Synthesize conflicts. Separate consensus, disagreement and unanswered questions instead of forcing one neat answer.
5. Verify before delivery. Reopen cited sources, test whether they support the attached claim, and record gaps.

This plan gate is good product design. It makes scope and source standards visible before the expensive part begins. The quality still depends on the prompt, the selected model, retrieval coverage and the reviewer who approves the plan.

What can Feynman do beyond a literature review?

Is Feynman really fully local?

It can be configured for local model inference, but a normal research workflow still reaches external sources. The standalone installer documentation says the prebuilt bundle includes a pinned Node.js runtime and verifies its SHA-256 before replacement. An npm installation is also available and requires a compatible Node version. For supply-chain-sensitive teams, inspect the script, pin an exact release and verify the published checksum rather than treating a pipe-to-shell command as a policy exception.

Feynman's setup guide supports hosted providers, Amazon Bedrock, LM Studio, LiteLLM, Ollama and vLLM. A local model can keep prompts and inference on infrastructure you control. Paper search, web retrieval, alphaXiv, optional hosted parsers and cloud compute still cross a network boundary unless you deliberately replace or disable them.

Use a simple data-flow test before calling the system local:

• Where does the research prompt go?
• Which provider receives URLs, documents, repository content or search queries?
• Which fetched pages are cached, where, and for how long?
• Which credentials and OAuth tokens are stored under the Feynman home directory?
• Does telemetry leave the machine, and does your policy allow its metadata?

“Runs from my terminal” is an interface statement. “All data stays on my machine” is an architecture claim. Verify the second one from the exact provider and search configuration you deploy.

Does Feynman eliminate hallucinated citations?

No, but it creates a much better failure boundary than citation-shaped text with no verification step. The verifier is instructed to fetch each URL, locate the supporting passage, classify the claim as supported, overstated, contradicted or unsupported, remove claims it cannot source, and avoid fake certainty. That is the right direction.

Three limits remain. A live URL can contain weak evidence. A source can support the words while the model misses a methodological flaw. Search can omit the paper that changes the conclusion. Treat the final brief as an auditable draft, not an autonomous sign-off. Our AI agent evaluation and sandbox checklist shows how to add deterministic checks, adversarial cases and human approval around agent output.

Can Feynman audit and replicate papers?

The code audit workflow extracts concrete paper claims, then searches the associated public repository for matching configuration, training and evaluation behavior. It reports mismatches, missing implementations and reproducibility risks with file locations. That is valuable due diligence before a team builds on a published result, but it cannot inspect private training code, unavailable data or undocumented operator choices.

The replication workflow creates requirements, an experimental recipe, underspecified details, risks and success criteria. It executes only after the user chooses local, isolated, Docker, Modal, RunPod or plan-only operation. This approval boundary matters because a replication can download untrusted code, process licensed data and spend real GPU budget.

Use the word “replicated” only when the planned checks passed against preserved scripts and raw outputs. A plausible plan is not a reproduction, and a matching headline metric is not enough if the dataset split or evaluation path changed.

Do recurring research watches run automatically?

Only when scheduling capability is actually available. The watch documentation says Feynman always creates a baseline and follow-up plan, but schedules recurrence only when its scheduling tool is visible. Otherwise it records the gap and gives you a refresh prompt. That is honest behavior and an important operational detail for teams expecting continuous monitoring.

What does Feynman cost?

The software is MIT licensed, so there is no licence fee. The total cost of an accepted research output has at least five other lines:

• Model inference: lead-agent reasoning, parallel researchers, review, writing and verification all consume tokens or local compute.
• Search and extraction: some providers are keyless, while hosted search, parsing and grounding services may charge by request or result.
• Experiment compute: local GPU time, cloud GPU minutes, storage and data transfer can dominate a replication.
• Human review: a domain expert must resolve uncertain evidence, unsupported implications and risky recommendations.
• Operations: version pinning, credentials, retention, monitoring, provider changes and failed runs require ownership.

Measure cost per accepted brief or verified experiment, not cost per model call. A cheap report that takes two senior hours to repair is expensive. A more costly run that exposes disagreement early may be the better system.

Who should adopt Feynman?

A two-week Feynman pilot that produces a buying decision

1. Choose one repeatable research question. Use a topic where your team already has a trusted human brief and known must-find sources.
2. Freeze the acceptance rubric. Score recall of must-find evidence, irrelevant-source rate, claim support, reviewer corrections and time to approval.
3. Pin the release and model. Record the Feynman version, model, search route, prompts and retrieval date so runs can be compared.
4. Start without experiment execution. Validate discovery, synthesis and citation support before granting code or GPU access.
5. Run one adversarial topic. Include conflicting papers, a dead link, a paper with incomplete code and an attractive unsupported claim.
6. Review the data flow. Map every hosted provider, credential, cache, retention window and outbound request.
7. Test one paper audit. Have an engineer verify a sample of reported matches and mismatches directly in the repository.
8. Test one bounded replication plan. Compare its requirements and assumptions with a domain expert before any compute spend.
9. Count total cost. Include tokens, search, GPUs, failed runs and reviewer minutes.
10. Set the adoption gate in advance. Expand only if accepted-brief time or evidence coverage improves without lowering citation support or control.

Research boundary

Status checked 3 September 2026 against Feynman's public repository, license and official workflow documentation. This is an independent architecture and buyer review, not a sponsored post, security audit or controlled benchmark. We did not install Feynman, submit private documents, connect paid providers or execute a GPU replication. The project is moving quickly, so pin a release and recheck its current documentation before adoption.