Hmm… For now, first of all, there is no problem with it not being an LLM. I think the practical approach is to imagine who you want to find the model or project, work backward from there, and make the best use you can of the Hub’s different building blocks:
The first thing I would separate is what “category” means here, because several different questions are being mixed together:
-
What kind of repository or service should contain each artifact?
Model, Dataset, Space, Storage Bucket, GitHub, etc.
-
Which Hub task or pipeline_tag should be used?
For example, text-generation, image-text-to-text, or another input/output task.
-
Which descriptive tags should help people find it?
For example, persistent-ai, stateful-agent, or cross-session-memory.
-
How should the complete project be presented?
As a chatbot, companion, autonomous service, research project, radio application, agent runtime, and so on.
Those do not need to have the same answer.
The Hub’s formal task categories are not intended to be a complete ontology of every kind of AI system. They primarily describe the “shape” of a model API—its inputs and outputs—and help select search filters, inference handling, and widgets. The documentation explicitly describes the taxonomy as relatively coarse-grained and recommends ordinary tags for finer distinctions.
So the fact that “Chatbots” does not fully describe persistence, identity, memory, or continuous operation is understandable, but it does not necessarily mean that the chatbot classification is wrong. It may simply describe how users interact with one surface of the system, rather than what the whole system is.
A project can simultaneously be:
- a chatbot from the user-interface perspective;
- text generation from the model API perspective;
- a stateful or persistent agent from the system-design perspective;
- a continuously running service from the operational perspective;
- and a research project from the publication perspective.
No single tag has to carry all of that information.
A practical mapping
I would choose each location according to what visitors should be able to use, download, inspect, or reproduce there.
| What you want people to find or use |
Most practical home |
Notes |
| A working conversational experience, radio UI, API frontend, or interactive demonstration |
Space |
The backend may run inside the Space or elsewhere. The card should say which is the case. |
| A codebase, runtime, scheduler, memory layer, agent loop, SDK, or backend implementation |
GitHub |
GitHub can remain the canonical development repository, while a Space provides the hosted demonstration. |
| Reusable weights, checkpoints, adapters, tokenizer files, processors, or model configuration |
Model repository |
This remains appropriate even if the model is not an LLM or uses an unusual architecture. |
| Fixed evaluation sets, versioned benchmark results, anonymized traces, reproducibility snapshots, or published logs |
Dataset repository |
Best when Git history, review, cards, and reproducible versions matter. |
| Live memory, frequently changing state, caches, raw operational logs, intermediate results, or continuously arriving traces |
Storage Bucket |
Buckets are mutable and non-versioned, unlike Model, Dataset, and Space repositories. |
| A project containing several Models, Datasets, Spaces, and Papers |
Collection |
Useful as a map or landing page for the complete project. |
| The method, definitions, related work, controls, evaluation protocol, results, and limitations |
Technical report or paper |
This can later connect to a Hugging Face Paper Page and the associated artifacts. |
The project does not need to fit into one repository.
For what you describe, one possible arrangement would be:
- Space: the public conversation and radio experiences;
- GitHub: the canonical code, if there is code that can be published;
- Model repository: any independently reusable checkpoint or model artifact;
- Dataset: fixed evaluations, public test cases, redacted traces, and reproducible result snapshots;
- Bucket: live mutable state, internal working data, or continually updated traces;
- Collection: the page that explains how all the Hub artifacts relate to one another.
If the implementation is proprietary, that does not prevent the Space or project page from being useful. It just becomes especially important to state clearly:
- what runs locally in the Space;
- what is provided by an external hosted endpoint;
- what can be downloaded;
- what can be reproduced;
- what can only be evaluated as a service;
- and which page is the canonical source of current information.
The important distinction is not “LLM versus non-LLM.” It is closer to:
Is the reusable artifact a checkpoint, a codebase, an application, a dataset, a state store, or a complete hosted system?
A more detailed decision guide
Use a Model repository when the checkpoint is itself a reusable artifact
A Model repository is a good fit when another person can meaningfully do one or more of the following:
- download the weights;
- run inference;
- fine-tune or adapt the model;
- convert it to another format;
- inspect its configuration;
- use it from a supported or custom library;
- compare it with other checkpoints.
It does not have to be an LLM, and it does not have to follow a mainstream architecture. The Hub already contains vision, audio, reinforcement-learning, diffusion, scientific, multimodal, and many other kinds of models.
A code-heavy model project can also split responsibilities. For example, Microsoft’s BitNet implementation is developed on GitHub, while the corresponding weights are distributed through a Model repository. The Hub repository does not need to be the main software-development repository merely because the project uses a model.
If no weights or reusable checkpoint are being distributed, a Model repository may still serve as a system card or project description, but readers should be told that explicitly so that they do not arrive expecting downloadable model files.
Use GitHub when the main contribution is code or system architecture
GitHub is usually the more conventional canonical home when the main artifact is:
- an agent framework;
- a runtime;
- a memory manager;
- a scheduler;
- a set of services;
- an orchestration layer;
- an SDK;
- a backend application;
- or a larger code project with tests, CI, releases, issues, and external contributors.
The Space can then be a thin hosted frontend or reference deployment.
Hugging Face documents an official GitHub-to-Hub synchronization workflow. The hub-sync action can mirror files to Spaces, Models, or Datasets. Another option is for the Space to install a tagged release of the GitHub package.
If the Space depends directly on a moving main branch, the demo may change or break unexpectedly. Pinning a package release, Git tag, or commit is usually easier to reproduce.
Use a Space when the usable artifact is the experience
A Space is the natural entry point when the main thing people should do is:
- talk to the system;
- watch or listen to it;
- submit inputs;
- inspect outputs;
- call a demonstration API;
- or experience the complete application.
The Space does not need to contain every component. It can call an external API or backend, provided that the boundary is documented clearly.
For a continuously running application, it is also useful to distinguish the public interface from the always-on worker. A 24/7 radio is not only a model task; it is also an application involving scheduling, state, media generation, and hosting.
On free hardware, Spaces may sleep when unused. Indefinite execution may therefore use paid Space hardware or an external service, while the Space remains the public interface or demonstration.
Use a Dataset repository when the data should be versioned and cited
Examples include:
- evaluation prompts and expected properties;
- benchmark inputs;
- fixed conversation histories;
- anonymized multi-session examples;
- published system traces;
- red-team cases;
- failure cases;
- versioned result tables;
- periodic snapshots exported from live state;
- or a reproducibility package associated with a paper.
A Dataset repository is still a Git repository. It is well suited to data that should have a history, documentation, stable revisions, discussions, and reviewable changes.
It is less suitable as a database that the running application rewrites on every interaction.
Use a Storage Bucket for mutable operational data
Hugging Face describes Storage Buckets as S3-like, mutable storage without Git history. They are intended for frequently changing files such as logs, checkpoints, and intermediate artifacts.
That makes a Bucket a natural candidate for:
- live memory exports;
- caches;
- user uploads;
- generated media;
- continually updated logs;
- raw traces;
- shared application state;
- and files mounted into a Space.
A useful pattern is:
running system -> private Bucket
|
+-> reviewed/versioned export -> Dataset repository
In other words, the Bucket can hold the changing operational state, while selected snapshots are exported to a Dataset when they become something that should be reviewed, compared, cited, or reproduced.
Hugging Face also supports an agent trace viewer for traces placed in either Datasets or Buckets. Public traces need careful review because they may contain prompts, tool inputs, command output, paths, secrets, private code, or personal data.
Use a Collection to explain the complete project
A Collection can group Models, Datasets, Spaces, and Papers on one page. Hugging Face explicitly lists “showcase and share a complete project with its paper(s), dataset(s), model(s) and Space(s)” as a use case.
A Collection does not replace the individual cards, and it is not necessarily the code repository. Its value is that it gives visitors a map:
Project Collection
├── Main Space
├── Radio Space
├── Model repository, if applicable
├── Evaluation Dataset
├── Paper
└── Other related artifacts
The GitHub repository and external service documentation can then be linked prominently from the Collection description and the relevant repository cards.
Choose one durable source of truth
Splitting the project into several artifacts is useful, but it can create a second problem: visitors may not know which page contains the current explanation.
I would choose one canonical landing page—perhaps the Collection, the main Space card, or the GitHub README—and ensure that every other page links back to it.
That page should answer, near the top:
- What is this?
- Who is it for?
- What does “persistent” mean in this project?
- Which parts are public?
- Which parts are proprietary?
- What can be downloaded, cloned, tested, or reproduced?
- Where should a user, developer, or researcher start?
- Which page and version should be cited?
For example, “persistent” could refer to several different properties:
- state surviving a process restart;
- memory surviving across conversation sessions;
- a stable user profile;
- a continuing relationship model;
- an autonomous scheduler continuing without an open chat;
- a world state that keeps changing;
- accumulated skills or learned procedures.
Defining which of those are intended will make the project easier to understand and compare, regardless of the formal Hub category.
Task category versus ordinary tags
For the formal pipeline_tag, I would choose the closest description of the main model/API interaction.
For the public demo, “chatbot” may still be a reasonable interface label even if it is incomplete. It tells visitors what they can do on that page. The persistent or autonomous properties can then be expressed separately through ordinary tags and the card.
Possible descriptive terms might include:
persistent-aistateful-agentcross-session-memorylong-term-memorylong-horizon-agentautonomous-agentcontinuous-operationidentity-continuitylong-term-personalization
These are suggestions for human-readable vocabulary, not official standardized Hub tasks.
It may help to use more than one precise term rather than expecting persistent-ai to cover every meaning. A card can also define the project’s terminology directly:
In this project, “persistent” means that state and memory survive process restarts and separate user sessions, and that new information can update previously stored information.
That kind of definition is more informative than a category name alone.
When would a formal new Hub task be useful?
A normal custom tag can be used immediately. A formal Hub task is a larger proposal.
According to the Hub task documentation, task integration may affect:
- model and dataset filtering;
- input validation;
- Inference API behavior;
- library integration;
- task icons;
- and interactive widgets.
The documented starting point is an “Adding a new task” issue in the huggingface_hub repository.
Before going that far, it would be useful to determine whether persistent-ai represents:
- a search and vocabulary problem;
- a reusable agent/runtime interface;
- a benchmark category;
- a distinct inference protocol;
- or a completely new Hub product surface.
A formal task proposal becomes easier to evaluate when there are concrete answers to questions such as:
- Are there multiple public implementations?
- Do they have a shared input/output or session protocol?
- Who owns and returns the persistent state?
- Is identity part of the request?
- Is the result only a response, or also state changes and scheduled actions?
- What could a common widget demonstrate?
- Is there a shared benchmark?
- What specifically cannot be represented with an existing task plus ordinary tags?
These are not stated formal acceptance requirements. They are simply useful materials for making the proposal concrete enough for maintainers and future readers to assess.
If the immediate need is only “help people find systems with cross-session memory,” a community tag convention may be much lighter and more effective than a new inference task.
Discoverability is larger than the task filter
Choosing metadata matters, but it is unlikely to be the only way people discover a project at the current scale of the Hub.
The Hub full-text search indexes Model Cards, Dataset Cards, and Space app.py files. That makes the text of the card important, not just its tags.
I would write the card for people who do not already know the internal project vocabulary.
For example, someone may search for:
- persistent AI;
- stateful agent;
- cross-session memory;
- long-term conversational memory;
- autonomous agent runtime;
- continuously running AI;
- AI companion;
- long-horizon agent;
- persistent identity;
- agent memory.
If the card only uses a project-specific acronym, those people may never connect their question to the project.
A practical rule would be:
Use metadata for Hub filters, but use the card to explain the project in the ordinary language that users, search engines, researchers, and other developers are likely to use.
The repository card should remain the durable source of truth. Other channels can bring people to it:
- a Collection;
- a Social Post;
- a longer Community Blog Article, where available;
- a Forum thread;
- GitHub;
- an arXiv paper;
- a Hugging Face Paper Page;
- Daily Papers;
- social media;
- external articles and search engines.
These are discovery routes, not substitutes for documentation. If a Post or paper sends someone to a page that does not explain the artifact boundaries, the result is more attention but not necessarily more understanding.
Other discovery routes within Hugging Face
Posts and Blog Articles
The current HF PRO documentation lists publishing Social Posts and Community Blogs among PRO features. Blog Articles can also be published by eligible members of Team or Enterprise organizations.
A short Post is suitable for:
- a release;
- an update;
- a new demo;
- or a call for feedback.
A Blog Article is better for:
- a system overview;
- an architecture explanation;
- a research update;
- a tutorial;
- a release announcement;
- or an explanation of how the Model, Space, Dataset, GitHub repository, and paper relate.
Neither should replace the canonical project card.
Forum categories
The Forum describes Research as a place for research questions and project coordination. It describes Show and Tell as a place to showcase Spaces, Models, Datasets, and other projects.
One possible division is:
- Research: definitions, evaluation protocols, category design, related work, and requests for collaboration;
- Show and Tell: the finished or usable project, demo, and release announcement.
That avoids using one thread simultaneously as a taxonomy proposal, technical paper, support request, and product announcement.
Papers and Daily Papers
If there is an arXiv paper, HF Paper Pages can connect it to related Models, Datasets, and Spaces. Linking the arXiv or Paper Page from each repository card allows the Hub to extract the arXiv ID and expose the relationship.
Daily Papers is then an additional research-discovery and discussion route. It is not the paper host or artifact repository itself.
A useful relationship is:
arXiv paper
-> HF Paper Page
-> Model
-> Dataset
-> Space
-> Collection
-> GitHub
Applying that to the two examples in the post
Conversational system
The conversational interface can remain a chatbot or conversational Space even if that does not describe the whole architecture.
The complete description might instead be distributed as:
- interface: chatbot;
- primary output task: the closest existing generation task;
- system description: persistent/stateful agent;
- state behavior: cross-session memory and identity continuity;
- runtime: GitHub or proprietary hosted backend;
- public experience: Space;
- evaluation artifacts: Dataset;
- live state: Bucket or other operational storage.
24/7 radio
A continuously running radio does not necessarily need a new model task. It may be more naturally described as an application or service built from several components:
- text or script generation;
- speech generation;
- memory;
- scheduling;
- media playback or streaming;
- a persistent state store;
- and a continuously running worker.
The Space can be the listener-facing page or demo, while the continuous worker runs on paid Space hardware or external infrastructure.
Its model components can still be linked as Models if they are independently reusable.
In both cases, the system can be new or unusual without requiring every aspect of it to be encoded in one Hub task label. Whether the underlying method is technically novel is a separate question from how its public artifacts should be organized.
Who to contact
There may not be one specific person who handles this complete question.
The practical routes seem to be:
| Goal |
Most appropriate public route |
| Discuss terminology and find similar projects |
The Forum |
| Develop a community tag convention |
The Forum, supported by concrete examples |
| Propose a formal Hub task |
The documented huggingface_hub issue route |
| Report a specific Hub bug or missing feature |
The relevant public GitHub issue tracker or Site Feedback |
| Receive contractual organizational support |
The support channel included with an applicable Team or Enterprise plan |
The current Team and Enterprise plan documentation lists different support levels, including forum access, best-effort support, email support with an SLA, and advanced Slack support depending on plan.
However, I would not make direct access to a product team a prerequisite for moving forward. Enterprise support is primarily an organizational support channel; it should not be assumed to guarantee a product-taxonomy consultation.
For a general categorization question, a well-scoped public proposal is likely to be more reusable than a private conversation because it can be reviewed asynchronously, linked to examples, improved by other users, and found by future projects with the same problem.
A useful proposal would include:
- the narrow definition of the proposed term;
- several representative public examples;
- the user group that needs to find them;
- the current workaround;
- the concrete limitation of that workaround;
- and whether the request is for a tag, task, widget, API protocol, or repository type.
A compact possible layout
Putting the above together, a project of this kind might look like:
Canonical landing page
Collection, main Space card, or GitHub README
Public experience
HF Space: conversation
HF Space: radio
Canonical code
GitHub repository
tagged releases
tests and documentation
Reusable model artifacts, if available
HF Model repository
Versioned research/evaluation artifacts
HF Dataset repository
Live mutable state
private HF Storage Bucket or another operational store
Research description, if applicable
arXiv / other paper venue
HF Paper Page
Discovery routes
Hub search
Posts
Blog Article
Forum Research / Show and Tell
Daily Papers
external search and social media
That structure makes it possible for different audiences to arrive through different routes without forcing the entire system into a single category.
If research publication, citation, licensing, or IP also matters
This is a separate issue from Hub classification, but it can affect publication order.
A common research-publication layout is:
- arXiv or another paper venue: method, related work, evaluation, controls, limitations, and claims;
- GitHub: canonical software development;
- GitHub Release + Zenodo: an archived, citable software version;
- HF Model or Dataset: citable ML artifacts;
- Space: runnable demonstration;
- Paper Page and Collection: links among the pieces.
Hugging Face can issue DOIs for Models and Datasets. A DOI is intended to identify a persistent revision, so it is worth deciding which artifact and version should be treated as stable before generating one.
The code, weights, datasets, documentation, and hosted service may require different licenses or terms. Upstream licenses from base models, libraries, datasets, voices, media, or other dependencies still apply.
A dated release or paper can help create a public record of what was disclosed and when, but a license governs reuse; it does not establish technical originality.
If patent protection may be relevant, publication order can matter because public disclosure may affect patent novelty, and the rules differ by jurisdiction. That decision is better made before publishing implementation details. This is a situation for appropriate legal or patent advice rather than a Hub metadata decision.
In brief
My answer to the three questions would be:
-
Can it be classified on the Hub today?
Yes. Non-LLM is not a problem. Use the closest task for the primary API interaction, descriptive tags for persistence and autonomy, and split the project among Space, GitHub, Model, Dataset, Bucket, and Collection according to the actual artifacts.
-
Could a tag convention be useful?
Possibly. Ordinary descriptive tags can be used immediately. It would help to define exactly what is persistent—memory, identity, process, relationship, world state, or something else—and see whether several independent projects converge on the same vocabulary.
-
Is a formal new task needed?
Maybe eventually, but only if there is a concrete shared protocol, inference behavior, widget, or search need that existing tasks plus ordinary tags cannot represent. A formal task is more than a label.
-
Who should be contacted?
The Forum is suitable for developing terminology and gathering examples; the documented GitHub issue route is suitable for a formal task proposal. Direct product-team access should probably not be treated as a necessary first step.
The most important practical step is probably not finding one perfect category. It is creating one clear, durable source of truth, then putting each reusable component where the people who need it are most likely to find and use it.
