Nexent
Build and deploy governed production AI agents from natural-language requirements.
- Source repo
- ModelEngine-Group/nexent
- Stars
- ★ 6.1k
- Last updated
- 1d ago
- License
- MIT
- Primary language
- Python
- FA score
- 52/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API
- Cost
- Free software; you pay for model usage
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- An internal platform team that wants to create business agents from natural-language requirements in a private Docker environment, with version rollback available.
- Not a fit if
- Individuals on a single laptop below 8 GiB memory and 40 GiB disk
- Small teams unwilling to run Docker/Kubernetes, databases, and storage setup
- Source review
- 52/100 · Major gaps
What does this agent do, and when should you use it?
Nexent is a zero-code agent platform built around Harness Engineering, combining tools, skills, memory, and orchestration. It is designed to turn a natural-language requirement into an executable agent, with agent versioning and history rollback. Its documented feature set includes A2A collaboration, two-tier persistent memory, progressive skill disclosure, knowledge-base retrieval, MCP extensions, and source-level citations. It can run on local or private infrastructure through Docker or Kubernetes, with both deployment paths using deploy/env/.env as their runtime configuration. It is best suited to teams that need self-hosting, multi-tenancy, and access controls rather than a standalone model chat interface.
Nexent takes natural-language agent requirements and generates executable agents. At runtime, it combines unified tools, Skills, two-tier memory, and orchestration; Progressive Skill Disclosure loads Skills into context dynamically, while the knowledge base imports more than 20 document formats for retrieval, automatic summaries, and cited answers. A2A Agent Collaboration supports distributed multi-agent workflows, and the MCP Tool Ecosystem connects custom and third-party MCP services. For delivery, bash deploy.sh docker forwards to deploy/docker/deploy.sh, while bash deploy.sh k8s uses deploy/k8s/deploy.sh; both read deploy/env/.env, and the Kubernetes path renders explicit settings into Helm ConfigMap and Secret overrides.
- An internal platform team that wants to create business agents from natural-language requirements in a private Docker environment, with version rollback available.
- A team coordinating several agents in a distributed workflow can use A2A Agent Collaboration for agent-to-agent cooperation.
- An operations or support team with substantial internal documentation can import it into a knowledge base and require source citations in responses.
- A product team that needs retained context at both the user and user-agent level can use the documented two-tier memory model.
- An organization serving multiple tenants and requiring role-based access and fine-grained knowledge-base controls can deploy it as a governed agent service.
- A development team that needs custom or third-party MCP services can extend agents through the MCP Tool Ecosystem.
How do you install or deploy this agent?
For Docker, install Docker 24+ and Docker Compose v2+, then provide at least 4 CPU cores, 8 GiB memory, and 40 GiB disk; the documented recommendation is 8 cores, 16 GiB, and 100 GiB. Run:
git clone https://github.com/ModelEngine-Group/nexent.git
cd nexent
bash deploy.sh dockerFor Kubernetes, install Kubernetes 1.24+ and Helm 3+, with at least 4 CPU cores, 16 GiB memory, and 100 GiB disk. Run:
git clone https://github.com/ModelEngine-Group/nexent.git
cd nexent
bash deploy.sh k8sDeployment preserves an existing deploy/env/.env; if absent, it first reuses docker/.env and otherwise uses deploy/env/.env.example. The supplied material does not document model-provider credential fields, a management URL, or first-login steps.
How do you use this agent?
After running bash deploy.sh docker or bash deploy.sh k8s, interactive deployment offers component, port-policy, and image-source selections. Use --defaults to skip the menu, or provide --version, --components, --port-policy development|production, and --image-source general|mainland|local-latest. infrastructure is mandatory; application, data-process, and supabase are selected by default but may be disabled. Product use is described as stating the desired agent in natural language and configuring the required knowledge base, Skills, MCP services, memory, and collaboration capabilities; the supplied material does not include a UI walkthrough or API example for creating the first agent.
What are this agent's strengths and limitations?
- It unifies tools, skills, memory, and orchestration under Harness Engineering, with documented constraints, feedback loops, and control planes.
- It offers both Docker and Kubernetes deployment paths using a shared deploy/env/.env configuration model for local or private infrastructure.
- A2A collaboration, progressive Skill loading, two-tier memory, MCP extensibility, and cited knowledge retrieval cover core components of multi-agent applications.
- Multi-tenancy, RBAC, agent versioning, and history rollback provide governance-oriented capabilities for organizational deployments.
- The minimum footprint is material: Docker requires at least 4 CPU cores, 8 GiB memory, and 40 GiB disk, while Kubernetes requires at least 16 GiB memory and 100 GiB disk.
- Kubernetes deployment requires Kubernetes 1.24+ and Helm 3+, plus storage decisions such as persistence mode, storage class, or local path.
- The supplied material does not specify model-provider credential fields, the detailed first-agent configuration flow, the management endpoint, or API examples, so implementation details need validation.
- Although optional components can reduce the footprint, application, data-process, and supabase are selected by default, so deployers must assess component scope.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Nexent This agent | 52 · Major gaps | Self-hosted serviceFree + model costs | ★ 6.1k | 1d ago | Python | OpenAI API |
| Solace Agent Mesh | 35 · Major gaps | CLIFree + model costs | ★ 4.9k | 1d ago | Shell | — |
| npcpy Agent Framework | 43 · Major gaps | Library / SDKFree + model costs | ★ 1.5k | 4d ago | Python | Codex · Claude Code · OpenAI API · Claude API |
| aiXplain SDK | 29 · Major gaps | Library / SDKFreemium | ★ 59 | 7d ago | Python | — |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows deployment scripts support interactive confirmation (TUI) and defaults mode, but do not explicitly require user confirmation for external actions; sensitive information (e.g., registry passwords) is handled, but storage and transmission security are not detailed; dependency security includes some checks (e.g., path traversal rejection), but no dependency vulnerability scanning; external effects: deployment scripts pull and push images, but permissions are not explicitly limited; rollback: version management and history rollback are claimed, but no concrete implementation is provided; source attribution: copyright notice and contribution guide exist, but publisher is unverified. Therefore, scores are low.
Self-consistency: README, deployment scripts, and test files are largely consistent, but some inconsistencies exist (e.g., README mentions Docker Compose, but tests do not reflect it); dependency availability: external images and Hugging Face models are relied upon, but no availability guarantees are provided; failure messages: test scripts have clear error messages, but not all failure scenarios are covered.
Audience and scenarios: README clearly identifies individual/small team and enterprise scenarios, and provides Docker and Kubernetes deployment options; capability boundaries: core features are listed, but no explicit limitations; trigger precision: deployment scripts support various parameters and interactive modes, but trigger conditions are not explicit; environment fit: multiple architectures and deployment environments are supported, but detailed compatibility notes are missing.
Information architecture: README is well-structured with TOC and documentation links; install notes: detailed deployment steps and system requirements are provided; naming stability: project name and version naming are consistent; examples and FAQ: documentation links are provided, but no concrete examples; known limitations: not explicitly listed; license: MIT license is present; versioning and changelog: version statement exists, but no changelog; maintenance responsibility: contribution guide and security policy exist, but maintainers are not clearly identified.
Output usability: deployment and test scripts provide clear output and error messages; marginal value: zero-code platform and multiple features are offered, but no comparison with other platforms; cost-benefit: deployment options and resource requirements are provided, but no cost analysis.
Claim traceability: feature claims in README are not backed by concrete implementation or test evidence; cross-source corroboration: test scripts and documentation exist, but no independent verification; fact-inference separation: README claims are mostly assertions, without distinguishing facts from inferences.
- Publisher identity is unverified; treat with caution.
- Deployment scripts handle sensitive information (e.g., registry passwords); ensure secure transmission and storage.
- Reliance on external images and models; ensure supply chain security.
- Feature claims lack concrete implementation and test evidence; further verification is needed.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Bug 修复 / Bug Fixes - 优化离线部署包的镜像导出，回滚按平台过滤的导出逻辑，旧版单平台镜像不再导致离线包构建中断。 / Improved image export for offline deployment packages by rolling back the platform-filtered export, so legacy single-platform images no longer abort the offline package build. - 优化自动化消息来源的迁移逻辑，仅按显式运行消息引用归类，不再扫描全部消息单元；历史会话的活跃时间保持为空并沿用会话创建时间兜底。 / Improved the automation message-source migration to classify only explicit run message references instead of scanning all message units, and left legacy activity timestamps empty so conversation creation time remains the fallback.View on GitHub ↗ -
Release notes excerpt
Bug 修复 / Bug Fixes - 修复代理组内权限的历史数据问题：将旧表单遗留的 EDITABLE 值归一化为 EDIT，使非创建者、非管理员用户在界面上显示的编辑权限与实际行为一致。 / Fixed legacy agent in-group permissions by normalizing the EDITABLE value left by the previous deployment form to EDIT, so non-creator and non-admin users now actually get the edit access the UI already advertised. …View on GitHub ↗ -
Release notes excerpt
Bug 修复 / Bug Fixes - 修复对话来源信息在长列表中卡顿的问题：来源元数据改为两行展示并由样式裁剪，悬停与详情按需加载，来源与图片分页统一为每页 20 条，前台刷新做了合并处理，引用在手动翻页后仍能正确定位。 / Fixed chat source metadata stalling on long lists: metadata now renders as two clipped rows, hover and details load lazily, sources and images paginate at 20 items per page, foreground refresh is coalesced, and citations still relocate correctly after manual paging. …View on GitHub ↗