[opensourcedex]

nexent is a free, open source ai development platforms project written in Python and released under MIT. It has 5,869 GitHub stars, 730 forks and 265 open issues, and was last pushed 75 minutes ago. On this registry it ranks #77 of 116 tracked projects in AI Development Platforms, with 5 head-to-head comparisons available.

What is nexent?

Nexent is a zero-code Python platform that auto-generates production-grade AI agents from natural-language prompts, built on Harness Engineering principles and aimed at developers and teams who want deployable agent systems without drag-and-drop orchestration.

What it is

Nexent is an open-source platform, written in Python and released under the MIT licence, that turns a prompt into a working AI agent. It sits in the AI & Machine Learning / AI Development Platforms category and packages the pieces an agent normally needs to be wired together by hand: unified tools, skills, memory, and orchestration. Those parts ship with built-in constraints, feedback loops, and control planes, so the generated agent carries its own guardrails and control surface rather than relying on external glue code. The project describes its development model as pure language: one prompt, then an agent, with no orchestration graph to draw.

The concrete problem it solves is agent assembly. Building an agent today usually means stitching together a tool layer, a memory store, a retrieval pipeline, a model client, and an orchestration layer, then adding your own retry, constraint, and observability logic on top. Nexent replaces that manual drag-and-drop scaffolding with a generation step. The registry topics reflect the same stack — agent, agentic-ai, agentic-framework, agentic-rag, agentic-workflow, harness, harness-engineering, llm, mcp, multi-agent, and rag — so retrieval, tool calling, and multi-agent work are first-class parts of the platform rather than add-ons.

Key capabilities

  • Zero-code agent generation: agents are produced from natural language, not from a visual orchestration canvas.
  • Unified runtime for tools, skills, memory, and orchestration under one platform rather than separate services.
  • Built-in constraints, feedback loops, and control planes shipped as part of the agent harness.
  • Agentic RAG and multi-agent workflows, per the project topic list.
  • MCP (Model Context Protocol) support, listed among the project topics.
  • Two deployment paths from the same scripts: Docker via bash deploy.sh docker and Kubernetes with Helm 3+ on Kubernetes 1.24+.
  • Component selection at deploy time — infrastructure is required, while application, data-process, and supabase are selected by default and can be disabled for a smaller footprint.
  • Offline image packaging through bash build.sh --package --target docker --compress true or bash deploy/offline/build_offline_package.sh --target docker --compress true, producing image tars, load-images.sh, push-images.sh, manifest.yaml, and checksums.txt.

Who uses it and how

  • Individuals and small teams run the Docker Compose path, where the minimum is 4 CPU cores, 8 GiB memory, and 40 GiB disk, with 8 cores, 16 GiB, and 100 GiB recommended.
  • Production or platform teams run the Kubernetes path, which starts at 16 GiB memory and 100 GiB disk and recommends 64 GiB and 200 GiB, with Helm 3+ and Kubernetes 1.24+.
  • Air-gapped or mainland-network deployments use the offline package builder and the --image-source mainland or --image-source local-latest options instead of pulling from a public registry.
  • Operators reuse saved choices: successful runs write non-sensitive selections to deploy.options, and --defaults redeploys from that file without the interactive TUI.
  • Teams tuning runtime behaviour edit deploy/env/.env, with fallback to docker/.env and then deploy/env/.env.example; monitoring settings are generated from deploy/env/monitoring.env.example into deploy/env/monitoring.env.

Getting started

Clone the repository, change into it, and run bash deploy.sh docker; that entrypoint forwards to the native implementation at bash deploy/docker/deploy.sh. Images are also published to Docker Hub under nexent/nexent.

How it compares

No list of paid products this project replaces and no competing tools are named in the provided facts, so on the evidence here Nexent stands alone in this registry, with no direct alternative documented alongside it.

When to use it — and when not to

A self-hoster must operate the full stack, including the supabase and data-process components, the .env configuration, and monitoring, plus Docker 24+ and Compose v2+ or Kubernetes and Helm. Anyone wanting a fully managed hosted service, a single static binary, or a host with fewer than 4 cores and 8 GiB of memory should look elsewhere. The project also carries 265 open issues, and the README is dominated by deployment mechanics rather than agent-authoring guidance, so expect to lean on the external documentation site rather than the repository text alone.

project readme (upstream, from github) — read inline

Nexent Banner

Website English 中文 Documentation Docker Pulls Codecov (with branch)

Nexent is a zero-code platform for auto-generating production-grade AI agents, built on Harness Engineering principles. It provides unified tools, skills, memory, and orchestration with built-in constraints, feedback loops, and control planes — no orchestration, no complex drag-and-drop required, using pure language to develop any agent you want.

One prompt. Endless reach.

Watch the demo video

🚀 Get Started Now

⭐ Before you get started, please star us on GitHub — your support drives us forward!

Deploy on Your Own

If you need to run Nexent locally or in your private infrastructure, we offer two deployment options:

System Requirements

Resource Docker Kubernetes
CPU 4 cores (min) / 8 cores (rec.) 4 cores (min) / 8 cores (rec.)
Memory 8 GiB (min) / 16 GiB (rec.) 16 GiB (min) / 64 GiB (rec.)
Disk 40 GiB (min) / 100 GiB (rec.) 100 GiB (min) / 200 GiB (rec.)
Architecture x86_64 / ARM64 x86_64 / ARM64
Software Docker 24+, Docker Compose v2+ Kubernetes 1.24+, Helm 3+

Note: Recommended configurations ensure optimal performance in production environments.

Docker Deployment (Recommended for Individuals/Small Teams)

Quick and straightforward for most users. Prerequisites: Docker 24+ and Docker Compose v2+:

git clone https://github.com/ModelEngine-Group/nexent.git
cd nexent
bash deploy.sh docker

The root deploy.sh only forwards to the target deploy script; the native Docker implementation is bash deploy/docker/deploy.sh. The Docker and Kubernetes deploy scripts share the same deployment configuration model. Interactive runs show Bash TUI menus for component selection, port policy, and image source. infrastructure is required; application, data-process, and supabase are selected by default and can be disabled when you want a smaller deployment. Use b/Backspace to return to the previous TUI step and q to quit. Use --defaults to skip the TUI and deploy with saved deploy.options or built-in defaults. Non-interactive runs can also pass the same choices with --version, --components, --port-policy development|production, and --image-source general|mainland|local-latest. Successful deployments save non-sensitive choices to each deploy directory's deploy.options for reuse on the next run.

Docker and Kubernetes both use deploy/env/.env as the runtime configuration file. Existing deploy/env/.env is kept as-is. If it does not exist, the deploy scripts first reuse docker/.env, then fall back to deploy/env/.env.example. Monitoring-specific settings are generated from deploy/env/monitoring.env.example into deploy/env/monitoring.env.

Docker uninstall is handled by bash uninstall.sh docker. It can preserve or delete data volumes: run it interactively, pass --delete-volumes true|false, or use bash uninstall.sh docker delete-all to remove containers and persistent data.

Offline image packages can be built with bash build.sh --package --target docker --compress true or bash deploy/offline/build_offline_package.sh --target docker --compress true. The package includes image tar files, load-images.sh, push-images.sh, root deploy/uninstall entrypoints, deployment scripts, SQL files, manifest.yaml, and checksums.txt. Package deploys use saved deploy.options or built-in defaults without opening the TUI; add --config to configure interactively. Deploy with bash deploy.sh --load-images docker ... on the target host, or use bash deploy.sh --push-images --image-registry-prefix registry.example.com/nexent docker ... to push loaded images to an internal registry and deploy with that image prefix. When --push-images is used without a prefix, deploy.sh asks for it before push-images.sh prompts for the registry username and password.

For detailed deployment instructions, see Docker Installation.

Kubernetes Deployment (For Enterprise Production)

Ideal for enterprise scenarios requiring high availability and elastic scaling. Prerequisites: Kubernetes 1.24+ and Helm 3+:

git clone https://github.com/ModelEngine-Group/nexent.git
cd nexent
bash deploy.sh k8s

The native Kubernetes implementation is bash deploy/k8s/deploy.sh. It installs two independent Helm releases: nexent-infrastructure for Elasticsearch, PostgreSQL, Redis, and MinIO, then nexent for application services after infrastructure and the Elasticsearch API key are ready. Use --release-scope all|infrastructure|nexent to operate both releases or either side independently. The script reads deploy/env/.env and renders explicit Helm ConfigMap and Secret overrides. Use --persistence-mode local|dynamic|existing, --storage-class/--sc, --local-path, --local-node-name, and --existing-claim-prefix to control PVC behavior.

Kubernetes uninstall is handled by bash uninstall.sh k8s. By default it removes nexent first and nexent-infrastructure second. The same --release-scope option supports application-only removal and dependency-protected infrastructure removal.

Kubernetes offline packages use the same builder with --target k8s or --target all. Run load-images.sh on every cluster node that needs the images, or use --push-images --image-registry-prefix registry.example.com/nexent to push the images to an internal registry before deploying with the same version, image source, and image registry prefix.

For detailed deployment instructions, see Kubernetes Installation.

✨ Core Features

Nexent provides a comprehensive feature set for building powerful AI agents:

Feature Description
⚙️ Multi-Model Integration OpenAI-compatible with any provider, full LLM/Embedding/VLM/STT/TTS coverage, supports domestic model switching
🤖 Zero-Code Agent Generation Describe requirements in natural language, generate executable agents instantly, what you think is what you get
🤝 A2A Agent Collaboration Agent-to-Agent protocol enables seamless multi-agent cooperation and distributed workflows
🧠 Layered Memory Mechanism Two-tier memory (user-level + user-agent-level) for persistent context across conversations
📝 Progressive Skill Disclosure Dynamically loads Skill into context, maximizing context window efficiency
🗄️ Personal-Grade Knowledge Base Real-time import and intelligent retrieval for 20+ document formats, auto summaries, fine-grained access control
🔧 MCP Tool Ecosystem Plug-and-play extension system with custom development and third-party MCP service support
🌐 Internet Knowledge Integration Multi-source search blending real-time information with private data
🔍 Knowledge-Level Traceability Precise citations and source verification, full transparency for every fact
🎭 Multimodal Interaction Voice, text, images, files — comprehensive natural dialogue
🔢 Agent Version Management Version iteration and history rollback, safe and controllable
🏪 Agent Marketplace Official and community curated agents, one-click install and use
👥 Multi-Tenancy & RBAC Multi-tenant isolation, role-based access control, fine-grained resource management

🤝 Join Our Community

If you want to go fast, go alone; if you want to go far, go together.

We have released Nexent v2.0! A comprehensive upgrade from v1.0, featuring A2A protocol support, progressive Skill disclosure, layered memory mechanism, user management with multi-tenancy, agent version management, agent marketplace, and more.

readme truncated — read the full docs on github

Frequently asked questions

Is nexent free to use?

nexent is open source under the MIT licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does nexent do?

Nexent is a zero-code platform for auto-generating production-grade AI agents using Harness Engineering principles — unified tools, skills, memory, and orchestr

What is nexent written in?

nexent is primarily written in Python. Its source is publicly available at https://github.com/ModelEngine-Group/nexent, and it has 5,869 GitHub stars.