Paper2Rebuttal: a nine agent pipeline for writing conference rebuttals

What the framework is for

RebuttalAgent is an AI-powered multi-agent system that helps researchers craft high-quality rebuttals for academic paper reviews. The system analyzes reviewer comments, searches relevant literature, generates rebuttal strategies, and produces formal rebuttal letters, all through an interactive human-in-the-loop workflow.

The framing in the project documentation is worth noting, because it positions the tool as an assistant rather than an author. The human-in-the-loop is described as iterative, with the strategy review step and the natural language feedback step both being places where the author is expected to intervene.

The key features are six. Automatic paper parsing converts PDF papers to structured text using Docling. Issue extraction breaks down reviewer comments into actionable issues with priority levels. Literature search automatically searches arXiv for relevant supporting papers. Strategy generation creates data-driven rebuttal strategies, and the parenthetical in the feature list is a deliberate one, not sophistry. Rebuttal writing generates formal, conference-ready rebuttal letters. And a human feedback loop iteratively refines strategies based on author input.

The project is the official implementation of the paper Paper2Rebuttal: A Multi-Agent Framework for Transparent Author Response Assistance, accepted by ACL 2026 main conference, with the paper on arXiv as 2601.14171. The project page and a Hugging Face Space are linked, and the documentation recommends deploying locally, saying the hosted space can be very slow, taking up to an hour to finish.

The nine agent pipeline and what each stage contributes

The system uses a multi-agent pipeline, and the documentation lists every agent with its role.

| Agent | Role | |-------|------| | Semantic Encoder | Compresses paper into high-density format | | Issue Extractor | Extracts and merges reviewer concerns | | Literature Retrieval | Decides if external papers are needed | | Reference Filter | Filters relevant references | | Reference Analyzer | Analyzes supporting literature | | Strategy Generator | Creates rebuttal strategy and to-do list | | Strategy Reviewer | Reviews and improves strategy | | Rebuttal Writer | Writes formal rebuttal letter | | Rebuttal Reviewer | Polishes final rebuttal |

The shape of this list is the interesting part. The literature stages are three separate agents rather than one, and they are ordered by increasing cost: retrieval decides whether external papers are needed at all, the filter narrows the candidates, and the analyzer reads the survivors. That ordering is what keeps the expensive literature analysis from running over every reference the reviewer mentioned.

The other pattern is a generator and a reviewer for each artefact. There is a Strategy Generator and a Strategy Reviewer, then a Rebuttal Writer and a Rebuttal Reviewer. The reviewers are not a separate opinion, they are part of the pipeline, so the quality of the output depends on the review stages running rather than on the writer model being good enough first time.

The Semantic Encoder at the front is what makes the rest affordable. Compressing the paper into a high-density format once means the issue extraction and strategy stages are not re-reading the full PDF for every reviewer comment.

Setting up the environment and the API keys

The installation is a conda environment, Python 3.10, and the requirements file:

conda create -n rebuttal python=3.10
conda activate rebuttal
# if you want to run on GPU , please firstly install the GPU version of PyTorch (select the one based on your CUDA version)
pip install -r requirements.txt

The requirements are pinned: docling at 2.30.0, fastapi at 0.128.0, gradio at 6.2.0, httpx with the socks extra at 0.28.1, openai at 2.14.0, Requests at 2.32.5, python-dotenv at 1.0.0 or newer, PyYAML at 6.0, google-generativeai at 0.8.0 or newer, and hf_xet at 1.0.0 or newer.

Configuration is by environment file. You copy the example and fill in the key for the provider you chose:

cp .env.example .env

The example file ships empty keys for six providers, and the documentation is explicit that you should only configure the provider you plan to use, and that you can also edit the base_url in .env.

The repository layout shows the shape of the implementation. There is app.py, which is the Gradio entry point, rebuttal_service.py, which holds the pipeline logic, llm.py for model access, arxiv.py for the literature search, tools.py for shared helpers, and a prompts/ directory holding the per-agent prompts. There is also an assets/ directory and a .env.example.

Since the prompts are separate files, an agent's behaviour is a prompt rather than code, which is the right shape for a system where the stages are all language model calls.

Launching the interface, and the performance numbers to plan around

The web interface is launched with a port argument:

python app.py --port 8080

And with GPU acceleration for the PDF parsing stage:

python app.py --device cuda --port 8080

The performance figures in the documentation are the part you should plan around. Literature analysis involves parsing multiple external papers using Docling, which is computationally intensive, and the documentation strongly recommends using GPU acceleration. In CPU mode, processing a full workflow may take up to 1 hour. In GPU mode with CUDA, processing typically takes only about 15 minutes. And the hosted Hugging Face Space is described as very slow, taking up to an hour to finish.

So the expected turnaround is somewhere between a quarter of an hour and an hour depending on your hardware, and a rebuttal deadline is a few days. That is workable but it is not interactive in the way a chat assistant is, and it is the reason the documentation pushes you to deploy locally.

There is a Windows wrinkle on the first run. On Windows you may need to run the terminal as Administrator for the first run, because the PDF parser Docling needs to download AI models that require symlink permissions. Alternatively you can enable Developer Mode. There is also a first run cost, since the first run may be slower as Docling needs to download AI models from Hugging Face, and subsequent runs will be much faster.

Session recovery and the review workflow

A long pipeline that runs in a browser is vulnerable to the browser being closed, and the documentation handles that.

If the browser page is accidentally refreshed during processing, you can resume your session. You enter your API Key in the configuration section, click Refresh List to see active sessions, select your session from the dropdown, and click Resume Selected Session.

The limit is stated plainly. If the server restarts, the app will attempt to restore sessions from gradio_uploads, but this is best-effort and depends on saved logs and summaries, so some in-memory progress may be missing. That is the right thing to know before you rely on it, because a lost session on a long GPU run is a real cost.

The user-facing workflow is five steps. You upload your paper PDF and a review text file, the raw document including all reviewers' comments and their IDs. The system parses your paper and extracts reviewer issues. For each issue, you review the AI-generated rebuttal strategy. You refine strategies through natural language feedback. And finally you download the rebuttal letter and the strategy summary.

That middle of the workflow is the human-in-the-loop in practice. The system produces a strategy per issue rather than one letter, and the author corrects the strategies before the letter is written. The output is a pair of artefacts, the letter and a strategy summary.

Where Paper2Rebuttal is the wrong tool

The first limit is the time budget, and it is the practical one. Up to an hour on CPU, about fifteen minutes on a GPU with CUDA, and the hosted space can also take up to an hour. A deadline of two days leaves room, but a deadline of two hours does not, and the fix is hardware rather than configuration.

The second is the hardware requirement itself. The documentation strongly recommends GPU acceleration, and the pipeline depends on Docling parsing external papers from arXiv. A machine with no GPU is not a slower version of this tool, it is a different and much less pleasant experience.

The third is that the literature search is limited to arXiv. The Literature Retrieval agent decides if external papers are needed and the search is an arXiv search, so a rebuttal that needs to cite a workshop paper, a technical report or a patent will not find it, and the strategy will be built on a narrower evidence base than a human reviewer would use.

The fourth is the Datasets item in the todo list, which is still unchecked. The code release, the paper release and the Hugging Face demo are done, but the datasets are not, so there is no published evaluation set in the repository for you to reproduce the paper's numbers with, and the analysis of the paper itself is in the arXiv entry rather than in the code.

Compare that with doing the rebuttal by hand with a general purpose assistant. The difference in approach is that a general assistant gives you one conversation about one paper, while this pipeline applies a fixed decomposition that separates extraction, retrieval, strategy and writing, and produces a strategy document you can audit before the letter exists. For a deadline with several reviewer comments and a need to ground the response, the structure is the argument for it, and the hour on CPU is the argument against.

Licence, project state and what to check before you run it

The platform does not record a licence for this repository, so the terms are not stated in a file you can point at from the project page, and the LICENSE file is not in the top level listing either. For an academic project that is a low practical risk, since the paper is on arXiv and the code is public on GitHub, but if you intend to build on it in a commercial product, you should establish the licence position directly with the authors rather than assume the usual research licence.

The project state is straightforward. The code and paper were released on 2026-01-21, a WeChat group was created on 2026-01-23 for discussion, and the acceptance by ACL 2026 main conference was announced on 2026-04-06. The repository is not archived, and the last push was on 2026-08-04, so the tree is about two and a half months old relative to today. It publishes no GitHub releases, so there is no version to pin, and the version of the software you get is whatever the default branch holds.

What to check before you run it is a short list. Set up the environment with conda and the requirements file, and if you intend to use the GPU path, install the GPU version of PyTorch that matches your CUDA version first, because the documentation puts that step before the requirements install.

Then create the.env file and configure only the provider you will use, since the documentation says to configure only the provider you plan to use and the example file ships six empty key sets. And decide where the sessions live, because the resume feature depends on the gradio_uploads directory and the recovery is best-effort.

Finally, if the response to your reviewers is going out under your name, read the generated letter rather than the strategy summary. The pipeline has a review stage for the letter, but a reviewer of your rebuttal is reading your words, and the human step in the workflow is there for exactly that.

Editorial conclusion

Paper2Rebuttal fits an author facing a real rebuttal deadline who wants structured help on literature grounding and issue coverage, and who is willing to run a local pipeline with their own model API key and a GPU to get usable turnaround. It does not fit an author who wants a finished letter in ten minutes, because the documentation puts a CPU run at up to an hour and a GPU run at about fifteen minutes, and the hosted space can also take up to an hour. Before you rely on it, read the pipeline table so you know which agent produces which part of the output, set up the.env file with only the provider you intend to use, and keep the human review step in the loop rather than shipping the generated letter unread.

Frequently asked questions

Official sources

1. AutoLab-SAI-SJTU/Paper2Rebuttal on GitHub
2. Issues
3. README