AI Engineer World's Fair 2026

How I automate my own job at Hugging Face using agents

Read the talk

How I automate my own job at Hugging Face using agents

Niels Rogge turns repetitive requests for research artifacts into a nightly workflow, then uses autonomous agents to handle the replies, improve documentation, and report results.

From a talk by Niels Rogge

Before you start: Basic familiarity with Python, GitHub issues and pull requests, and LLM tool calling will help you follow the implementation choices.

Getting research artifacts out of Google Drive

What happens when an interesting research paper has public model weights, but nobody can easily find them? Niels Rogge, a Belgian KU Leuven alumnus who describes five years working as a machine learning engineer at Hugging Face, encountered this repeatedly while following research on GitHub. Researchers published artifacts through Google Drive, GitHub releases, Dropbox, Zenodo, and other servers. The files existed, but finding and reusing them required following a scattered trail of links.

His intervention was straightforward: open a GitHub issue suggesting that the authors also publish their weights on Hugging Face, where hosting is free. Authors often agreed that the move made sense. This became a recurring part of the Community Science team's work—enough for Rogge to describe it as the Google Drive to the Hub team.

Community Science slide showing a GitHub reply about moving weights and a video dataset to Hugging Face, above Niels Rogge’s Google Drive-to-hub comment.Open full source frame
Community science as the “Google Drive -> hub team.”

The benefit goes beyond changing the download location. Hugging Face paper pages, sourced from arXiv, connect papers to their models and datasets. Metadata makes those artifacts searchable by task, language, and compatible library: someone looking for a depth estimation model or an LLM can filter for it instead of discovering it accidentally. Model cards and dataset cards supply documentation, while upload and download tooling makes the artifacts easier to use. Researchers gain visibility; downstream users gain a more direct path from a paper to its implementation.

0:280:58
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:28 · section reference included

A repeatable procedure that outgrew one person

The manual work consisted of repeated requests to release checkpoints or datasets, plus pull requests on the Hub to improve model cards and dataset cards. But the supply of research kept growing. Rogge points to hundreds of new arXiv papers each day and rising submission volumes at conferences such as NeurIPS. Writing each request personally could not keep pace.

The automation target was an existing procedure, with a clear branch based on where the artifacts already lived:

  1. Find the paper's GitHub repository, if one is available.
  2. Read its README and identify new models or datasets worth sharing.
  3. If the artifacts are already on Hugging Face, inspect their cards and metadata; open a pull request when documentation needs improvement.
  4. If the artifacts are absent, open a GitHub issue requesting publication on the Hub.
  5. Follow up with the author.

The last step matters: creating a request starts a conversation rather than completing the work.

Automating Community Science slide with a numbered workflow for reading a README, checking artifacts, opening a pull request or issue, and following up, beside an LLM diagram with retrieval, tools, and memory.Open full source frame
The outreach workflow, from finding a paper’s GitHub repository to following up with its author.
3:133:20
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:13 · section reference included

Start with a controlled workflow

Anthropic's Building Effective AI Agents provides the architectural distinction Rogge uses. A workflow puts LLM calls inside a predefined path. An autonomous agent lets the model choose tools repeatedly until it considers the task complete.

DesignWho chooses the path?Main trade-off
WorkflowApplication codeMore control; less flexibility
Autonomous agentModel operating in a tool loopMore flexibility; less predictability
HybridCode and model at different stagesBounded autonomy where needed

These are not mutually exclusive choices for an entire application. Different parts of the outreach process can use different amounts of autonomy.

For the initial build in 2024, Rogge chose the deterministic end of that spectrum. He took Anthropic's guidance to start simply—potentially with a single LLM API call—and avoid unnecessary agents or frameworks. His implementation replicated the manual procedure with direct LLM calls at individual steps. He later used Cursor and an Excalidraw MCP server to visualize the pipeline, but the runtime itself did not depend on an agent framework.

In Python, the routing decision can remain ordinary application code even when an LLM supplies the assessment. This compact example captures the artifact branch and produces a proposed action; it does not submit an issue or pull request:

python

from dataclasses import dataclass
from typing import Literal

Action = Literal["request_upload", "improve_card", "no_change"]

@dataclass(frozen=True)
class ArtifactAssessment:
    on_hub: bool
    card_complete: bool
    metadata_complete: bool


def propose_action(artifact: ArtifactAssessment) -> Action:
    if not artifact.on_hub:
        return "request_upload"
    if not artifact.card_complete or not artifact.metadata_complete:
        return "improve_card"
    return "no_change"


assessment = ArtifactAssessment(
    on_hub=True,
    card_complete=True,
    metadata_complete=False,
)
proposed_action = propose_action(assessment)
assert proposed_action == "improve_card"

The model can interpret research material while the surrounding program controls which branch runs next. That separation is the source of the workflow's predictability.

5:055:17
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:05 · section reference included

Run it nightly, then inspect the traces

Deployment was a nightly cron job: a Python script calling an LLM API, reading arXiv papers, and potentially opening GitHub issues or Hugging Face pull requests while Rogge slept. He used GitHub Actions, following Free Cron Jobs with Github Actions, and valued its accessible starting point and job-management UI. Scheduled Actions can be delayed, so this suits overnight processing rather than an exact-time guarantee. Rogge reports hundreds of GitHub issues created each night.

For observability, he uses Langfuse to inspect prompts, inputs, outputs, cost, and latency. The schedule answers when the program runs; traces answer what the model actually did during a run. That visibility becomes especially useful when a small recurring job produces a large volume of public-facing output.

6:597:08
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:59 · section reference included

The next bottleneck was the inbox

Automating issue creation moved the bottleneck downstream. Researchers replied, unread GitHub notifications accumulated, and Rogge still had to work through them like a mailbox. A few months before the talk, he automated that follow-up work too.

This time he chose an autonomous agent using the Claude Agent SDK. The immediate influence was an Anthropic workshop at AI Engineer New York in November of the previous year. Rogge interpreted its guidance as a shift toward agents because newer models could handle more of the control flow themselves. He accepted less predictability in exchange for flexibility.

Rogge cites a Cursor talk in London that described replacing a 12,000-line custom workflow with a 200-line skill. His own experience follows the same direction: work that previously required thousands of lines of custom logic can now be expressed through an agent, a command-line tool, and a skill. The skill supplies procedural knowledge; the model chooses how to apply it to the particular reply it encounters.

8:188:30
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

8:18 · section reference included

An SDK, a CLI skill, and a sandbox

The follow-up system uses the Python Claude Agent SDK. It initially ran Claude models; Rogge says he switched that week to GLM 5.2 through Hugging Face Inference Providers. That service brings providers such as Together.ai, Fireworks, and Cerebras behind a unified interface. He describes his integration as using OpenAI- or Anthropic-compatible interfaces.

Modal hosts the execution environment. The agent primarily uses Bash to run the Hugging Face CLI, with a Hugging Face CLI skill supplying instructions for Hub operations. It can then comment on GitHub and post final results to the team's Slack channel. The architecture separates three concerns: the SDK runs the agent loop, the CLI performs operations, and the skill explains how to use those operations.

Model choice was partly motivated by external evaluations. Rogge cites strong Cursor Bench performance and says GLM 5.2 beat Opus 4.8 on PostTrainBench while costing less. PostTrainBench concerns agents post-training small language models, not research outreach: the historical comparison used four small base models, seven evaluation benchmarks, and a one-H100, ten-hour budget per run. Its June 2026 changelog supports the historical ranking, while later auditing changed result eligibility; the talk supplies neither an outreach comparison nor a price calculation.

10:2510:37
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:25 · section reference included

One invocation, many issue-processing agents

Modal's batch processing provides the fan-out: parallel containers each run one agent loop for one GitHub issue. Rogge describes their startup as fast and finds the arrangement well suited to background work. The unit of parallelism is a conversation that needs follow-up, rather than an arbitrary fragment of a single agent's reasoning.

Although Modal supports cron scheduling, Rogge still starts follow-up manually. He invokes a Cursor skill he calls Process Unread Model; Composer 2.5, his usual Cursor agent, then invokes the other agents. Their results ultimately go to Slack. Manual initiation and autonomous execution coexist: he chooses when to process the backlog, while the workers handle the individual issues.

Automating Community Science slide labeled Invoked as a Skill, with two workflow bullets and a terminal screenshot showing a Modal job running in the background.Open full source frame
A skill fetches unread GitHub issues and Hub notifications, then posts results to Slack.

The Slack messages list research papers and the artifacts uploaded following outreach. Paper references in model cards or dataset cards cause those papers to be indexed on the Hub, connecting the completed documentation back to discoverability. Rogge says the messages appear a few minutes after he invokes the skill.

11:5812:09
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:58 · section reference included

Recipients experience it as personal outreach

Rogge says he does not disclose that an agent is posting. His reasoning is that people may immediately close an issue from a bot, while the generated requests resemble the messages he previously wrote himself. Recipients address him personally and thank him for the suggestion and clear guidance. He also sees what he believes are agents replying to his agents, prompting a joke about the dead internet.

Rogge reports only two negative comments among thousands of created issues to date. One recipient asked him to close the issue as slop; he says most instead accept that publishing their weights or datasets on Hugging Face is useful. That is his account of recipient feedback under an undisclosed-automation policy, rather than a measured comparison of disclosed and undisclosed outreach.

13:4413:56
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:44 · section reference included

From release requests to better model cards

The conversations sometimes return through other channels. An Apple researcher sent Rogge a direct message after an agent requested artifacts from an Apple paper. Other outreach concerned Google DeepMind mathematics datasets. Rogge also describes an email about publishing a 400-gigabyte dataset on Hugging Face. He reports that PaddleOCR, the OCR project, migrated all its OCR models to the Hub following agent-created issues.

Uploading files is only part of the work. Margaret Mitchell and her coauthors' Model Cards for Model Reporting motivates systematic model documentation, and Hugging Face provides a default template. In the Git diff Rogge presents, the agent fills that template using the paper's GitHub README, PDF, and related source material. The mechanism is source-based completion of an existing document structure.

One generated card credited Niels of the Hugging Face Community Science team as its author, even though Rogge had not explicitly requested that attribution. Other recipients thanked him for correcting their mistakes, although the agents had made the changes. These examples show how generated documentation can acquire a human identity as it passes into the normal contribution process.

A particularly visible example was the release request for Tiny Recursive Models, which had been trending on Hugging Face and Twitter. Rogge reports more than 60 upvotes on the agent-created issue requesting its Hub release. The request illustrates demand from downstream users as well as the researcher's opportunity for greater visibility. Rogge says he has hundreds of positive issue examples; the public release-request issue itself does not establish that publication was completed.

14:5115:01
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

14:51 · section reference included

Scaling useful work also requires evaluation

The obvious failure mode is an agent producing low-quality issues at internet scale. Rogge explicitly raises that concern and recommends Hamel Husain's LLM Evals FAQ, along with Husain's broader free writing and paid course. The talk points readers toward evaluation practice but does not describe an implemented evaluation suite or an acceptance threshold for outgoing messages.

His architectural conclusion is scoped to this work. He sees open models such as GLM 5.2 and DeepSeek V4 becoming capable replacements for closed models. For his use case, he now favors agents over elaborate workflows: a Hugging Face CLI, a skill explaining its use, and a sandbox provide the core execution setup. Evaluation remains necessary even as the custom orchestration code shrinks.

17:2517:34
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

17:25 · section reference included

Reusing discovery for Daily Papers

The same underlying research-discovery workflow powers Daily Papers, an account Rogge created on X. Rogge reports that Daily Papers passed 90,000 followers without his ongoing involvement. After deployment, it posts interesting research papers and Hugging Face artifacts every four hours, or when a noteworthy release appears.

Gemini selects the visual to accompany a post, extending automation from finding research to choosing how to present it. Rogge reports more than 2,000 likes on a Daily Papers post about NVIDIA releasing an optimized version of GLM 5.2. This is another destination for the discovery machinery: instead of asking researchers to publish artifacts, it tells potential users what has become available.

18:3818:49
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

18:38 · section reference included

Making benchmarks and research concepts accessible

Rogge closes with an effort to revive Papers with Code. He describes the original service as having been acquired by Meta and subsequently discontinued; his current effort aims to make research and the state of the art easier to access again.

The scope includes benchmark tracking, with OCR as his example, and educational explanations of concepts such as mid-training and on-policy distillation. The final slide places a mid-training explanation beside an olmOCR-Bench chart. This extends the Community Science goal beyond making artifacts available: readers also need ways to understand the research, locate relevant evaluations, and decide what to investigate next.

Papers with Code(.co) slide showing a post explaining mid-training beside an olmOCR-Bench line chart.Open full source frame
Papers with Code combines research explanations with benchmark tracking.
19:3219:43
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

19:32 · section reference included

Resources

From the talk

Updates since the talk

Transcript download
Read the transcript and explore slides

Loading transcript and slides…