NocoBase: A No-Code Platform Where AI Agents and Humans Edit the Same Data Model

The Problem NocoBase Targets: Business Systems That Are Too Specific for SaaS and Too Boring to Hand-Code

Internal tools sit in an awkward gap. A CRM, an ERP module, a project tracker or an admin dashboard is rarely novel, but it is always specific to one company's data model, approval chain and permission rules. Buying a SaaS product means bending the business to the vendor's schema. Writing it from scratch means paying for authentication, audit logs, field-level permissions and a workflow engine before anyone sees a useful screen. NocoBase is aimed at that gap, and the README frames the target audience explicitly: the WYSIWYG interface is described as designed for regular users, not just developers, while the CLI and agent integration are aimed at people who already run Claude Code, Cursor, Codex, OpenCode or TRAE. The project topics reinforce the same positioning: admin-dashboard, crm, erp, internal-tool, project-management, self-hosted. This is a platform for building the systems a company runs on, not a general web framework.

How It Works: Configuration on Top of a Microkernel, Not Generated Application Code

The architectural claim in the README is the interesting part. Instead of an agent emitting a codebase, the agent emits configuration for infrastructure that already exists: data models, pages, workflows and permissions. The README describes this as AI working on top of production-proven infrastructure and a WYSIWYG no-code interface, with built-in guardrails that keep AI output aligned with the system architecture. Underneath, the design is a microkernel in which everything is a plugin, with shared conventions across official and custom plugins. Data is decoupled from the UI and stays in standard relational structures; the README states you can use the main database, external databases and third-party APIs as data sources. That separation is what makes the human and agent workflows compatible. Both edit the same model, so a person refining a form layout in the WYSIWYG interface and an agent adding a workflow step are operating on one representation rather than two divergent ones. The README also describes a second layer of AI usage beyond building: AI employees that run inside the system, handling analysis, Q&A, form filling on the front end and document recognition, risk monitoring and task routing on the back end, with their own roles and field-level read and write permissions.

Getting It Running: Three Commands and a Decision About Which Agent You Use

The README's quick start is short and specific. You install the CLI globally with npm install -g @nocobase/cli, confirm it with nb --version, scaffold an application with nb init --ui, and then optionally start a coding agent alongside it. The README lists codex, claude and opencode as the example agent commands. The --ui flag on nb init is the part worth noting: it signals that scaffolding is expected to involve the browser-based configuration interface rather than being a purely terminal affair. The README points to two documentation pages for the details, one on installing a NocoBase app and one titled AI Agent Integration Guide. Beyond the CLI, the README mentions MCP, HTTP APIs, CLI and skills as the interfaces through which external agents connect, and names OpenClaw, Hermes, Dify, Coze and n8n as platforms that connect through standard protocols, with Telegram, WhatsApp, Slack and Gmail as channels for querying data and triggering workflows. None of the connection details are in the README itself, so treat the documentation site as required reading before you plan an integration.

The AI Employee Model Is the Most Distinctive Idea and the Least Documented One

Most no-code tools with AI features use the model to generate an app and then get out of the way. NocoBase's README describes something different: AI employees that continue to operate after the system is built, integrated with workflows so they can join decisions and execution. The permission design is the concrete part. Each AI employee has its own role with field-level read and write permissions, audit logs record every data change and workflow trigger, and admins can adjust AI permissions at any time. That is a sensible answer to an obvious question, which is what stops an agent from writing to the wrong table. What the README does not give is the operational detail: how an AI employee is defined, how its role is assigned, what happens when a workflow step it participates in fails, or how cost and latency are bounded when an agent sits inside a business process. Those are the questions to answer from the documentation before you put an AI employee anywhere near production data.

Where NocoBase Is the Wrong Tool

The plugin microkernel is a commitment, not a feature you can ignore. If your project is a bespoke TypeScript application with unusual runtime requirements, a custom protocol, or a UI that does not resemble a data-driven business system, you will spend your time working against the platform's conventions rather than with them. The README's own framing supports this: the value proposition is not starting from scratch, which means the platform's opinions about data models, pages, workflows and permissions are load-bearing. A second constraint is release cadence. The three most recent releases in the material are v2.2.10, v2.3.0-beta.9 and v2.4.0-alpha.5, all dated within two days of each other. That is a fast-moving project with stable, beta and alpha lines running in parallel, and the README's release notes live on a blog rather than in the repository, with weekly summaries of important changes. Running an alpha or beta line against business data is a decision you make deliberately, not by default. A third point to check rather than assume: the repository reports its licence as NOASSERTION, which means no standard licence identifier was detected. The README does not discuss licensing at all. Anyone planning to embed NocoBase in a commercial product needs to read the actual licence file, since nothing in the supplied material settles the question.

How It Differs From Directus and Appsmith

The nearest comparisons are Directus, which puts a data platform and API in front of an existing SQL database, and Appsmith, which builds internal UIs on top of arbitrary APIs and databases. Directus is database-first: you bring a schema and it exposes REST and GraphQL over it, with a relatively thin administrative layer. Appsmith is UI-first: you drag widgets and bind them to queries. NocoBase is model-first in a different sense, because the data model, the page configuration, the workflow engine and the permission system are all first-class objects that both a person and a coding agent can edit through the same interface. That shared editing surface is the actual difference. With Directus or Appsmith, an AI agent typically writes code against an API. With NocoBase, the README describes the agent configuring the platform itself, using the CLI and skills, which is why the project insists that AI output stays aligned with the system architecture rather than becoming black-box code. Whether that holds up in practice depends on how well the skills and guardrails are documented, which the README does not show.

Maintenance and Upgrade Cost

The README makes a maintenance argument rather than stating a cost. Because features arrive as composable plugins with shared conventions, and because data stays in standard relational structures in your own database, the platform's claim is that you avoid platform lock-in and can mix custom and official plugins. The practical counterweight is that you are now maintaining a NocoBase deployment plus whatever custom plugins you write, and you are tracking a project that ships stable, beta and alpha releases on the same day. The README's release notes process, weekly summaries posted to a blog, is your upgrade signal; there is no changelog in the repository material provided. The plugin architecture cuts both ways here: upgrading the core is a plugin compatibility question, not just a version bump. On licensing, the only fact available is that the repository reports NOASSERTION, so the terms governing commercial use, redistribution and plugin licensing cannot be determined from the supplied material and should be read directly from the licence file before adoption.

Editorial conclusion

Adopt NocoBase if you need an internal system with data models, permissions and workflows that both non-developers and coding agents can edit in the same place, and you accept installing the @nocobase/cli globally and running nb init --ui to scaffold the app. Do not adopt it if you want a plain TypeScript framework to build a bespoke product; the plugin microkernel and configuration layer are the product, and working against them is wasted effort. Verify the licence terms first, because the repository reports NOASSERTION rather than a named licence, and confirm the v2.2.10 versus v2.3.0-beta.9 release line you intend to run before committing data to it.

Official sources

1. Issues
2. nocobase/nocobase on GitHub
3. Project website
4. README
5. Releases