antgroup/agentic-ai-landscape: A Curated CSV Behind a Next.js Map of Agent Infrastructure
Data driven agentic landscapes and insights. Produced by Ant Open Source and inclusionAI.
At a glance
- What is it?
- The repository is a dataset and publishing pipeline, not an agent framework. Its value depends on whether you need someone else's curated shortlist of agent and model infrastructure projects, and whether you can live with curation fields that record a selection caveat next to every entry.
- Who is it for?
- Adopt it if you need a pre-filtered, machine-readable shortlist of agent and model infrastructure projects with a stated selection reason per row, and you are willing to read selection_caveat before trusting any entry. Skip it if you need exhaustive coverage or a library to build on: this repository ships a dataset, a Next.js viewer and Python collection scripts, not an agent runtime.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Is Discovery, Not Orchestration
Agent tooling is easy to find and hard to rank. A search for agent frameworks returns hundreds of repositories with overlapping descriptions, and the usual sort key, stars, rewards projects that were popular two years ago. This repository takes a different position: it publishes a shortlist. The README states the landscape highlights projects that are currently most representative of each ecosystem rather than attempting to cover every project. That is a deliberate editorial act, and it is the whole product. The audience is therefore narrow and specific. It suits an engineer or technical lead who needs to justify a build-versus-adopt decision and wants a starting list rather than a search result page. It also suits analysts tracking which layers of the agent stack are consolidating. It does not suit anyone who needs complete coverage of a category, because completeness is explicitly out of scope. The two top-level blocks, Agent Infra and Model Infra, split the problem along a sensible seam: application, framework, runtime and tools on one side; data, training, serving and deployment on the other. That split is the cleanest thing in the README, and it maps directly onto how teams actually allocate headcount.
A CSV Keyed by repo_id Is the Actual Artifact
The canonical dataset is data/agentic-ai-projects.csv, and the README describes its schema precisely enough to reason about. Each row is keyed by the GitHub repo_id, which means the join key is stable across renames, unlike owner/name slugs. Each row carries GitHub metadata (stars, forks, license, language, topics), OpenDigger signals (openrank_* and participants_*), and four curation fields: landscape_layer, landscape_section, selection_reason, selection_caveat. Those last four fields are the interesting design choice. Most curated lists publish a ranking and hide the reasoning. Here the reasoning is a column you can filter on. selection_caveat in particular is unusual: a dataset that ships a caveat field per row is telling you where its own confidence is thin, and that is more useful than a confidence score nobody can audit. The vitality signal is OpenRank rather than star count. The README says activity from issues, pull requests, reviews, and contributors is taken into account. That matters for agent projects specifically, where a repository can accumulate stars from a conference talk and then go quiet for a year. OpenRank comes from OpenDigger, which is listed among the initiating communities, so the metric and the maintainers are connected. Treat that as a disclosure, not a disqualification, but do read the OpenDigger methodology before you treat an openrank_ value as a verdict.
Two Consumers, One File: Next.js Site and Python Scripts
The architecture has a single source of truth and two readers. The production Next.js application lives in apps/landscape-web and, per the README, reads the canonical project dataset directly. That means the site has no separate content store to drift out of sync with the CSV. The second consumer is the collection and publishing pipeline in scripts/, which is Python and writes back into the same dataset. Data flows one way for the site and one way for the pipeline: scripts gather GitHub metadata and OpenDigger signals, humans or agents fill the curation fields, and the web app renders whatever the CSV currently contains. The repository also holds dated, bilingual analyses under insights/, case studies under insights/case_studies, and automatically generated weekly snapshots under insights/weekly_reports_by_agents. The weekly reports being agent-generated is worth flagging: they are snapshots of newly surfacing projects, and the README does not describe a review step between generation and publication. If you cite a weekly report, check whether the projects it names appear in the canonical CSV with a selection_reason, because that is the only place the curation judgement is recorded.
Running the Preview Locally
For the web preview, the README gives one command from the repository root: npm run web:dev, then open http://127.0.0.1:3000. Changes under apps/landscape-web/ and the canonical CSV rebuild automatically. One implementation detail is documented and worth repeating because it explains a failure you would otherwise misdiagnose: the command uses Webpack polling because native file watching has previously exhausted file handles in this repository. Polling trades CPU for reliability, so expect a busier fan on a large checkout. There is also a state quirk. If the page was already open against npm run start, you must refresh once after switching servers so the browser loads the development client; after that, changes appear without another manual refresh. The README is explicit that npm run start is only for checking a completed production build and does not provide live updates. For the data pipeline the steps are: python3 -m venv .venv, then .venv/bin/pip install -r requirements.txt, then fill in scripts/.env with GitHub, ClickHouse, and publishing credentials. ClickHouse being in that list tells you the pipeline expects a columnar store for the OpenDigger signals, which is a real operational dependency rather than a local-only script. Deployment notes point at Vercel with apps/landscape-web as the project Root Directory.
The Curated Shortlist Is Also the Ceiling
The main limitation is stated by the project itself, which makes it easy to miss. A landscape that selects representative projects cannot tell you about the long tail, and the long tail is where a lot of agent infrastructure actually gets adopted. If your team needs a project in a niche that the curators have not judged representative, absence from this dataset tells you nothing about the project. There is a second, sharper problem: the license field. The README lists license among the GitHub metadata columns, but the repository's own license is not stated in the supplied material, and the topics and description do not resolve it. A dataset that carries per-project license strings while its own terms are unstated is awkward for anyone who wants to redistribute the CSV or build a commercial product on it. Third, the freshness model is uneven. The landscape images are dated 2026, the blog post is dated 2026, and weekly reports are generated automatically, but the canonical CSV is maintained by hand through an issue tracker, and the README points contributors at a single dedicated issue for missing projects. Hand curation plus a single intake thread is a throughput limit you should measure before depending on the data for a quarterly decision. Finally, the pipeline needs GitHub and ClickHouse credentials, so a self-hosted mirror is not a weekend project.
Against a Plain GitHub Search or a Package Registry
The obvious alternative is not another landscape. It is the thing most teams already do: a GitHub topic search filtered by language and sorted by stars, or a package registry listing for the runtime layer. The difference in approach is real. A topic search returns everything matching a string and ranks by a popularity counter that never decays; this repository returns a subset chosen by named curators, ranks by a composite activity metric, and attaches a written reason and caveat to each row. The trade is coverage for judgement. A search gives you recall and no opinion; this gives you opinion and no recall. If you need to know whether a specific project exists, use the search. If you need to decide which of forty plausible projects deserves a two-week evaluation, the curation fields do work that a star sort cannot. A second alternative sits closer to home: OpenDigger itself. The README links to X-lab2017/open-digger as the source of the OpenRank values. If your question is purely quantitative, going to OpenDigger directly gives you the raw signals across a far wider set of repositories without anyone's shortlist in between. What you lose is the layer and section assignment that turns a metric into a map.
Maintenance Cost and What the Licence Silence Means
The maintenance story has three moving parts, and only one of them is cheap. The Next.js app reads the CSV directly, so adding a row is a data edit rather than a code change, and the polling dev server rebuilds on save. The Python pipeline in scripts/ is the expensive part: it needs a virtual environment, a requirements install, and a scripts/.env populated with GitHub, ClickHouse, and publishing credentials. Anyone mirroring the project inherits that credential surface and the ClickHouse dependency. The weekly reports are generated by agents, which lowers the marginal cost of publishing but shifts the cost to verification, and the README does not document what that verification consists of. Repository conventions for contributors and coding agents are in AGENTS.md, and weekly report and ecosystem insight operations are documented in WORKFLOW.md, so the process is written down even where the review gate is not. On licensing, the supplied material does not state this repository's license, and I will not guess. The practical implication is narrow but real: the CSV aggregates license strings for other projects, and if you plan to redistribute the dataset or embed it in a product, the terms you need are the ones that are missing. Check the repository root for a LICENSE file and read the license column in the CSV before you ship anything derived from it. This is a description of what to verify, not legal advice.
Editorial conclusion
Adopt it if you need a pre-filtered, machine-readable shortlist of agent and model infrastructure projects with a stated selection reason per row, and you are willing to read selection_caveat before trusting any entry. Skip it if you need exhaustive coverage or a library to build on: this repository ships a dataset, a Next.js viewer and Python collection scripts, not an agent runtime. Before relying on it, open data/agentic-ai-projects.csv, check how many rows carry a non-empty selection_caveat in the layers you care about, and confirm the license status of the four projects whose license field is empty, starting with this repository itself, which the supplied material lists as unknown.
Community notes