# AI Enablement Stack: a five layer map of the AI tooling market > The AI Enablement Stack is a community maintained directory of venture backed AI tools, organised into five layers from infrastructure to agent consumers and rendered as a diagram, an HTML page and a Markdown page from a single JSON file. It is a curated catalogue rather than a tool you run, and its inclusion criteria exclude most open source projects. **daytona/ai-enablement-stack** — A Community-Driven Mapping of AI Development Tools - Repository: https://github.com/daytona/ai-enablement-stack - Stars: 645 · Forks: 121 - Language: HTML - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/daytona-ai-enablement-stack ## What the AI Enablement Stack actually is The AI Enablement Stack is a curated collection of venture-backed companies, tools and technologies that enable developers to build, deploy and manage AI applications. It provides a structured view of the AI development ecosystem across five layers, and it is described as a community-driven mapping rather than a piece of software. The primary language of the repository is HTML, and the repository description calls it a community-driven mapping of AI development tools. The author on the package manifest is listed as Nikola Balic with a daytona.io address, so this is a Daytona project maintained in the open with contributions from outside. The stated audiences are three. Developers are meant to find the right tools to build AI applications faster and more efficiently. Engineering leaders are meant to make informed decisions about AI infrastructure and tooling. And organisations are meant to understand the AI development market and plan technology adoption. That third audience is the one that shapes the content. This is a market map, and the unit of entry is a company with a logo and a link rather than a library you install. That framing is also where its limits come from, and we will come back to it. ## The five layers and how they are defined The stack is organised into five named layers, and the definitions are worth reading closely because they are the taxonomy everything else hangs off. The agent consumer layer is where AI meets end users through autonomous agents, assistive tools and specialised solutions. It holds ready to use AI applications and agentic tools. The observability and governance layer covers tools for monitoring, securing and managing AI systems in production, described as essential for maintaining reliable and compliant AI operations. The engineering layer holds development resources for building production-ready AI applications, including training tools, testing frameworks and quality assurance solutions. The intelligence layer is the cognitive foundation, featuring frameworks, knowledge engines and specialised models that power AI capabilities. The infrastructure layer is the computing backbone that enables AI development and deployment, from development environments to model serving platforms. The ordering runs from infrastructure upward to the agent consumer layer, with intelligence sitting between the engineering work and the end user. Each entry in the generated Markdown repeats its layer and subcategory in a Category field, so the taxonomy is applied per tool rather than inferred from where it sits in the document. ## One JSON file drives the README, the HTML page and the diagram The repository is a small static site generator rather than a hand maintained document, and the layout makes the data flow clear. The source of truth is ai-enablement-stack.json. A logo is added under the public/images/ folder and a tool is added to the appropriate category in that JSON file. From there, the generated artefacts are ai-enablement-stack.html, ai-enablement-stack.png and the Markdown section itself. The scripts are wired in the package manifest: ```json "scripts": { "generate:image": "node generate-image.js", "generate:readme": "node generate-readme.js", "generate": "npm run generate:image && npm run generate:readme", "dev": "node server.js", "start": "node server.js" }, ``` So the readme generation is node generate-readme.js, the diagram is node generate-image.js, and running both is npm run generate. The dev and start scripts both run node server.js, which serves the page locally while you work. The dependencies explain how the diagram is produced. Playwright is a runtime dependency, not just a dev one, which means the image generation drives a real browser to render the stack. Sharp is there for image processing, Express and ws run the server, helmet and express-rate-limit and morgan handle security headers, rate limiting and request logging, and compression handles response encoding. The dev dependencies include Playwright test, chokidar for file watching, nodemon for restarts and the Node type definitions, and there is a playwright.config.js in the tree, so the generated output is checked by browser tests. ## The selection criteria exclude most open source tools This is the part that decides whether the stack is useful to you, and it is stated as four bullet points: production readiness, enterprise-grade capabilities, active development and support, and venture backing or significant market presence. Read that against the entries in the list and the character of the catalogue becomes obvious. Devin, Lovable, Bolt.new, Vercel v0, Morph and Coworked all sit in the agent consumer layer, alongside the open source projects OpenHands, AutoGen and AgentGPT. Bolt.new is described as a web-based development platform enabling in-browser application development with AI assistance, with real-time execution, one-click Netlify deployment and no setup required, aimed at rapid prototyping and non-technical founders. Vercel v0 is described as generating React components from natural language prompts, with Tailwind CSS and Shadcn/UI integration and production-ready code generation with customisation options. So the directory mixes commercial products and open source projects in one list, but the selection criteria tilt the result toward companies with funding and enterprise offerings. A developer looking for a self-hosted or small open source tool will find some of them listed, but they are entries in a market survey rather than a recommendation, and the site is not a catalogue of everything available. A second observation is about data quality. Many entries carry the literal line No description available, so the directory's coverage of the less famous projects in each layer is thin, and the Markdown listing cannot be treated as an even-handed comparison. ## Contributing a tool takes a rationale, not just a link The contribution path is documented in the project README and points at a CONTRIBUTING.md file in the repository root. The steps are numbered from zero. Read the CONTRIBUTING.md file first, fork the repository, add a logo under the ./public/images/ folder, add the tool in the appropriate category in the file ai-enablement-stack.json, and submit a PR with a compelling rationale for its acceptance. The requirement of a rationale for acceptance is the interesting part. This is a curated list, so a pull request that only adds a logo and a JSON entry is not enough. The reviewing side gets to judge whether the tool belongs, which means the list reflects the taste of its maintainers and contributors as much as the market. The structure of an entry in the generated entry format is also fixed. Each tool has a heading with its link, a details block containing an image, then a Category line naming the layer and subcategory, a Description section, and a Links section listing Website, X/Twitter or GitHub as available. That consistency is what makes the JSON file workable as a source for both the HTML page and the Markdown, and it is why the generator scripts can rebuild everything from scratch. The repository also carries a CODE_OF_CONDUCT.md file, a .devcontainer directory and a .vscode directory, so a contributor can work in a prepared container or editor setup, and a yarn.lock file sits alongside package.json. ## Where the AI Enablement Stack is the wrong tool The clearest wrong case is using it as a shortlist for a technical decision. The selection criteria are market criteria, not technical ones. Nothing in the entry format records a licence, a deployment model, a pricing tier, an API surface or a self hosting option, so the data needed to choose between two tools is not in the directory at all. The Links section points at a website, a GitHub repository or an X account. The second wrong case is expecting coverage. The catalogue is a curated community list with entries that say No description available, so a tool that matters to you and is not in the file simply does not appear. There is no search index, no filter and no completeness claim, and the layers themselves are one team's taxonomy rather than an agreed standard. The third is open source and pre revenue work. Venture backing or significant market presence as an inclusion criterion means a small, self hosted or academic project is unlikely to be added, even if it is the right tool for a specific job. If your evaluation criteria include licence compatibility or whether something runs on your own hardware, this list will not help you answer them. The fourth is maintenance timing. The repository is not archived, but the last push was on 2026-07-24, and there are no GitHub releases. Since the artefact is a generated document, a stale commit means a stale diagram, and there is no versioning of the JSON data itself to compare against. ## Apache-2.0, the generator scripts and what an upgrade costs The project is released under the Apache-2.0 licence, with the text in the LICENSE file. The package manifest repeats it as the licence field. The Apache 2.0 terms permit use and redistribution with the notice obligations attached, including stating changes, and the NOTICE file convention applies if one is added. The licence matters here for a specific reason. The generated artefact, the diagram and the HTML page, are derived from the JSON data and the logos in public/images. Some of those logos belong to third party companies, and the Apache licence covers this repository's own content rather than the trademark rights of the companies pictured in it. If you republish the diagram in a deck or on a site, that is a separate question from the code licence. On the upgrade side, the cost is low but real. The dependency set is modest: Express, Playwright, Sharp, ws, helmet, morgan, compression and express-rate-limit at runtime, with Playwright test, chokidar, nodemon and the Node types for development. A browser download for Playwright is the notable part of a fresh checkout, since the image generation genuinely renders the stack in a browser. Because the pipeline regenerates everything from the JSON, the upgrade path is straightforward: pull, run npm run generate, and check the diff in ai-enablement-stack.html, ai-enablement-stack.png and the Markdown section. The repository does not publish GitHub releases, so there is no tagged version to pin and no changelog of the data, which means the git history of ai-enablement-stack.json is your only record of what changed. ## Conclusion AI Enablement Stack works as an orientation document for an engineering leader who has to justify a tooling choice to a non engineering stakeholder, since the five layers give a vocabulary and the diagram gives something to put on a slide. It does not work as a technical shortlist, because selection favours production readiness, enterprise capabilities, active development and venture backing, which leaves out most open source and pre revenue projects. Before relying on it, open ai-enablement-stack.json and check whether the tools you actually shortlist appear at all, read CONTRIBUTING.md to see how a listing is argued for, and run npm run generate after editing so the Markdown page, HTML page and diagram do not drift apart. ## FAQ ### What is the AI Enablement Stack? It is a curated collection of venture-backed companies, tools and technologies for building, deploying and managing AI applications, organised into five layers: agent consumer, observability and governance, engineering, intelligence, and infrastructure. It is a community-driven mapping rather than a runnable tool. ### How do I add a tool to the AI Enablement Stack? Read CONTRIBUTING.md, fork the repository, add a logo under the ./public/images/ folder, add the tool in the appropriate category in ai-enablement-stack.json, and submit a pull request with a rationale for its acceptance. Regenerating the Markdown and diagram is handled by the npm run generate script. ### What criteria decide whether a tool is listed? Four: production readiness, enterprise-grade capabilities, active development and support, and venture backing or significant market presence. That selection favours funded commercial products, so many open source and pre revenue projects are absent. ### Which file is the source of truth for the AI Enablement Stack? ai-enablement-stack.json. The generate-image.js and generate-readme.js scripts read it to produce the diagram image and the Markdown, and package.json wires them together under the generate script. ### What licence does the AI Enablement Stack use? Apache-2.0, stated in the LICENSE file and in the package manifest licence field. Note that the logos in public/images belong to the listed companies, so republishing the generated diagram raises trademark questions the repository licence does not answer. ## Sources - [daytona/ai-enablement-stack on GitHub](https://github.com/daytona/ai-enablement-stack) - [Issues](https://github.com/daytona/ai-enablement-stack/issues) - [License: Apache-2.0](https://github.com/daytona/ai-enablement-stack/blob/main/LICENSE) - [README](https://github.com/daytona/ai-enablement-stack/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/daytona-ai-enablement-stack