Hugging Face's Community Science team helps researchers move models and datasets from places such as Google Drive, Dropbox, and Zenodo onto the Hub.
2
Niels Rogge first automated outreach as a deterministic Python workflow running nightly on GitHub Actions, then used a more autonomous agent to handle follow-up.
3
The follow-up agent uses bash, the Hugging Face CLI, one skill, and a sandbox, with a separate container processing each GitHub issue.
Summary
Niels Rogge describes the Community Science team at Hugging Face as a "Google Drive to the Hub" team. Its members find papers whose models or datasets are stored on third-party services, then ask authors to publish them on Hugging Face, where artifacts gain metadata, documentation, and better discoverability. Manual outreach could not keep up with the number of papers, so Rogge reproduced his process as a deterministic workflow. A Python script calls an LLM at predefined steps, runs nightly through GitHub Actions, and uses Langfuse to inspect prompts, outputs, cost, and latency. He later automated issue follow-up with a more autonomous agent built using the Claude Agents SDK. That agent mainly uses bash and the Hugging Face CLI, with one container per issue. Rogge reports thousands of issues and only two negative replies, while researchers have moved models and large datasets to the Hub. He closes by arguing that open models now work well for this task and that evaluation still matters.
The team moves research artifacts from scattered services onto the Hub
Rogge says researchers often publish weights on Google Drive, GitHub releases, Dropbox, Zenodo, or other servers. That makes their work harder to find. Hugging Face paper pages can link a paper to its models and datasets, while metadata tags make artifacts searchable by properties such as task, language, or compatible library. Model cards and dataset cards add documentation, and Hugging Face tooling makes uploads and downloads easier. Rogge describes the Community Science team as the "Google Drive to the Hub team" because its outreach asks authors to place these artifacts in a central location.
Manual outreach follows a repeatable path that can be automated
When Rogge found a paper, he looked for its GitHub repository and read the README. He checked whether new artifacts were already on Hugging Face. If they were present but lacked proper model cards, dataset cards, or metadata tags, he could open a pull request. If they were absent, he opened a GitHub issue asking the authors to release them. He then followed up with the authors. Hundreds of papers arrive on arXiv each day, so opening these issues and pull requests by hand did not scale.
A deterministic workflow was the right first design
Rogge explains the difference between a workflow and an autonomous agent. A workflow puts LLM calls inside a predefined path, which gives more control and predictable behavior. An autonomous agent loops through tool calls until it decides the work is done, which gives it more flexibility but less predictability. He chose a workflow in 2024 after reading Anthropic's "Building effective agents" guidance, which recommended starting with a single LLM API and avoiding frameworks when they were unnecessary. His implementation reproduced his manual outreach path without an agent framework.
Nightly GitHub Actions runs handle outreach while Langfuse exposes what happened
The outreach system is a Python script scheduled as a nightly cron job through GitHub Actions. While Rogge sleeps, it reads hundreds of arXiv papers and may open GitHub issues or Hugging Face pull requests. He chose GitHub Actions because its free tier provides a practical way to run scheduled jobs and its interface makes them easy to manage. He uses Langfuse for tracing and observability. It lets him inspect the model's inputs and outputs, prompts, cost, and latency. The automation created so many issues that the resulting replies became a second task.
Follow-up needed a more autonomous agent because replies were less predictable
After automating issue creation, Rogge still handled replies himself. He later automated that follow-up with a fully autonomous agent. The change followed an Anthropic workshop where he heard that improved models might make agents a better choice than workflows. He also cites a Cursor talk in which a 200-line skill replaced 12,000 lines of custom workflow code. For his own system, a simple agent can replace much of the custom code, provided it has a command-line tool and a suitable skill.
The follow-up agent is small and centered on the Hugging Face CLI
Rogge's agent uses the Claude Agents SDK and initially used Claude models. He says he later switched to GLM 5.2 through Hugging Face Inference Providers, which gives access to several providers and open models through compatible interfaces. The agent's main tool is bash, which it uses to run Hugging Face CLI commands. It has a Hugging Face CLI skill and can comment on GitHub issues. It also posts results to a Hugging Face Slack channel. Rogge says this is enough for the work, rather than requiring a large collection of specialized tools.
Batch containers let each issue run in its own agent loop
For deployment, Rogge uses Model's batch processing feature to start many containers in parallel. Each container runs one agent loop and processes one GitHub issue. He says the containers start quickly and that this setup fits agents that run in the background or overnight. He usually invokes follow-up manually through a Cursor skill called "process unread." That skill starts an agent, which can invoke other agents, and then posts the gathered results to Slack. The automation reports which papers and artifacts became available on Hugging Face after the outreach.
Researchers usually accept the outreach, but Rogge does not disclose the agent
Rogge says he does not tell recipients that an agent wrote the GitHub issue because they may close a bot's message without reading it. He argues that the agent sends the same content he previously sent by hand. Among thousands of issues, he reports only two negative replies. Other researchers have thanked him, released models and datasets, or asked for help. Examples include a 400-gigabyte dataset, OCR models from PaddleOCR, and artifacts from papers by Apple and Google DeepMind. One issue for "Tiny Recursive Models" received more than 60 upvotes.
Evaluation remains necessary when an agent can post at scale
Rogge acknowledges the risk of an agent posting low-quality material across GitHub. He recommends Hamel Husain's "LLM evals FAQ" for people who want to learn how to evaluate agents. His conclusion is that open models such as GLM 5.2 and DeepSeek V4 are becoming capable enough for this work. He now prefers agents over workflows for his use case, with a single CLI, a single skill, and a sandbox. The automation is useful because it can act at large scale, but its quality still needs to be checked.
"At the time I started building a workflow which basically replicated the workflow that I was doing when I was doing this outreach."06:10
Who should watch
You are automating repetitive research outreach and need to decide between a fixed workflow and an autonomous agent.
Your system creates many tickets or messages, and you need a practical pattern for processing each item in isolation.
You want examples of scheduled LLM jobs, tracing, batch containers, and lightweight tool use rather than a large agent framework.
