agentic-ai-landscape: a root package for slides, a start script that is not there, and no licence

The root package builds slides, and the web app is a second package under apps/

The manifest at the repository root is not the landscape application. Its name is `agentic-ai-landscape-pptx-tools`, its description says local PPTX generation helpers for reports and talks, it is marked private so it is never published, and its single dependency is `pptxgenjs` at `^4.0.1`. Its version is `0.1.0` and its Node floor is 18.

Three scripts are defined. Two of them are slide tooling: `pptx:check` runs a script that verifies pptxgenjs, and `pptx:sample` builds a sample deck. Both are plain node scripts with no test framework around them, which is a sensible way to keep a slide dependency working without standing up a runner.

The third is the one you need to run the site, and it delegates:

npm run web:dev

That expands to `npm --prefix apps/landscape-web run dev:local`. So the actual Next.js application lives in a second package under `apps/`, with its own manifest and its own dependencies, and the root manifest contains none of them. Running `npm install` at the root installs pptxgenjs and nothing the website needs.

The architecture underneath is sensible: the CSV is the single source of truth and the web app reads it directly. The cost is that the repository has two JavaScript dependency trees and one of them is invisible from the root manifest.

The start script is documented as a root command and is not defined there

The preview instructions tell you to run `npm run web:dev` from the repository root and open `http://127.0.0.1:3000`. Then they say to use `npm run start` only when checking a completed production build, and note that it does not provide live updates.

The root manifest has no `start` script. Its three scripts are `web:dev`, `pptx:check`, and `pptx:sample`. A `start` script exists inside the app package, if anywhere, and following the page's wording from the root gives you a missing script rather than a production server.

The same paragraph reveals why the two servers need care. If the page is already open against `npm run start`, you have to refresh it once after switching to the development server so the browser picks up the development client, and after that changes appear without another manual refresh. Two servers serving the same port to the same tab is a normal situation in Next.js and it is documented here without a fix.

There is a third disclosure in the same block that says more about the repository than the tooling does. The development command uses Webpack polling because native file watching has previously exhausted file handles in this repository. That is a real constraint on a tree containing a large CSV, an app, insight content, and scripts: the default file watcher runs out of handles, so the dev loop pays a polling cost on every build.

Changes under `apps/landscape-web/` and the canonical CSV are both picked up and rebuilt automatically, which is the behaviour you would want if the polling workaround had not been necessary.

Four addresses for one map, and two frontends reading the same CSV

Pointing at this project is ambiguous. The recorded homepage is `insights.inclusion-ai.org`. The top of the page links to a Canva site at `agi-landscape.my.canva.site` and to `inclusion-ai.org/insight`, and the body links to the same page again with a trailing slash. The production deployment is `landscape-demo-omega.vercel.app`.

So there is a static presentation artefact, a separately hosted insights site, a Vercel demo whose name contains a generated suffix, and a projects page that appears twice in the same document with and without its trailing slash.

Underneath all of them is one file. The canonical dataset is `data/agentic-ai-projects.csv`, and the production Next.js application reads it directly. That is the part worth crediting: there is no database of record to drift from, and the static artefact and the web app cannot disagree about a project's stars because neither of them stores them.

The Vercel instruction is a small operational detail with a trap in it. Vercel is told to use `apps/landscape-web` as the project Root Directory, which only works if you understand that the repository is a monorepo and the app is a subdirectory. Connect the repository root and you get a project that has no Next.js app in it, only a slide helper.

Every row records why the project is in and what the caveat is

The dataset schema is the most transferable thing here, and one column in it is unusual.

Each row is keyed by the GitHub `repo_id` rather than by name, so a renamed repository keeps its identity. Rows carry GitHub metadata: stars, forks, licence, language, topics. They carry OpenDigger signals in `openrank_*` and `participants_*` columns. And they carry four curation fields: `landscape_layer`, `landscape_section`, `selection_reason`, and `selection_caveat`.

`selection_caveat` is the one to notice. The dataset records not just why a project was included but what is wrong with including it. That is a discipline most rankings lack, and it converts an opinion list into something a reader can audit: you can find the rows where the authors themselves flagged a problem.

The activity measure is stated as a deliberate choice. Projects are ranked with OpenRank rather than raw star counts, so activity from issues, pull requests, reviews, and contributors is taken into account. Stars measure attention; OpenRank measures work.

The scope is equally explicit. The landscape highlights the projects currently most representative of each ecosystem rather than attempting to cover every project, and the two infrastructure blocks are Agent Infra for the application, framework, runtime and tool ecosystem, and Model Infra for the data, training, serving and deployment stack. So a row count is a curation budget, not a census, and the OpenRank figures describe activity at collection time.

The Python requirements split by use and name a version only in a comment

The dependency file is organised by who needs what, and the second group is optional by comment rather than by extras.

python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
# then fill in scripts/.env with GitHub, ClickHouse, and publishing credentials

The runtime group is `requests[socks]`, `python-dotenv`, `python-dateutil`, and `clickhouse-connect`. The extras flag on requests means the collector can go through SOCKS proxies, and the ClickHouse driver says the analysis runs against a ClickHouse backend rather than against the CSV alone. A second group, described as only needed by the insight and figure helper scripts, adds `pandas` and `duckdb`.

The Python version is stated as a comment, `# Runtime dependencies for scripts/ (Python 3.12)`. A comment constrains nobody, so the version you get is whatever `python3` resolves to on your machine.

The bigger gap is that the documented setup stops before the interesting part. The fence creates a virtual environment, installs four packages, and then tells you to fill in `scripts/.env` with three separate credential sets. It never shows the command that collects anything. That is deferred to `WORKFLOW.md`, which is said to document weekly report and ecosystem insight operations, and to the `scripts/` directory.

Storing GitHub, ClickHouse and publishing credentials in one dotenv file is a small thing that scales badly as the publishers multiply, since a single file with three secrets tends to get copied around as one unit.

Submissions go to one pinned issue, and insights ship as dated bilingual posts in the repo

Corrections and additions have a single destination. If you think an important project is missing, you are asked to share it through a dedicated issue tracker, which is issue 1 in this repository rather than a form or a new issue.

That is a real mechanism with a real cost. One issue as an intake channel keeps the discussion in one place and makes it easy to find, but it also means the queue is a single thread that grows without bound and that nothing about a submission gets its own searchable history.

The content side explains why the primary language of this repository is HTML rather than Python or TypeScript. Three kinds of writing are published here: landscape reports described as dated, bilingual analyses of how each layer is evolving; case studies as deep dives into single projects or themes; and weekly reports described as automatically generated snapshots of newly surfacing projects. They live under `insights/`, with the case studies and the weekly reports in their own subdirectories.

So the repository is three things at once: a data pipeline, a content site, and a web application. The pipeline and the site are the reason there is a `data/` directory next to an `insights/` directory next to an `apps/` directory, and the weekly snapshot job is the reason there is a ClickHouse dependency at all.

The page also states who produces it, Ant Open Source and inclusionAI, and closes with a section headed Initiated by Communities that renders as whitespace, with the image slots present but empty.

No licence file, no releases, and a skills lockfile next to an openspec directory

The licence position is the first thing to settle and there is nothing to settle it with. The root entries contain a `.dockerignore`, a `.gitignore`, `AGENTS.md`, `CLAUDE.md`, the readme, a workflow document, the content and code directories, two dependency files and two lockfiles. There is no licence file. The recorded licence field is empty as well, so the metadata and the tree agree on nothing rather than disagreeing, and for a dataset you may want to republish that is a genuine gap rather than a formality.

There are no published releases either, so the dataset has no versioned history you can pin to. The last push is 2026-09-27.

The agent tooling at the root is more than usual. There is a `skills-lock.json`, a directory called `openspec/`, a `.agents/` directory, an `AGENTS.md` that the page names as the place holding repository conventions for contributors and coding agents, and a separate `CLAUDE.md`. That is two instruction surfaces plus a skills lock plus a spec directory, for a repository whose actual code is a CSV and some scripts.

The dependency files sit side by side too: `package-lock.json` for the slide helper and `requirements.txt` for the scripts, with no shared tooling to keep them in step. Nothing visible states that the two registry descriptors or the weekly job are generated from the manifest, which means drift between what the site shows and what the repository says has to be caught by reading.

Editorial conclusion

Use this repository if you want the ecosystem dataset and the reasoning behind it rather than a tool, because the curation columns are the actual contribution and the OpenRank signals measure work rather than attention. Do not treat it as an exhaustive index or as a neutral one, since the selection is explicitly representative rather than complete and every row carries a human selection reason. Before you rely on it, resolve the licence question, because no licence file is present and the metadata records none, which matters if you plan to republish the CSV. And if you intend to run the local preview, read the scripts directory yourself first, since the documented setup stops before the entry point and one documented command is not defined where the page implies.

Frequently asked questions

Official sources

1. antgroup/agentic-ai-landscape on GitHub
2. Issues
3. Project website
4. README