OneResearchClaw: a skill-routed pipeline from raw materials to research reports
Any research. One Claw. 🦞 From any materials to research with fully autonomous & skill-driven researcher.
At a glance
- What is it?
- OneResearchClaw turns meeting audio, documents, tables, archives and cloud links into exported research reports through a staged agent pipeline with query confirmation and a review loop. The design is opinionated about where humans stay in the loop, and the documentation leaves several operational questions open.
- Who is it for?
- Adopt OneResearchClaw if your raw material is messy and multi-format (meeting recordings, PDFs, tables, ZIP bundles, arXiv or video links) and you want the grounding, literature search and export stages chained without manual handoffs. Do not adopt it if you need a stable, frozen output contract, because the project is at v0.1.0 and the README announces capability changes on consecutive days in April 2026.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 130 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The handoff problem OneResearchClaw is built around
The README frames the problem in workflow terms rather than model terms: real materials are scattered across formats and locations, and the usual response is to manually connect keyword extraction, research and summarization across separate stages. OneResearchClaw's claim is that you supply files in different formats and the system performs structuring, keyword extraction, deep research, content synthesis and multi-format export in one run. That is a concrete complaint about tool boundaries, not about model quality. The intended user is someone who already has material in hand (a recorded meeting, a document set, a table, a ZIP of mixed files) and needs a report out of it, and who currently pays the cost of moving that material between tools by hand. The project is written in Python, requires Python 3.10 or later per the README badges, and is MIT licensed.
Routing input types to grounding skills
The pipeline is described as multi-format input to research report generation. On the input side the README lists meeting audio and video, documents, tables, PPT files, ZIP mixed-material packages, plus arXiv, YouTube and Bilibili links. The stated mechanism is type detection followed by routing: the system identifies the material type and sends it to the corresponding grounding skill, which is where the material is converted into a grounded note that later stages consume. The skills catalog is a named section of the README, so skills are a first-class concept rather than an implementation detail, and the repository topics include both llm-agents and self-evolving. Cloud links are handled by a separate ingestion path: pasting an arXiv, YouTube or Bilibili link causes the system to download it locally and then enter the same workflow. This matters because it means the link path is not a different pipeline, it is a pre-step that produces local material for the same grounding stage. The README does not describe the internal interface between a grounding skill and the research stage beyond the grounded note, so anyone extending the skill set should expect to read the source.
Query confirmation, depth modes and the review loop
Before retrieval begins, the system generates candidate queries from the grounded note and lets the user confirm, add, delete or modify them. The README's justification is alignment with the user's real research direction and reduced irrelevant retrieval and token waste. This is the clearest human checkpoint in the pipeline, and it is a deliberate one: the system does not silently decide what to search for. Depth is a second control, exposed as simple, medium or complex, and the README says these modes govern literature search, source opening, evidence organization and report analysis depth. The README does not state the concrete budgets behind each mode, so treat the mode names as labels until you inspect the code. After a report is generated it enters a review then rewrite loop, where different models or review perspectives check completeness, evidence consistency, logical coherence and over-claiming, and revise through bounded rounds. Bounded is the operative word: the loop is not open-ended. Meeting input gets one more stage, multi-topic splitting, which identifies multiple topics in a long discussion and generates independent reports that each go through grounding, research, summary and export separately.
Getting it running
The README's quick start section is the entry point, and the release notes give the version to target: v0.1.0, tagged 2026-04-20. The environment requirement is Python 3.10 or later, stated in the README badge. Beyond that, the supplied material does not include the actual install command, the CLI invocation, or the configuration keys, so I cannot give you a verified command line here. What the material does name as user-facing controls are the research depth values (`simple`, `medium`, `complex`) and the export formats (`md`, `docx`, `pdf`, `pptx`, `audio`), with both Chinese and English export supported. Those are the settings to look for first when you open the repository. If you need a runnable command before committing time, read the quick start section and the skills catalog in the README directly rather than trusting a summary, including this one.
Where the pipeline is the wrong tool
The review loop is bounded by design, which means it improves a draft and then stops. If your requirement is a report that has been checked against a source of truth you control, this pipeline does not offer that; it offers consistency and coherence checks by models, which is a different guarantee. The query confirmation step is also a constraint in disguise. It is valuable when you know your research direction, and it is friction when you are running unattended batch jobs over many inputs, because each run expects a human to confirm or edit queries unless you have a way to skip that stage. Finally, the project is at v0.1.0 with a single release, and the news entries describe capability changes landing on 2026-04-13, 04-16, 04-17, 04-19, 04-20 and 04-21. That cadence is normal for an early project and it also means interfaces can move. Pin to a commit if you build on top of it. The README does not discuss failure modes for malformed input, so test your own material types before relying on the routing.
How it differs from a general agent framework
A general agent framework such as LangChain or LlamaIndex gives you primitives (chains, tools, retrievers) and leaves the workflow to you. OneResearchClaw ships the workflow itself: grounding, query confirmation, literature research, synthesis, review and rewrite, then export to five formats. The difference is where the decisions live. With a framework you decide the stage order and write the glue between an audio file and a literature search. Here the stage order is fixed by the project and the extension point is the skill, which is why the README maintains a skills catalog and why the 2026-04-21 news entry about Skill-Evolve matters: it saves personalized preferences as selectable derived versions of skills, so the pipeline adapts to how you work rather than requiring you to rewrite the pipeline. That is a real architectural difference, and it is also a commitment. You get less freedom to reorder stages and more of the pipeline pre-built. If your research process is unusual, a framework plus your own orchestration will fit better.
Licence, maintenance and upgrade cost
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive baseline and it is the same licence used by most Python tooling, so incorporating OneResearchClaw into a larger internal system does not by itself create a copyleft obligation. This is not legal advice; read the LICENSE file and your own counsel if the output is distributed. The maintenance cost is the more interesting number. The project is at v0.1.0, last pushed 2026-05-09, with six dated news entries inside a nine-day window in April 2026. That is a fast-moving pre-1.0 codebase. Upgrading means re-checking the skills you depend on and the depth-mode behaviour, because the release notes tie new capabilities to those areas. Skill-Evolve adds a second cost: derived skill versions accumulate as users save preferences, so you will want a policy for which derived versions are active in a shared deployment. The README does not describe that policy.
Who should adopt it and what to verify first
The fit is narrow and specific: you have a pile of heterogeneous material, you want a structured report out of it, and you are willing to sit at the query confirmation step. The multi-topic meeting splitting is the feature most likely to justify the adoption on its own, because producing several focused reports from one long discussion is tedious to do by hand. Teams that need deterministic, auditable outputs, or that run fully unattended over thousands of inputs, should look elsewhere or expect to modify the pipeline. Before adopting, verify three things in the repository: the actual install and run commands in the quick start section, the concrete behaviour of the `simple`, `medium` and `complex` depth modes in the source, and the termination condition of the review loop. Those three determine whether the pipeline matches your workload, and none of them is fully specified in the README.
Editorial conclusion
Adopt OneResearchClaw if your raw material is messy and multi-format (meeting recordings, PDFs, tables, ZIP bundles, arXiv or video links) and you want the grounding, literature search and export stages chained without manual handoffs. Do not adopt it if you need a stable, frozen output contract, because the project is at v0.1.0 and the README announces capability changes on consecutive days in April 2026. Before running anything, verify which Python packages the pipeline pulls in for audio and video handling, what the simple, medium and complex depth modes actually change, and where the review loop stops.
Community notes