Xpert AI: a plugin-governed agent platform where Assistants, tools and workbench views share one lifecycle
XpertAI is an open-source platform for building, running, and evolving ai agents, providing extensible capabilities and infrastructure for diverse AI systems.
At a glance
- What is it?
- Xpert is an AGPL-3.0 TypeScript platform that treats models, tools, middleware, Skills, MCP apps and full Agentic Apps as governed plugins around a core runtime. The interesting part is the plugin boundary and the agent/workflow split; the unproven part is how much of the enterprise governance story is documented rather than demonstrated.
- Who is it for?
- Adopt Xpert if you already accept AGPL-3.0 obligations and you want agent capabilities delivered as installable, versioned plugins rather than as code you maintain in your own repository. Do not adopt it if you need a permissively licensed embeddable runtime, or if your agents are simple single-prompt calls that a few hundred lines of SDK code would cover.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, 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 Xpert addresses: capability sprawl across agent stacks
Most agent projects start as a runtime plus a model client, then accumulate tool registries, prompt stores, retrieval pipelines and UI panels until the original boundary is gone. Xpert's README frames the opposite arrangement. The core is described as providing "the runtime, contracts, security boundaries, and lifecycle controls", while everything users actually touch (model providers, tools, middleware, Skills, MCP apps, Assistant templates, Remote Components, Workbench views and complete Agentic Apps) arrives as a plugin. The tagline is blunt about it: "Everything is a Plugin". The intended audience is a team that wants to install and version agent capabilities the way it installs packages, and that needs a place to put approvals and audit trails rather than handing a model raw credentials. A solo developer writing one tool-calling loop is not the target; the plugin lifecycle is overhead at that scale.
Core runtime, plugin boundary, and the agent/workflow split
Two architectural claims carry the project. The first is the plugin boundary: capabilities and applications are installed artifacts with a lifecycle, and the README lists models, integrations, tools, middleware, Skills, Assistants, Workbench views, MCP Apps and Agentic Apps as things that pass through it. The second is a hybrid execution model. The README says to "use agents for flexible reasoning and workflows for stable, inspectable control paths", and the Agent Studio screenshot description shows a single agent wired to Skills, web tools, sandbox capabilities, retry and loop-guard middleware, and operational controls. The same visual model can combine multiple agents with deterministic Workflow nodes "when a process needs stricter control". That is a real design decision: reasoning stays in the agent, control flow moves into nodes you can inspect. The material does not describe the workflow engine's execution semantics, so how a node hands state to an agent and back is not something I can confirm from what is supplied.
Governed execution: typed tools, semantic objects, approvals, audit trails
The governance section is where Xpert makes its strongest claim and where the documentation is thinnest. The README says the platform exposes "data and business actions through typed tools, semantic objects, policies, approvals, and audit trails instead of handing models raw access". It also describes human-reviewable workbenches where "tool calls open focused UI views where users can inspect, correct, approve, or submit results". That is a coherent pattern: a tool call pauses, a view renders, a person decides, and the result returns to the run. What the README does not give is the shape of a policy definition, where approvals are recorded, or what an audit trail entry contains. Treat the governance layer as the thing to inspect first in a trial instance, not as a feature you can size from the README alone. The related Agentic BI and Data Xpert area claims semantic models, indicators and "governed object-semantic tools for enterprise data queries and actions", which is the same promise applied to analytics.
Getting it running with Docker Compose
The Quick Start path is short and specific. The Docker route requires at least 2 CPU cores, 4 GiB RAM, Docker and Docker Compose. The README gives these commands:
git clone https://github.com/xpert-ai/xpert.git cd xpert/docker cp env.example .env docker compose up -d
Then open http://localhost/ and complete the initialization flow. Note that the compose file lives under xpert/docker, not at the repository root, and that .env is created from env.example rather than generated. The README points to the self-hosting documentation for deployment options, environment configuration and upgrades, so the meaning of individual keys in env.example is not covered in the material I have. For source development the instruction is a supported Node.js LTS release plus the repository-pinned pnpm version through Corepack, which means the pnpm version is fixed by the repo rather than chosen by you.
Where Xpert is the wrong tool
The licence is the first hard boundary. The Community Edition is AGPL-3.0, and the README links a LICENSES.md file, which implies the project distinguishes editions. If you plan to embed the runtime in a closed product or expose a modified version as a network service, AGPL-3.0 obligations apply to that distribution and that service; I am not giving legal advice, and the LICENSES.md file is the document to read before you decide. The second boundary is operational weight. A Docker Compose stack with a 4 GiB memory floor and an initialization flow is a different commitment from a library you import. The third is scope: if your agent is one prompt plus two HTTP tools, the plugin lifecycle, workbench views and approval machinery are cost without benefit. The fourth is documentation depth. The README is a map, not a manual. It names capabilities such as GraphRAG-style evidence, Remote Components and lifecycle hooks without describing their interfaces, so anything you need at the API level has to be confirmed from docs.xpertai.cn or the plugin source repositories.
How this differs from a code-first agent framework
A code-first framework such as the OpenAI Agents SDK or LangGraph has you define agents, tools and graphs in your own repository, and the framework is a dependency you upgrade on your schedule. Xpert inverts that. The runtime is the platform, and capabilities arrive as plugins installed into it, with a marketplace at app.xpertai.cn/plugins/marketplace and source at github.com/xpert-ai/xpert-plugins. The practical difference is where change happens. In a code-first setup, adding a tool is a pull request in your codebase. In Xpert, adding a tool is installing or authoring a plugin that the platform versions and manages, and the README even points at an agent skill (xpert-plugin-development) for creating, testing, deploying and versioning plugins. The trade-off is control versus reuse: you get a governed lifecycle and a catalog of existing pieces, and you give up the ability to read the whole system as one repository. Teams that already run internal platforms tend to prefer the first model; teams that want to consume capabilities rather than maintain them tend to prefer the second.
Maintenance, upgrades and the plugin lifecycle
The README states that the core owns lifecycle controls and that plugins are installed and evolved through one lifecycle, but it does not publish a versioning policy, a compatibility matrix between core releases and plugin versions, or an upgrade procedure beyond pointing at the self-hosting documentation. The repository shows no releases retrieved in the material I have, so there is no changelog to read for breaking changes. That matters more here than in a plain library, because an upgrade can move the runtime underneath plugins you did not write. The npm package @xpert-ai/contracts is published and versioned, which suggests plugin authors compile against a contract surface rather than against core internals, but the README does not state the compatibility guarantees. If you self-host, the upgrade path in the self-hosting documentation is the thing to read before you install third-party plugins, and the AGPL-3.0 licence plus LICENSES.md is the thing to read before you ship anything built on it.
Editorial conclusion
Adopt Xpert if you already accept AGPL-3.0 obligations and you want agent capabilities delivered as installable, versioned plugins rather than as code you maintain in your own repository. Do not adopt it if you need a permissively licensed embeddable runtime, or if your agents are simple single-prompt calls that a few hundred lines of SDK code would cover. Before committing, verify three things against the self-hosting documentation at docs.xpertai.cn/en/ai/getting-started/community: which deployment topology the docker compose file actually starts, what the initialization flow requires in .env, and how upgrade steps handle plugin versions already installed in your instance.
Community notes