OpenDraft: a 19-agent pipeline that checks every DOI before it cites it

The failure mode OpenDraft was written against

Most AI writing tools fail in a specific, expensive way: they produce a fluent paragraph with a plausible author, year and journal, and the reference does not exist. For a literature review or a thesis draft that is worse than an empty page, because the fake citation is harder to spot than a missing one. OpenDraft's README states the project was built after the authors kept running into exactly this, and the design follows from it: rather than trusting a model's assertion that a paper exists, the engine queries scholarly databases and drops anything it cannot confirm. The target user is named fairly precisely in the README: researchers preparing literature reviews or journal submissions, graduate students working on a thesis or dissertation, and developers who want to extend the pipeline itself. The README also lists who it is not for, including one-click final papers and assignment cheating, which is a candid framing rather than a marketing one.

How the 19 agents are arranged, and where the DOI gate sits

The README describes a pipeline of 19 specialized agents grouped by function: research, structure, writing, citation, polish and export. The research phase finds candidate papers through CrossRef, OpenAlex and Semantic Scholar plus web search, and then the citation stage confirms each DOI. The default rule, as stated in the README, is that a source is included only once its DOI is held by at least two of the three databases. Each citation also records which databases confirmed it and which ones the engine re-queried itself. That last detail matters more than the agent count. It means the output carries provenance per reference, so a reader can distinguish a citation confirmed by three databases from one confirmed by two, instead of getting a flat list where every entry looks equally trustworthy. The README is explicit that this establishes the DOI resolves in multiple databases and does not establish that the paper says what the draft claims it says. That distinction is the honest boundary of the whole design, and it is the sentence to hold onto when reading the feature list.

Installation, keys and the command-line surface

The README gives a setup time of roughly ten minutes for local installation and states Python 3.10+ as the requirement, matching the Python 3.10+ badge. Cost is not included: the README says you bring your own model API keys, and the At a Glance table estimates roughly $0.35 per draft on Gemini Flash up to roughly $3.00 on Claude Opus. Those figures come from the project's own table and are not something this review measured. Export targets are PDF, Microsoft Word (.docx) and LaTeX, and the LaTeX export arrived in v1.7.4. The README notes that the typical output is 5 to 80+ pages, 10k to 20k+ words and 30 to 50+ citations, and that those numbers were measured before multi-source confirmation became the default. That parenthetical is worth taking seriously: tightening the citation gate changes how many sources survive, so the older figures should not be read as a current expectation. One release note is also worth flagging for anyone installing from a wheel rather than a checkout: v1.7.3 fixed a Scribe FileNotFoundError by shipping prompt files in the wheel, so versions before that could fail on a missing prompt file.

What the citation gate does not check

The verification step confirms that a DOI is held by at least two of the three databases. It does not confirm that the cited paper supports the sentence it is attached to. A draft can therefore be fully clean on the reference list and still misattribute a finding, overstate a result, or cite a real paper for a claim that paper never makes. The README acknowledges this directly by saying the engine is a research assistance and drafting tool, not an autonomous author, and by carrying a Human Review Required badge. Treat the verification as a filter on fabrication, not on interpretation. The second limitation is coverage. All three databases are DOI-centric, so work without a registered DOI (many conference papers, preprints that were never deposited, non-English journals, books and grey literature) is structurally harder to confirm and more likely to be dropped by the two-database rule. A draft in a field that lives on arXiv preprints and workshop papers will come out thinner than one in a field with dense DOI coverage, and the engine has no way to tell you that is what happened. The third is that a stricter gate and a longer draft pull against each other: requiring two independent confirmations removes candidates, so raising the confirmation bar is the direct cost of the citation behaviour the project is selling.

Where the documentation is thin

The README points to EVALUATION.md for the benchmark plan, which is a plan rather than published results. Nothing in the supplied material gives measured citation precision, a false-positive rate for the two-database rule, or an accuracy comparison against a single-model baseline. The At a Glance numbers for word count and citation count are described as measured before the current default, so they do not describe the shipping configuration. The README also mentions that the maintainers use Codex and OpenAI models for PR review, regression test generation, issue triage and release automation, which is a statement about how the project is maintained rather than evidence about output quality. For an engineer deciding whether to adopt this, the practical consequence is that the verification mechanism is inspectable in the source but its error rate is not documented. You can read the code to see how a DOI is confirmed; you cannot read a number telling you how often the gate is wrong. That gap is the main thing to close before trusting the pipeline on real work.

The alternative, and the actual difference in approach

The obvious comparison is a general-purpose chat model with a search or retrieval plugin. The difference is not model quality, it is where the trust decision happens. A chat model with browsing decides during generation whether a reference looks right; the reference is part of the prose and there is no separate artefact recording what was checked. OpenDraft separates drafting from verification: the research phase proposes candidates, and an independent step re-queries CrossRef, OpenAlex and Semantic Scholar and applies a two-of-three rule before the citation enters the draft. The output also carries per-citation confirmation metadata, so the check is auditable after the fact rather than implied. That is a real architectural difference and it is the reason to pick this over a chat window for a literature review. The trade-off is that you inherit a fixed pipeline with 19 stages, a Python 3.10+ environment and your own API keys, where a chat model is one subscription and no installation. If your need is a two-page summary with a handful of links, the pipeline is more machinery than the task requires.

Licence, maintenance and what upgrading costs you

OpenDraft is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is not legal advice; if you plan to redistribute a modified engine or ship it inside a product, read the licence text yourself and check the terms of the model APIs you connect, since those are separate agreements and the MIT grant covers OpenDraft's code only. On maintenance, the repository is active rather than archived, with v1.8.0 in August 2026, v1.7.4 in July 2026 and a patch release the day before it. The release history shows the kind of cost you take on by tracking it: v1.7.3 was a packaging fix for prompt files missing from the wheel, and v1.8.0 changed citation confirmation to multiple sources by default. That second change is the one to watch on upgrade, because it alters how many citations survive into a draft. If you have prompts or downstream tooling tuned to the previous single-source behaviour, pin your version and re-run a known draft after moving to v1.8.0 rather than assuming the output will look the same.

Editorial conclusion

Adopt OpenDraft if you want a self-hostable, MIT-licensed pipeline that produces a structured first draft with citations whose DOIs were confirmed by at least two scholarly databases, and you are willing to supply your own model API keys and read the output critically. Do not adopt it if you need a finished submission, if you cannot pay for model tokens, or if your field's literature lives outside CrossRef, OpenAlex and Semantic Scholar's DOI coverage. Before committing, read EVALUATION.md to see what the benchmark plan actually measures, and run a single draft on a topic where you already know the canonical papers, then check whether those papers appear and whether the ones that do carry the two-database confirmation flag.

Official sources

1. federicodeponte/opendraft on GitHub
2. License: MIT
3. Project website
4. README
5. Releases